HowTo: Backup von LUKS Headerdaten erzeugen / zurueckspielen

Heute morgen kam ich zur Arbeit und mein Rechner wollte das Passwort zum entschluesseln der mit LUKS verschluesselten Festplatten nicht mehr annehmen. Nach einer Stunde probieren aller erdenklichen Moeglichkeiten habe ich mich dann dazu entschieden den PC komplett neu aufzusetzen. Zum Glueck ist nur sehr wenig verloren.

Warum ich in der letzten Woche jeden Morgen das Passwort eingeben konnte und es heute morgen nicht mehr ging ist ein Raetsel. Vielleicht haette mir ein Backup der LUKS Headerdaten geholfen. Ich hatte aber keines, bis gerade eben.

Erzeugen:

cryptsetup luksHeaderBackup /dev/disk/by-uuid/XXXX --header-backup-file /tmp/backupname.luksheader

Wieder einspielen:

cryptsetup luksHeaderRestore /dev/disk/by-uuid/XXXX --header-backup-file /tmp/backupname.luksheader

Mehr Sicherheit fuer die eigenen Daten – vollverschluesselte Festplatten auf Servern

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

Links zu den ersten acht Artikeln befinden sich am Ende des Blogposts. Im neunten Teil moechte ich meine Ueberlegungen zu selbstgehosteten Servern und deren Sicherheit im Kontext Verschluesselung der Festplatten vorstellen.

Wenn ich eine verschluesselte Verbindung zu einem anderen Rechner / Dienst im Internet aufbaue kann ich das ungewollte Mitlesen der Kommunikation erschweren bis verhindern. Speichere ich nun die Daten auf eigenen Servern und vertraue sie nicht Firmen wie Google (Mail, Drive), Microsoft (Outlook.com, Skydrive) oder Amazon Cloud (Dropbox) an, dann erschwere ich auch erst einmal das ungewollte Lesen meiner Daten. Ich bin ja schliesslich kein Administrator auf dem anderen Server und weiss nicht wann sich wo auf deren Seite jemand potentiell dazwischen schaltet.

Meine Daten liegen also auf einem selbstgehosteten Server und ich baue eine verschluesselte Verbindung dahin auf. Die Daten auf dem Server selbst sind aber immer noch unverschluesselt gespeichert. Es kann also potentiell jemand ins Rechenzentrum gehen, sich den Server schnappen, analysieren und die Daten dort herunter ziehen. Was liegt da naeher als die Festplatten zu verschluesseln.

Mit LUKS (klick) steht dafuer unter Linux auch eine gute Loesung zur Verfuegung. Auf meinem Laptop oder meinem Arbeitsplatzrechner setze ich sie bereits ein. Ist ja auch kein Problem beim Booten das Passwort einzugeben. Das bei einem Server zu tun ist es schon sehr viel umstaendlicher, denn man sitzt ja eigentlich nie direkt davor…

Ich werde hier nun keine Anleitung schreiben wie man die Schritte 1:1 geht um seine Festplatte mit LUKS zu verschluesseln. Davon gibt es bereits genuegend im Netz. Einige Distributionen wie Debian bieten es sogar im Installer gleich an die Festplatte mit LVM zu erzeugen und dann mit LUKS zu verschluesseln. Die Stichworte beim Suchen nach entsprechenden Dokumentationen sind Distributionsname + „LUKS“ oder „cryptsetup“ oder „encrypted filesystem“. Nicht zu vergessen auch unter /usr/share/doc/cryptsetup/ nach zuschauen!

Der Clou an der Geschichte ist nun, das man einen dropbear SSH Server in die initramfs seines Servers hinzufuegen kann. So ist es moeglich waerend des Bootvorgangs eine SSH Verbindung in die initramfs aufzubauen und dort das Passwort zum entschluesseln der Festplatte einzugeben. Damit das ganze komfortabel wird, nutze ich dafuer SSH-Keys ohne Passwort in Verbindung mit einem Miniskript pro Maschine.

Boese boese mag sich nun mancher denken, aber alles halb so wild. Ich habe eine Maschine die ist unverschluesselt. Einfach, weil Sie es nicht benoetigt und dort nichts wichtiges abgespeichert ist. Auf dieser Maschine habe ich einen Ordner mit ecryptfs verschluesselt (klick fuer Anleitung). In diesem Ordner bewahre ich folgendes auf:

  1. private Keys fuer die Verbindung zu dem Dropbear Servern im initramfs der virtuellen Maschinen
  2. eigene known_hosts Datei dafuer
  3. Ein Skript pro VM das mir die Eingabe des Passworts erleichtert.

Das Skript sieht schematisch wie folgt aus:

#!/bin/bash
 
ssh -o "UserKnownHostsFile=known_hosts/known_hosts.initramfs" -i "keys/servername" root@1.2.3.4 "echo -ne "**TOPSECRET**" >/lib/cryptsetup/passfifo"

Wenn ich nun einen Server neu starte bei dem die Festplatte verschluesselt ist, dann melde ich mich auf der unverschluesselten Maschine an, mounte den ecryptfs verschluesselten Ordner und muss dann nur noch das entsprechende Skript starten, z.B. ./unlock_servername und schon bootet die Maschine durch.

In diesem Kontext sicherlich noch einmal spannend ist auf einen drei Jahre alten Blogeintrag „Howto: virsh console“ zu verweisen um sich das ganze auch vom physikalischen Server aus anzuschauen ;-)

Vorherige Blogposts:

  • 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 bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.
  • Der vierte Teil drehte sich um das Thema Komfort im Webbrowser und verwies in dem Kontext auf einen Artikel zum selbst gehosteten Firefox Sync Server.
  • Im fuenften Teil habe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern geschrieben.
  • Im sechsten Teil dreht es sich darum, wie man sich auf seinen Servern mit SSH aber ohne Passwort sicher authentifizieren kann.
  • Der siebte Teil behandelt das Thema Backup und zeigt eine Moeglichkeit wie man selbiges einfach konfiguriert und verschluesselt auf einem externen Speicher ablegen kann.
  • Der achte Teil stellt webbasierte Dienste vor, die man selber hosten kann und dadurch die eigenen Daten unter mehr Kontrolle hat.

HowTo: Change password on LUKS encrypted device

LUKS erlaubt bis zu 8 Keys, die in Slot 0-7 gespeichert werden koennen. Welche Slots belegt sind sieht man mit:

cryptsetup luksDump /dev/devicename

Einen neuen Key kann man mit dem folgenden Kommando hinzufuegen:

cryptsetup luksAddKey /dev/devicename

Einen vorhandenen Key kann man mit dem folgenden Kommando loeschen:

cryptsetup luksRemoveKey /dev/devicename

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.