chr.istoph, der Blog

Der Adaptec Device [9005:028b] (rev 01) hat auf einem Kunden Server immer einen hänger in den Virtuellen Maschinen verursacht. Zigleich traten folgende Fehlermeldung im kernel.Log auf:
[501672.741192] aacraid: Host adapter abort request (0,0,1,0)
[501672.741304] aacraid: Host adapter reset request. SCSI hang ?


Da mir der Contorler schon suspeckt vor kamm und das Problem erst nach einem Jahre langen neustart auftrat habe ich mir den scheduler mal angesehen. Ein gestellt war cfq:
cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]

Da der Controller aber immer alles besser weiß habe ich diesen auf noop = no operration umgestellt.
echo noop > /sys/block/sdb/queue/scheduler
cat /sys/block/sdb/queue/scheduler
[noop] anticipatory deadline cfq

Nun lief der reicher wieder flüssig.

Aktuell kann man fast jede Woche auf ssllabs.com nachschauen, ob das „rating“ einer Webseite mal wieder gefallen ist, einer der Server falsch konfiguriert ist oder einfach nur vergessen wurde Dienste neu zu starten. Um dies zu automatisieren hat ssllabs endlich eine api im development Modus freigeschaltet.

Schade das in der api kein Feld ohne das trusted flag hinterlegt ist, so bekomme ich mit meinem CACert leider immer nur ein T.

Ich habe das mal für den Zabbix gescriptet. Alles was man braucht ist folgende ausführbare Datei im Ordner /etc/zabbix/externalscripts/zabbix-check-ssllabs.sh

#!/bin/bash
domain=$1
if [ "$domain" = "" ]; then
	exit 1
fi

tmp=$(mktemp)
#TODO: trap
wget -q -O $tmp "https://api.dev.ssllabs.com/api/fa78d5a4/analyze?host=$domain&publish=On&clearCache=On&all=done"
sed 's/,/\n/g' $tmp | grep grade | awk -F '"' '{print $4}'
rm $tmp

Und natürlich ein Schema das man im Zabbix importieren muss:
Read the rest of this entry »

Wie ich schon vor einigen Jahren geschrieben habe, kann man die SSH fingerprints im DNS hinterlegen, um SSH Verbindungen zu validieren.

# dig -t sshfp blog.chr.istoph.de
;; ANSWER SECTION:
blog.chr.istoph.de. 7199 IN SSHFP 1 1 D931B1124CC5DA23DB2131C62BA9D286081E3EA7
...

Dafür hinterlegt man die Secure Hash Algorithm (SHA) Summen im DNS:
ssh-keygen -r blog.chr -f /etc/ssh/ssh_host_rsa_key.pub
blog IN SSHFP 1 1 d931b1124cc5da23db2131c62ba9d286081e3ea7
blog IN SSHFP 1 2 0fe30bacf0833a9051a74cec431af450ceeca4171b3da5bf0550ada55adadbfa

Jetzt gibt es aber neue Algorithmen die in SSH Einzug erhalten haben.
1: RSA
2: DSA
3: ECDSA
4: ED25519

Da man mit ssh-keygen immer nur einen Key haschen kann und die neue Kurve ED25519 noch nicht von Ubuntu 14.04. unterstützt wird siehe Beispiel:
ssh-keygen -r blog.chr -f /etc/ssh/ssh_host_ed25519_key.pub
export_dns_rr: unsupported algorithm and/or digest_type

So habe ich mir ein Skript geschrieben, das mir alle Fingerprints auf einmal erstellt.

#!/bin/bash

domain="$1"

if [ "$domain" = "" ]; then
	echo $0 domain
	exit 0
fi

function sshfp() {
	a=$1 #algorithmus
	f=$2 #file
	echo $domain IN SSHFP $a 1 $(awk '{print $2}' $f|base64 -d|sha1sum|awk '{print $1}')
	echo $domain IN SSHFP $a 2 $(awk '{print $2}' $f|base64 -d|sha256sum|awk '{print $1}')
}

for f in /etc/ssh/ssh_host_*_key.pub; do
	case "$(echo $f|awk -F '_' '{print $3}')"
	in
	  rsa)
		sshfp 1 $f
		;;
	  dsa)
		sshfp 2 $f
		;;
	  ecdsa)
		sshfp 3 $f
		;;
	  ed25519)		
		sshfp 4 $f
		;;
	esac
