Remote Linux Partitionen verschlüsseln

Wenn man einen Server aufsetzt, auf dem potentiell auch persönliche Daten (z.B. E-Mails) abgelegt werden sollen, kommt man früher oder später an den Punkt, an dem man sich über die Sicherung dieser Daten Gedanken macht. Für die permanente Verschlüsselung auf der Festplatte gibt es inzwischen glücklicherweise gute Standardtools, die einem viel Arbeit abnehmen können. 🙂

Um sie nutzen zu können, muss man sie jedoch erst einmal installieren. Dazu könnt ihr (unter Debian) folgenden Befehl nutzen:

1
sudo aptitude install cryptsetup

Beginnen wir mit etwas einfachem. Zuerst einmal wollen wir die Swap-Partition verschlüsseln. Was bringt es uns, die Daten zu verschlüsseln, wenn sie bei Speichermangel trotzdem unverschlüsselt auf der Platte landen? Hierfür deaktivieren wir erst einmal die derzeit verwende Swap-Parrtition:

1
sudo swapoff -a

Anschließend gehen wir in die Datei "/etc/fstab" und sehen uns an, wie das Swap-Device heißt. In meinem Fall (da ich ein Software-RAID verwende) finde ich folgende Zeile:

1
/dev/md/0 none swap sw 0 0

Das Device heißt bei mir also "/dev/md0". Hier könnte auch "/dev/sda1" oder soetwas stehen. Das hängt ganz von eurer Plattenkonfiguration ab! Diese Zeile könnt ihr übrigens gleich auskommentieren und die Datei durch folgende, neue Zeile ergänzen:

1
/dev/mapper/cswap none swap sw 0 0

Als nächstes gehen wir nun in die (während der Installation von cryptsetup angelegte) Datei "/etc/crypttab". Dort können wir verschlüsselte Devices definieren, die während dem Hochfahren geöffnet werden sollen. Hier tragt ihr nun eine neue Zeile ein:

1
cswap /dev/md0 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap

Denkt daran, den Devicenamen "/dev/md0" durch den zu ersetzen, den ihr in eurer "/etc/fstab" Datei gefunden habt (also z.B. "/dev/sda1")!

Bevor ihr die Partition tatsächlich nutzt, solltet ihr sie noch einmal mit Zufallsdaten überschreiben, um sicher zu gehen, dass sich dort nicht bereits Daten befinden, die ausgelesen werden könnten. Einfache Gemüter können einen BadBlocks-Lauf mit Zufallsdaten durchführen:

1
sudo badblocks -c 10240 -s -w -t random -v /dev/md0

Denkt daran, "/dev/md0" wieder durch euer richtiges Device zu ersetzen! Paranoide Gemüter können natürlich per DD bessere Zufallsdaten schreiben lassen:

1
sudo dd if=/dev/urandom of=/dev/md0 bs=10240

Denkt auch hier daran, "/dev/md0" durch euer richtiges Device zu ersetzen! Wenn ihr damit fertig seid, könnt ihr auch schon anfangen, eure verschlüsselte Swap-Partition zu nutzen. Dazu führt ihr folgende Befehle aus:

1
2
sudo /etc/init.d/cryptdisks restart
sudo swapon -a

Um zu gucken, ob alles funktioniert hat, könnt ihr folgenden Befehl nutzen:

1
sudo cat /proc/swaps

Hier sollte nun im Idealfall folgendes ausgegeben werden:

1
2
Filename    Type        Size       Used   Priority
/dev/dm-0   partition   67107760   0      -1

Es ist möglich, dass hier anstelle von "/dev/dm-0" ein anderes Device steht. Es sollte allerdings unbedingt mit "/dev/dm-" beginnen! Auch die Werte "Size", "Used" und "Priority" könnten bei euch anders sein. Falls dort jedoch immernoch etwas wie "/dev/sda1" steht, ist etwas schief gelaufen!

Kommen wir nun zur Verschlüsselung einer Datenpartition. Auch hierzu solltet ihr wieder in die Datei "/etc/fstab" gehen und das richtige Device heraussuchen. In meiner Datei befindet sich dort die passende Zeile:

1
/dev/md/2 /daten ext4 defaults 0 0

