dckg.net
Blog
Tools
Downloads
Sonntag, 31 Juli 2016 in Kryptographie, Linux, Sicherheit
Server Vollverschlüsselung
Nach langer Zeit bin ich nun endlich dazu gekommen, das Thema Server Vollverschlüsselung anzugehen.
Wozu überhaupt Vollverschlüsselung? Damit nur ich Zugriff auf meine Daten habe.
Was ist zum Beispiel, wenn die HDD nach Defekt vom Hoster getauscht werden muss? Oder ich kündige?
Wayne. Ist ja nur noch Datenschrott. Sofern verschlüsselt wurde.

Ein reines Debian Minimalsystem nutzen zu können, nicht die Images vom Hoster nehmen zu müssen, spricht auch für ein eigenes Setup.

Welche Möglichkeiten gibt es?
Der Debian Installer liefert schon alles mit, um bequem per GUI ein verschlüsseltes System aufzusetzen.
Wenn man nicht gerade eine KVM zum Booten des Installer-Images auf den Server zur Verfügung hat, ergibt sich zudem das Problem, den Server zu entsperren - Was auf einem Desktoprechner problemlos funktioniert (Passwort Eingabe) ist für einen Server schlicht nicht machbar.
Zum Rechenzentrum fahren würde ja noch gehen, aber rein lassen die mich garantiert nicht.

Ergo muss das Entsperren irgendwie über das Netzwerk realisiert werden.
Dropbear und Busybox erfüllen diese Aufgabe, ersteres ist ein schlanker SSH-Server, letzteres eine minimale Linuxumgebung.
Zusammen werden sie ins initramfs geladen, wo sie noch vor dem Eigentlichen, verschlüsselten System, geladen werden.
Dort wird sich dann normal per SSH eingeloggt und das Passwort in eine Pipe geschrieben:

echo -n "PASSWORD_HERE" > /lib/cryptsetup/passfifo


Bei meiner Internetrecherche habe ich leider keine fertige Lösung gefunden.
Ich musste also selbst Hand anlegen. Entstanden ist dieses Skript.
Vorgehensweise ist immer, den Server in ein Rettungssystem zu booten, und von dort das Skript auszuführen, sowie die weitere Konfiguration vorzunehmen.

Sicherheitstechnisch gesehen könnte das Recovery-Image vom Hoster eine Backdoor enthalten.
Also müsste ich Platz in einem Server-Rack anmieten und dort meine eigene Hardware reinstellen.
Nun traue ich den Leuten im Rechenzentrum nicht.
Insofern bräuchte ich mein eigenes Rechenzentrum. Mit eigenem Personal.

Man sieht, wo das hinführt. Absolute Sicherheit gibt es nicht. Ich bin mit meiner Lösung trotzdem mehr als zufrieden.

Unterstützt wird sowohl UEFI/EFI, als auch BIOS, wenn Verschlüsselung aktiviert wird, wird LVM statt auf der realen Festplatte auf dem verschlüsselten Volume eingerichtet. RAID habe ich leider derzeit nicht, ansonsten läge ganz unten, über der Festplatte, das RAID-Array und darauf dann das verschlüsseltes Volume, darin LVM.
dm-crypt, LVM, mdadm (Software RAID), benutzen alle den Device-Mapper, der echte, physische Laufwerke, in virtuelle Laufwerke abstrahiert.
Zu finden sind diese dann im Verzeichnis /dev/mapper. Hiermit lassen sich RAID, LVM, LUKS verschlüsselte Partitionen beliebig ineinander verschachteln.

Zum Ende hin ist das Skript etwas eskaliert, ein chroot in einem chroot. 😂
Der Hoster hat nämlich kein aktuelles Debian-Rettungssystem.
Virtualisierung ist mal wieder die Lösung:
Das Skript erstellt eine Ramdisk, lädt dort zuerst das aktuelle debootstrap mittels wget herunter, installiert es mit ar und tar.
Mehr muss auf dem Live-System nicht vorhanden sein.

Anschließend installiert debootstrap ein minimales Debian System mit den später benötigten Tools auf die Ramdisk.
Debian zuerst auf eine Ramdisk zu installieren, beschleunigt den Installationsprozess enorm, da das Entpacken und die Konfiguration der Pakete sehr IO-lastig ist.
Darauf folgend kopiert sich das Skript selbst mit auf die Ramdisk, macht chroot auf die Ramdisk und führt sich selbst noch einmal aus (im eben installierten Debian System).
Was auf dem Host an Programmen (nicht) vorhanden ist, wird somit völlig irrelevant.

In der Ramdisk, aus diesem Debian System heraus wird nun die Host-Festplatte formatiert.
Erneut wird ein chroot erstellt, diesmal auf den mit GPT und LVM partitionierten Datenträger, in das dass Debian System aus der Ramdisk via rsync kopiert wird, und die endgültige Konfiguration des Systems vorgenommen wird.

Warum LVM und GPT?
Normale Partitionierung mit MS-DOS unterstützt nur 4 Primäre Partition und Festplatten bis zu einer Größe von 2 TB.
Mit GPT an sich können ein paar hundert Partitionen angelegt werden, HDDs > 2TB sind möglich.

LVM, der Logical-Volume-Manager abstrahiert HDDs und Partitionen in PVs (Physical Volumes), VGs (Volume Groups), und LVs (Logical Volumes).
Während das System läuft, können Laufwerke zusammengefasst, Partitionen neu angelegt, vergrößert oder verkleinert werden.
Zudem bietet es fortgeschrittene Features wie RAID und Snapshots.
Steigende Abstrahierung, Komplexität heißt selbstverständlich auch mehr potentzielle Fehlerquellen.

Nachdem das Skript seine Arbeit vollendet hat:

Zu beachten gilt es die IP-Konfiguration im initramfs, wenn der eigene Hoster kein DHCP für die IPv4 Adresszuweisung verwendet: Nachzulesen in den Kernel-Docs: Pre-Boot IP-Adresse setzen

Späteres entsperren (Pre-Boot-Authentication) und nutzen des Systems:

Oben im Bild zu sehen ist eine VM, die den Server darstellen soll. Unten eine lokale Konsole.
Der Server bootet zuerst in das Busybox-System, startet den Dropbear SSH-Server und bezieht eine IPv4-Adresse.
Zu diesem Zeitpunkt kann ich mich mit dem Dropbear Private-Key beim Server einloggen; das Passwort an Cryptsetup übermitteln.
Dasselbe verhalten, als hätte ich das Passwort über die Tastatur eingegeben.
Die verschlüsselte LVM Partition wird entsperrt, auf der sich neben dem Root-Dateisystem sämtliche Daten befinden.
Mit exit kann die Busybox verlassen werden und sich in wenigen Sekunden über reguläres SSH mit dem richtigen Serversystem verbunden werden.

Bis auf den Entsperrprozess nach Neustart des Systems sind keine weiteren Schritte erforderlich.
Snippet:

# unlock
ssh -o FingerprintHash=md5 -o UserKnownHostsFile=~/.ssh/known_hosts_initramfs -i ~/.ssh/id_rsa_dropbear host \
"echo CONNECTED; echo -n "your_password_here" > /lib/cryptsetup/passfifo; exit";
sleep 15;

# normal use
ssh -o FingerprintHash=md5 host;


Jetzt habe ich mal ein Linux-System from scratch aufgesetzt, so langsam könnte ich mich Richtung Archlinux wagen.
Site optimised for Google Chrome / Chromium