Mehr Sicherheit fuer die eigenen Daten – Zertifikate

Dieses ist der dritte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann. Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann. Der dritte Teil hier bezieht sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.

Oft probiere ich eine Software aus, erstelle mir fix eine Subdomain, richte einen vHost ein, und entweder das was ich ausprobiere ist gut und es geht in meinen digitalen Alltag ueber, oder eben nicht. Zurueck bleiben verwaiste Subdomains, deaktivierte vHosts und dann natuerlich Applikationen die ich taeglich nutze, und zu denen ich eine unverschluesselte Verbindung aufbaue, obwohl ich es selbst in der Hand habe die Verschluesselung einzustellen.

Ich habe mich an dieser Stelle bewusst gegen eine eigene CA entschieden. Das ist hinten raus sicherlich praktisch, haette meine Einstiegshuerde aber wieder zu hoch gelegt und ich bin mit frueheren Versuchen daran bisher immer an mir selbst und fehlender Kontinuitaet gescheitert. Schlichte einfache selbst signierte Zertifikate sind fuer mich immer noch am einfachsten.

Was ich jedoch gemacht habe, ist, das ich alle Zertifikate bei CAcert signieren lassen habe. Das hat fuer mich den Vorteil, dass ich ueber alle Zertifikate einen Ueberblick habe, und wenn ich will, kann ich mir auch das CAcert Rootzertifikat importieren und einfach denen vertrauen. Gemacht wie folgt:

  1. Key erzeugen:
    openssl genrsa -out example.org.key 4096
  2. CSR erzeugen:
    openssl req -new -key example.org.key -out example.org.csr

    Bei den Fragen ist nur wichtig, dass der „Common Name“ der Name der Domain oder Subdomain ist, die man sichern moechte. Ein Passwort ist nicht einzugeben.

Bei CACert dann den Inhalt der example.org.csr Datei eingeben und das Zertifikat was man angezeigt und per Email zugesendet bekommt unter example.org.crt abspeichern.

Ein einfacher Apache vHost mit SSL sieht wie folgt aus:

<VirtualHost *:443>
ServerAdmin webmaster@example.org
ServerName example.org
DocumentRoot /var/www/example.org
 
SSLEngine on
SSLCertificateFile /path/to/example.org.crt
SSLCertificateKeyFile /path/to/example.org.key
 
CustomLog /var/log/apache2/example.org-access.log combined
</VirtualHost>

Wenn man auf den Dienst nur ueber https zugreifen moechte und eine einfache Weiterleitung von  HTTP auf HTTPS einrichten moechte, kann man das zum Beispiel mit einem kleinen vHost und einer entsprechenden rewrite Regel machen:

<VirtualHost *:80>
ServerAdmin webmaster@example.org
ServerName example.org
DocumentRoot /var/www/example.org
 
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
 
CustomLog /var/log/apache2/example.org-access.log combined
</VirtualHost>

Wenn man Zugriff auf ein Nagios hat, dann ergibt es Sinn das Ablaufdatum des SSL Zertifikates mit zu Ueberwachen, damit man da nicht irgendwann in Probleme rennt. Das folgende Kommando und der folgende Check warnen einen sobald das Zertifikat nur noch 30 Tage gueltig ist.

Command Definition:

define command{
        command_name    check_ssl_certexpire
        command_line    $USER1$/check_http -H $HOSTNAME$ -p $ARG1$  -C 30
        }

Check:

define service{
        use                             my-service
        host_name                       example.org
        service_description             SSL-Cert root
        check_command                   check_ssl_certexpire!443
        }

Mehr Sicherheit fuer die eigenen Daten – verschluesselter Container

Dieses ist der zweite Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann. Der zweite Teil, den ich hier beschreiben moechte, bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.

Es gibt immer Dateien, die muss man sicherer aufbewahren als alle anderen. Das sind zum Beispiel die Keys fuer die Webserver Zertifikate, PGP oder vielleicht auch das ein oder andere Passwort was man sich notieren moechte. Ich habe mich dazu entschlossen das ganze in einer verschluesselten Containerdatei aufzubewahren. Diesen kann ich auch ruhigen Gewissens irgendwo in ein Backup schieben und die Daten liegen nicht frei lesbar herum.

Es war fuer mich wichtig das ganze moeglichst einfach zu halten und nicht so kompliziert in der taeglichen Bedienung. Aus diesem Grund habe ich noch zwei Skripte und Aliase drumherum gebaut, so das ich mit einem simplen Befehl und einem Passwort den Container einhaengen bzw. mit einem weiteren Befehl den Container auch wieder aushaengen kann. Der Reihe nach:

  1. Erzeugen einer 128MB grossen Containerdatei:
    dd if=/dev/urandom of=mycrypt.file bs=1M count=128
  2. Die Datei an ein Loopback Device binden:
    losetup -f
    losetup /dev/loop0 mycrypt.file
  3. Initialisieren und Passwort festlegen:
    cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/loop0
  4. Oeffnen:
    cryptsetup luksOpen /dev/loop0 mycryptcontainer
  5. Dateisystem erzeugen:
    mkfs.ext4 /dev/mapper/mycryptcontainer

