Warnung: Diese Seite ist eine statische Kopie eines früher betriebenen Blogs. Es findet keine Aktualisierung mehr statt. Kommentare und die Suche funktionieren nicht.
Linux, Server & Co
Nachdem es mit ALT Linux nun schon ein russisches Linux gibt, hier die Root-Shell Version von Russisches Roulette:
if [ $[$RANDOM % 6] == 0 ] then echo "Oh oh..."; rm -rf / else echo "Next try"; fi
WARNUNG: Das Script erwartet gute Shell-Kenntnisse. Wer die Zeile nicht versteht, sollte sie unter keinen Umständen ausprobieren, denn das Script löscht Daten! Jede Haftung durch den Autor wird abgelehnt, die Benutzung erfolgt auf eigene Gefahr!
Mit dm-crypt / LUKS lassen sich unter Linux Festplatten oder Partitionen verschlüsseln. Die Details sind auf Wikipedia zu finden, dieser Artikel soll zeigen, wie einfach es einsetzbar ist.
Wir gehen von einer normalen Debian Lenny installation aus. Ich habe sda in 3 Partitionen unterteilt: Swap (2 GB), Root-FS (10 GB) und /home (Rest). Die dritte Partition werde ich verschlüsseln.
Zuerst installieren wir die Software und laden das nötige Kernel-Modul. Dies ist beim Einrichten einmalig manuell nötig, beim späteren Öffnen des Containers wird das Modul automatisch geladen:
apt-get install cryptsetup modprobe dm_crypt
Nun starten wir die Einrichtung:
cryptsetup luksFormat /dev/sda3
Mit luksOpen öffnen wir den verschlüsselten Bereich. Dadurch entsteht ein neues Gerät namens /dev/mapper/{name} welches das „geöffnete“ /dev/sda3 repräsentiert, jedoch in nichtverschlüsselter Form. Wir benutzen also künftig /dev/mapper/{name}, wobei alles, was wir dorthin speichern transparant verschlüsselt und nach /dev/sda3 geschrieben wird.
cryptsetup luksOpen /dev/sda3 private
Wir haben der Partition also nun den Gerätenamen ‚privat‘ gegeben, daher finden wir unsere lesbare „Partition“ nun unter /dev/mapper/private. Nun formatieren wir die Partition:
mkfs.xfs -L sda3-priv /dev/mapper/private
Fertig, schon kann die Partition gemountet und genutzt werden:
mount /dev/mapper/private /home
Was ich an dieser Stelle gerne empfehle ist das vollständige Überschreiben der Festplatte. Beim luksFormat wird der Bereich nämlich nicht überschrieben, es wird nur der leere Index angelegt. Die zuvor unverschlüsselt gespeicherten Daten sind also noch rekonstruierbar.
Das „Ausnullen“ (Überschreiben mit lauter 0x00 Bytes) vermeide ich hier, da ein Angreifer sonst verschlüsselte und unverschlüsselte Daten großer Teile der Platte kennen könnte und somit gezielt nach dem Schlüssel suchen könnte. Daher benutze ich hier /dev/urandom:
dd if=/dev/urandom of=/home/fillup.dat bs=1M rm /home/fillup.dat
Eine interessante Sache übrigens: Das Füllen mit Zufallsdaten könnte theoretisch auch vor dem luksFormat direkt auf /dev/sda3 erfolgen, man könnte sogar annehmen, dass dies schneller geht, weil die Zufalldaten dann nicht verschlüsselt geschrieben werden müßten. Da die Verschlüsselung jedoch die Entropie der Zufallszahlen ganz vewaltig in die Höhe treibt, geht das Erzeugen von Zufallszahlen beim Überschreiben des gecrypteten Bereiches in der Tat schneller als beim Überschreiben der Platte sda3.
Meine Messwerte:
| Überschreiben von /dev/sda mit /dev/urandom: | 5.4 MBit/s |
| Datei im XFS-Dateisystem von /dev/urandom anlegen, welches als /dev/mapper/private eingehängt ist und die Daten beim Schreiben auf /dev/sda verschlüsselt: | 6.0 MBit/s |
So, um die Partition nach dem Entmounten wieder zu „schließen“, also das Mapper Device wieder zu entfernen, damit nicht mehr auf die Daten zugegriffen werden kann, wird das Kommando luksClose genutzt:
umount /dev/mapper/private cryptsetup luksClose private
Durch einen Reboot ist das Laufwerk übrigens auch geschlossen, wenn also jemand mit lokalen Zugang zum PC kein Passwort hat, wird er künftig keine Daten aus /home mehr auf dem Rechner finden, denn selbst ein Reboot mit init=/bin/bash ist nun wirkungslos.
Fertig ist das streng geheime Home-Verzeichnis – was übrigend auch mit jedem anderen Verzeichnis klappt – zumindest solange es kein System-Verzeichnis ist, welches zum Booten schon benötigt wird.
TIPP: Ein Blick ins Manual von cryptsetup ist übrigens sehr zu empfehlen. Hier wied auch verraten, wie man mit den luks*Key Kommandos mehrere Passwörter anlegen (z.B. für mehrere Leute, jeder hat SEIN Passwort) oder wie man mit Key-Files (z.B. auf dem USB-Stick) arbeiten kann. Auch Scripting ist dank isLuks und luksUUID problemlos möglich…
Ein normales Image einer Partition kann mit losetup zum Loop-Device gemacht werden und so über /dev/loopX als Gerät angesprochen und z.B. gemountet werden. Schwieriger wird es jedoch, wenn das Loop-Device eine komplette Platte inklusive Partitionen enthält.
Ein einfaches Beispiel: Ein mit „dd if=/dev/sda of=/imagefile“ erstelltes Image kann zwar mit losetup zu /dev/loop0 gemacht werden, jedoch ist ein direktes Ansprechen der Partitionen, die ehemals auf /dev/sda existierten, nicht möglich. Dazu müßte es ja ein /dev/loop0_1, /dev/loop0_2 oder /dev/loop0_3 geben.
Gut, möglich ist es schon, denn losetup kann mit –offset auch nur Teile der Image-Datei als Loop-Device nutzen, nur müßte man so auf’s Byte genau die Partitionen finden, wobei ein Irrtum möglicherweise die Daten vernichten würde.
Diese Aufgabe löst kpartx. Der Einsatz ist ganz einfach: Installieren und loslegen.
apt-get install kpartx kpartx -av /imagefile oder kpartx -av /dev/loop0
Schon stehen unter /dev/mapper je Partition ein Loop-Device zur Verfügung, also zum Beispiel:
Der Parameter -a steht für add, das v dagegen für verbose, so dass ich gleich sehe, was er mir angelegt hat. Mit dem Parameter -l zeigt man die Mappings an, mit -d löscht man sie wieder.
Typischer Anwendungszweck:
Mit losetup kam ich noch gut klar. Als ich jedoch das erste mal ein Image erstellt habe und darin eine virtuelles Debian von einer virtuellen CD (.ISO-Datei) installierte, hat mir dieses in der Image-Datei mehrere Partitionen angelegt. Hier war kpartx meine Rettung, denn so konnte ich noch auf die Daten im Image-File zugreifen.