In meinem Fall heißt das Device also "/dev/md2". Darüber hinaus ist es bei mir als Ordner "/daten" gemounted und ist als EXT4-Dateisystem formatiert. Das hängt natürlich wieder von eurer jeweiligen Konfiguration ab! Dort könnte also als Device "/dev/sdb2", als Mountpoint "/tmp" und als Dateisystem "ext3" stehen oder ähnliches. Ihr könnt die Zeile nun auskommentieren - ihr werdet das Device später mit einem eigenen Script laden und mounten.

Als nächstes könnt ihr mit folgendem Befehl gucken, ob das entsprechende Device noch gemounted ist:

1
sudo df

Sollte sich in der Konsolenausgabe eine Zeile mit dem Devicenamen (z.B. "/dev/md2") und dem Mountpoint (z.B. "/daten") befinden, müsst ihr das Device zuerst unmounten - in meinem Beispiel mit:

1
sudo umount /daten

Als nächstes überschreiben wir die Partition wieder mit Zufallsdaten. Achtung! Ihr verliert durch diesen Schritt sämtliche Daten, die auf dieser Partition gespeichert sind! Hier wieder die jeweiligen Befehle. Ihr müsst "/dev/md2" durch euren entsprechenden Devicenamen ersetzen:

1
sudo badblocks -c 10240 -s -w -t random -v /dev/md2

...oder...

1
sudo dd if=/dev/urandom of=/dev/md2 bs=10240

Als nächstes erstellen wir bereits die neue Partition. Hierfür führen wir nacheinander folgende Befehle aus. Der erste Befehl fragt, ob ihr wirklich fortfahren wollt und bittet euch dann um die Eingabe eines Passwortes. Dieses Passwort ist sehr wichtig! Ihr werdet es zukünftig brauchen, um auf die Partition zugreifen zu können. Ihr solltet ein sicheres Passwort verwenden! Von diesem Passwort hängt die Sicherheit der Verschlüsselung ab! Leicht erratbare Passwörter bringen mehr Schaden als Nutzen. Vergewissert euch zudem, dass der Devicename korrekt ist und ersetzt "/dev/md2" entsprechend!

1
2
3
4
sudo cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 /dev/md2
sudo cryptsetup luksOpen /dev/md2 cdaten
sudo mkfs.ext4 -m0 /dev/mapper/cdaten
sudo cryptsetup luksClose cdaten

Nachdem mit dem ersten Befehl das neue verschlüsselte Device angelegt (und entsprechende Header auf die Platte geschrieben wurden), wurde mit dem zweiten Befehl das Device geöffnet - dafür musstet ihr das vorher eingerichtete Passwort kennen. Danach wurde auf diesem Device ein Dateisystem (EXT4) eingerichtet. Abschließend wurde das Device wieder geschlossen. Super! Damit habt ihr euer verschlüsseltes Device erstellt!

Normalerweise würde man die verschlüsselte Partition nun in der Datei "/etc/crypttab" hinterlegen, damit sie beim Hochfahren automatisch geöffnet und gemounted wird. Bei einem Remote-System, das wir nur per SSH erreichen, haben wir jedoch das Problem, dass wir beim Bootvorgang gar nicht die Möglichkeit haben, das benötigte Passwort einzugeben. Bei der Swap-Partition konnten wir das tun, da wir dort einfach bei jedem Start ein neues Passwort (aus "/dev/urandom") erzeugen. Für die Swap-Partition ist das nicht problematisch - die Daten werden nach dem Neustart sowieso nicht mehr benötigt. Bei allen anderen Partitionen würde dies jedoch einen vollständigen Datenverlust nach jedem Reboot bedeuten.
Man könnte nun natürlich anfangen und Schlüsseldateien hinterlegen. Dadurch würde jedoch das ganze System gebrochen werden. Denn auch jeder externe Angreifer könnte sich diesen Schlüssel (der ja unverschlüsselt vorliegen muss) von der Platte holen.

Aus diesem Grund gehen wir den einfachen Weg: Wir erstellen uns ein Script, das das Öffnen und Mounten des Devices für uns übernimmt. Dieses müssen wir lediglich nach jedem Reboot einmal ausführen, um unser System wieder in einen arbeitsfähigen Zustand zu bringen:

1
2
3
sudo mkdir -p /daten
sudo cryptsetup luksOpen /dev/md2 cdaten
sudo mount /dev/mapper/cdaten /daten