done | sort

Die Ausgabe sieht dann folgendermaßen aus:
Read the rest of this entry »

Zum einfach erstellen von DANE DNS Einträge habe ich mir ein Script geschrieben das, dass Zertifikat vom Server (z.b Webserver) abruft und den dazu passenden TLSA record erstellt.

#!/bin/bash
#(c) 2014  Christoph Hueffelmann (blog.chr.istoph.de)
domain=$1 
port=$2
crt=$3

if [ "$port" = "" ]; then
	echo "$0 domain.tld port [path/domain.tld.crt]"
	exit 1
fi
if [ ! -x "/usr/bin/openssl" ]; then
	echo "apt-get install openssl"
	exit 1
fi

if [ "$crt" = "" ]; then
	crt=$(mktemp)
	trap "rm -f $crt" 0 1 2 5 15
	echo QUIT | openssl s_client -servername $domain -connect $domain:$port 2>/dev/null | 
                    sed -ne '/BEGIN CERT/,/END CERT/p' > $crt
fi

#cat $crt
if [ -s $crt ]; then
	echo "_$port._tcp.$domain. IN TLSA 3 0 1 $(cat $crt | openssl x509 -outform DER | 
                                                   openssl sha256 | awk '{print $2}')"
else
	exit 1
fi

exit 0

Alles was man angeben muss ist die Domain und der Port oder optional auch den Pfad zur .crt Datei:
# ./tlsa.sh blog.chr.istoph.de 443
_443._tcp.blog.chr.istoph.de. IN TLSA 3 0 1 253ac080ec87c1a049cc5992e311d3afe39e7554b45ad754438dd7fcaeb22727

Fals man nur den SHA braucht kann man auf folgneden einzeiler verwenden:

echo QUIT | openssl s_client -connect blog.chr.istoph.de:443 | 
sed -ne '/BEGIN CERT/,/END CERT/p' | openssl x509 -outform DER | 
openssl sha256

Anmerken möchte ich natürlich das dies natürlich nicht der weg sein sollte TLSA records für Produktivbetrieb zu erstellen.

[UPDATE 28.01.15]
Das openSSL Kommando ist nun auch mittels der Option -servername SNI fähig.

Um einen Host hinter einer Firewall zu administrieren habe ich ein VPN zwischen den beiden Punkten aufgebaut. Um aber den ausgehenden Netzwerktraffic, der über die Firewall läuft, testen zu können brauchte ich eine Routing via Ports. Genau genommen wollte ich Port 22 durch den VPN Tunnel und den HTTP traffic über das Standard Gateway routen.

Zuerst braucht man eine separate routing table in unserem Fall foo
echo "1 foo" >> /etc/iproute2/rt_tables

In diese routing Tabelle legen wir zuerst eine default route ab
ip route add table foo default dev vpn

Dann braucht man eine rule zum die angibt wann die foo routing Tabelle verwendet werden soll.
ip rule add fwmark 1 table foo

Nun kommen wir zur Auswahl der Pakete, die anders geroutet werden sollen. Dies geschieht über die mangle table. Hier werden die einzelnen Pakte über fwmarks markiert.
iptables -t mangle -A OUTPUT -d 203.0.113.80/32 -p tcp -m tcp --dport 22 -j MARK --set-xmark 0x1/0xffffffff

Damit der Kernel auch die ausgehenden Pakete richtig benennt, werden alle Pakete die über das VPN geroutet werden nun auf die source Adresse des VPNs umgeschrieben.
Dies ist notwendig, da der Kernel beim bestimmen der Absenderadresse unserer TCP Verbindung die firewall Konfiguration bei der Bestimmung der ausgehenden route nicht verarbeitet.
iptables -t nat -A POSTROUTING ! -s 10.8.0.2/32 -o vpn -j SNAT --to-source 10.8.0.2

Zum Schluss müssen wir das reverse path filtering ausschalten, damit die Entgegennahme der Pakete, deren Antwort an ein anderes Interface gehen würde, erlaubt werden.
echo 0 | tee /proc/sys/net/ipv4/conf/*/rp_filter