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.

Mehr Sicherheit fuer die eigenen Daten – Einleitung und Aufraeumen

Im Kontext der NSA Affaere ist viel ueber Sicherheit und Verschluesselung geschrieben worden. Etwas zu aendern ist schwer, denn es koennen sich nur die Menschen aendern, die Dienste werden es nicht tun. Die Nutzer muessen das Thema Verschluesselung selbst in die Hand nehmen. Fuer viele ist das eigentlich unmoeglich, weil sie schlichtweg keine Ahnung haben. Fuer Menschen wie Dich und mich, die eigene Server betreiben, ist es jedoch machbar. Ich werde in der kommenden Zeit und in unregelmaessigen Abstaenden hier auf meinem Blog verschiedene Dinge vorstellen, die als direkte Reaktion aus diesen Ueberlegungen hervorgegangen sind.

Eine 100%tige Unabhaengigkeit ist nicht zu erreichen. Aber jeder kleine Schritt dahin ist richtig. Wir wollen alle kommunizieren ueber die Netze, und in der Regel bezahlen wir mit unseren Daten fuer die Services die wir nutzen. Das bedeutet im Umkehrschluss, dass wenn wir nicht mit unseren Daten bezahlen, wir auch keine Premiumdienste erwarten koennen die super einfach von der Hand gehen.

Der erste Schritt war fuer mich das Aufraeumen. Ich bin meine Rootserver durchgegangen und habe folgendes gemacht:

  1. Alle Zugaenge von mir und fuer Freunde ueberprueft die existierten und gegebenfalls gesperrt.
  2. Ich bin die Prozesstabelle durchgegangen und habe sichergestellt, dass ich keine Dienste laufen habe, die ich nicht laufen haben moechte. Gegebenenfalls habe ich diese deinstalliert.
  3. Ich bin im Apache alle vHosts durchgegangen und habe dort aufgeraeumt. Nicht mehr benoetigte deaktiviert und Konfigurationen angeglichen
  4. Ich habe meine DNS Konfigurationen durchgeschaut und sichergestellt, dass keine verwaisten Subdomains existieren etc.
  5. Ich bin das Dateisystem durchgegangen, habe mein Homeverzeichnis aufgeraeumt, die DocumentRoots der vHosts usw.

Kurz: Aufraeumen um eine gute Grundlage, einen Ueberblick, eine gute Struktur zu schaffen fuer die naechsten Arbeiten im Kontext Verschluesselung, die ich machen wollte. Stay tuned….

SELinux Notizen

  1. sestatus -> Zeigt Statusinformationen von SELinux an
  2. getenforce -> Zeigt nur den aktuellen Zustand von SELinux an. Enforcing bedeutet es laeuft, Permissive bedeutet, das es deaktiviert ist
  3. setenforce -> Aendert den Zustand von SELinux. Uebergibt man den Parameter 0 ist es im Permissive mode. Uebergibt man den Parameter 1 ist es im Enforcing mode. Kann man mit dem Tool getenforce ueberpruefen.
  4. getsebool -a -> Zeigt alle verfuegbaren SELinux Optionen inklusive dessen Status (on | off) an.
  5. getsebool httpd_can_network_connect -> Zeigt nur den Status der SELinux Option http_can_network_connect an
  6. setsebool  httpd_can_network_connect on -> Setzt fuer die SELinux Option die httpd_can_network_connect den Status on
  7. Der Schalter -P bei setsebool sorgt dafuer, dass eine Aenderung auch PERSISTANT ist, also ueber einen reboot hinaus aktiv, Beispiel: setsebool  -P httpd_can_network_connect on
  8. Die Logdatei von SELinux heisst zum Beispiel auf einem CentOS 6.4 audit.log und liegt unter /var/log/audit/audit.log
  9. ls -Z -> zeigt SELinux Security Context einer Datei an
  10. ps axZ -> zeigt SELinux Security Daten eines Prozesses an