Ersetzt den Devicenamen und den Mountpoint durch das, was ihr benötigt (z.B. durch das, was vorher in eurer "/etc/fstab" Datei stand). Ihr solltet euch zudem ein Script anlegen, das ihr immer dann ausführt, wenn ihr das System herunterfahren wollt. Auch dieses müsst ihr an eure Bedürfnisse anpassen:

1
2
3
cd /
sudo umount /daten
sudo cryptsetup luksClose cdaten

Ein Angriffsvektor bleibt leider bestehen: Das eigentliche Linux-System kann nicht verschlüsselt werden. Der Grund ist der gleiche wie eben. Wir müssten hierfür beim Booten das entsprechende Passwort eingeben. Zu dieser Zeit haben wir bei einem Remote-System jedoch noch garkeinen Zugriff. Wir müssen den Server also mindestens dahin kriegen, dass der SSH-Server läuft. Erst dort können wir aufsetzen und alles weitere manuell starten. Leider.

Ich hoffe, die Informationen helfen dem einen oder anderen sein lokales oder sein Remote-System ein bisschen sicherer zu machen. 🙂

Und wie immer gilt: Ich hafte nicht für Schäden an Software, Hardware oder für Vermögensschäden, die durch Anwendung dieser Änderungen entstanden sind oder entstehen könnten. 😉
Remote-Verschlüsselte Grüße, Kenny

4 Kommentare » Schreibe einen Kommentar

  1. Ich hätte eine Bitte bezüglich deines Blogs. Du scheinst eine Menge Hintergrundverständnis in Sachen Computertechnik zu besitzen, das allerdings hilft dem ungewieften Nutzer kaum. Deswegen wäre ein Verzeichnis mit Fachwörtern oder ähnliches nützlich. Andernfalls wäre ein nutzerfreundlicherer Artikel insofern freundlicher, als dass man dann Schritt für Schritt selbst das Verständnis für die einzelnen Befehle und Begriffe erlangt. Ansonsten einmal mehr ein interessantes Thema und eine absolut lebenswerte Website.

    • Hallo Alex, vielen Dank für deine Anregung. Leider wird die Umsetzung gar nicht so einfach werden. Wenn ich über Themen wie die Partitionsverschlüsselung schreibe, dann meist deshalb, weil ich mir das Thema selbst nur umständlich erarbeitet habe und der Meinung war, dass eine treffendere Anleitung hilfreich sein könnte. Hier schreibe ich dann oft auf dem Niveau, auf dem ich solch eine Beschreibung selbst erwarten würde. 🙂

  2. Je nach Anbieter kann man über eine kvm beim Booten zugreifen. Alternativ kann man auch das eigentliche System virtualisieren. Ist aber alles nicht der wahre Jakob.

    Auf meinen Servern nutze ich Truecrypt Container. Im Ergebnis ist es aber ungefähr das gleiche. Bei mir kommt noch dazu, dass ich z. B. meine E-Mails und Datenbanken in dem Ordner habe, d. h. nach dem Mounten müssen alle Dienste, die auf diese Daten zugreifen neu gestartet werden. Jeder Server hat dafür ein Startscript, was ungefähr so aussieht:

    #!/bin/sh
    truecrypt --mount /var/container /var/data
    service mysql restart
    service freeradius restart
    ...

    • Das ist bei mir genauso. Konfig-Dateien etc. liegen auf der verschlüsselten Partition, wodurch die Dienste erst nach dem (manuellen) Mounten gestartet werden können.

      Schlussendlich ist es immer ein Henne-Ei-Problem. Auch bei einer verschlüsselten VM (die ich eigentlich einsetzen wollte) benötigt man einen unverschlüsselten Bereich (den Hypervisor), der im Ernstfall von außen angegriffen/infiltriert werden kann. Neben dem gleichen Angriffsvektor hat man dort dann zudem die reduzierte Leistung aufgrund der Virtualisierung.

      Ja, auch bei Systemen, bei denen auch die Root-Partition verschlüsselt ist (z.B. wenn man sich KVM-over-IP leisten kann, bei Hetzner immerhin 34€/Monat) gibt es einen Angriffsvektor - nämlich die Partition für den Bootloader. Die muss in jedem Fall unverschlüsselt bleiben und kann damit angegriffen/infiltriert werden.

      Schlussendlich ist es also ein Abwägen. 100%igen Schutz gibt es in diesem Fall leider nicht. :-/

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.