Jetzt kann man die Datei mounten und es als ganz normales Device nutzen:

mount -t ext4 /dev/mapper/mycryptcontainer /home/user/crypt

Wieder entfernt wird es mit den folgenden Befehlen:

umount /home/user/crypt
cryptsetup luksClose mycryptcontainer
losetup -d /dev/loop0

Das ganze soll ja aber einfach sein. Aus diesem Grund habe ich mir zwei Skripte angelegt:

  • /usr/local/sbin/mountContainer.sh
#!/bin/sh
 
SAFE=/home/user/Dokumente/mycrypt.file
CRYPTNAME=mycryptcontainer
MNT=/home/user/crypt
FS=ext4
LOOPDEV=$(losetup -f)
 
if [ "$(losetup -a | grep -c "$SAFE")" != "0" ]; then
        echo "bereits eingehängt"
        exit
fi
 
/sbin/losetup $LOOPDEV $SAFE
/sbin/cryptsetup luksOpen $LOOPDEV $CRYPTNAME
/bin/mount -t $FS /dev/mapper/$CRYPTNAME $MNT
  • /usr/local/sbin/umountContainer.sh
#!/bin/sh
 
SAFE=/home/user/Dokumente/mycrypt.file
CRYPTNAME=mycryptcontainer
MNT=/home/user/crypt
LOOPDEV=$(losetup -a | grep "$SAFE" | sed "s/: .*//")
 
if [ "$(losetup -a | grep -c "$SAFE")" != "1" ]; then 
	echo "nicht eingehängt"
	exit
fi
 
/bin/umount $MNT
/sbin/cryptsetup luksClose $CRYPTNAME
/sbin/losetup -d $LOOPDEV

Nicht vergessen sie ausfuehrbar zu machen:

chmod 750 /usr/local/sbin/*mountContainer.sh

Da die Skripte mit root rechten aufgerufen werden muessen habe ich mir weiter die folgende Datei erzeugt:

  • /etc/sudoers.d/90_mycryptcontainer
user     host = NOPASSWD: /usr/local/sbin/mountContainer.sh
user     host = NOPASSWD: /usr/local/sbin/umountContainer.sh

und noch die Rechte dafuer setzen:

chown root.root /etc/sudoers.d/90_mycryptcontainer
chmod 0440 /etc/sudoers.d/90_mycryptcontainer

Zu guter Letzt noch zwei Aliase in meiner ~/.bash_aliases angelegt und voilà:

alias mcrypt='/usr/bin/sudo /usr/local/sbin/mountContainer.sh'
alias umcrypt='/usr/bin/sudo /usr/local/sbin/umountContainer.sh'

Jetzt kann ich mit den Befehlen mcrypt und umcrypt den Container ein- und aushaengen und kann vor allem die verschluesselte Containerdatei ruhigen Gewissens ins Backup packen.

Die hier beschriebenen Schritte stammen groesstenteils aus dem Wikieintrag Containerdatei von ubuntuusers.de.

SSH – Keys und Agent

SSH gehoert fuer mich zum taeglich Brot. Gefuehlte 1.000.000 mal taeglich baue ich Verbindungen zu irgendwelchen Servern auf, mache dort etwas, baue die Verbindung wieder ab usw… Etwas was mir mein Leben dabei sehr stark erleichtert ist die ~/.ssh/config in der ich fuer die entsprechenden Server die Voreinstellungen hinterlegt habe. Vor vielen Jahren hatte ich darueber bereits hier auf dem Blog geschrieben.

Authentifizierung ueber Keys ist ein weiteres Thema das das Leben sehr viel erleichtern kann. Deswegen hier kurz was dazu geschrieben. Als erstes benoetigt man einen Key. Der wird mit dem folgenden Befehl erzeugt:

ssh-keygen -t dsa

Dabei wird zur Eingabe eines Passworts aufgefordert, wenn man nicht sehr triftige Gruende dagegen hat sollte man das auch tun. Als zweites muss der public Key auf den betreffenden Server kopiert werden, z.B.:

scp ~/.ssh/id_dsa.pub username@example.net:/home/username/.ssh/authorized_keys2

Nun kann ich mich schon mit

ssh username@example.com

ueber den Key (mit dem Passwort des Keys) authentifizieren. Noch einfacher wird es jedoch, wenn man diese Identity dem SSH-Agent mitteilt. Das passiert mit dem Befehl:

ssh-add

Nach der Eingabe des Passworts fuer den Key uebernimmt der Agent alles weitere fuer einen. Man kann sich nun mit dem Key ohne Angabe des Passworts an dem Server anmelden, bis der Agent neu gestartet wird.

Natuerlich kann man auch mehr als einen Key haben, z.B. um private und dienstliche Sachen voneinander zu trennen:

ssh-keygen -t dsa .ssh/work
ssh-add .ssh/work

Die aktiven Identitys kann man sich uebrigens mit

ssh-add -l

anzeigen lassen