VPS mit LUKS verschlüsseln

Festplattenverschlüsselung beantwortet eine Frage, und beantwortet sie vollständig: was passiert, wenn jemand anderes die Festplatte in die Hände bekommt, während sie ausgeschaltet ist? Auf gemieteter Infrastruktur ist das nicht hypothetisch. Laufwerke fallen aus und gehen an den Lieferanten zurück. Nodes werden ausgemustert und ihr Speicher weiterverkauft. Volumes werden im Rahmen einer Ermittlung abgebildet oder verlassen ein Gebäude in einer Kiste.

• Abgedeckt. Eine ausgeschaltete Festplatte, ein Offline-Abbild Ihres Volumes, ein unter Garantie zurückgegebenes Laufwerk, eine stillgelegte Node, eine kopierte Snapshot-Datei. In jedem Fall hält der Angreifer Chiffretext und einen Header in Händen, und ohne Passphrase ist damit Schluss.
• Nicht abgedeckt: eine laufende Maschine. In dem Moment, in dem das Volume geöffnet ist, liegt der Schlüssel im Kernel-Speicher, und das Dateisystem liegt offen für alles mit Root-Rechten.
• Nicht abgedeckt: Ihr Traffic. Bytes auf der Leitung sind das Problem von TLS und WireGuard. LUKS bekommt sie nie zu Gesicht.
• Nicht abgedeckt: ein kompromittiertes Root-Konto. Ein Eindringling, der bereits drin ist, liest Ihre Dateien über denselben Mount wie Sie. Dafür ist Härtung da, und die beiden Kontrollen sind nicht austauschbar.

Die Liste ist bewusst kurz. Verschlüsselung ruhender Daten ist eine günstige Kontrolle mit hohem Wert und präzise begrenztem Umfang, und fast die gesamte Enttäuschung, von der Anwender berichten, entsteht dadurch, dass sie stillschweigend erwartet hatten, sie würde auch die anderen drei Zeilen abdecken.

Wenn Ihr verschlüsseltes Volume geöffnet ist, liegt der Schlüssel im RAM des Gasts — und auf jedem VPS, egal wo, befindet sich dieses RAM auf einer Maschine, die der Betreiber physisch kontrolliert. Ein Hypervisor kann den Speicher des Gasts lesen. Das ist kein Fehler in LUKS, in KVM oder in diesem Host im Besonderen; es ist schlicht, was das Mieten eines Computers bedeutet, und jeder Anbieter, der Ihnen etwas anderes erzählt, beschreibt ein Produkt, das es nicht gibt.

Die Bilanz ist deshalb nüchtern: Verschlüsselung ruhender Daten macht den Offline-Angriff unmöglich und lässt den Online-Angriff genau dort, wo er war. Ein Laufwerk, das das Rack verlässt, wird wertlos. Ein laufender Server ist so exponiert wie gestern. Beide Hälften dieses Satzes stimmen gleichzeitig, und eine Anleitung, die Ihnen nur die erste Hälfte erzählt, tut Ihnen keinen Gefallen.

Was die zweite Stellschraube bewegt, ist ein anderer Satz von Kontrollen, und sie summieren sich mit Verschlüsselung, statt sie zu ersetzen. Es gibt nichts Aktenkundiges offenzulegen, weil die Anmeldung hier ohne KYC auskommt — eine E-Mail-Adresse für die Zugangsdaten und sonst nichts. Die Zahlung wird on-chain abgewickelt statt über eine Bank. Und die Jurisdiktion, in der die Maschine steht, entscheidet, welche Anordnungen überhaupt etwas erzwingen können. Unsere ehrliche Aufschlüsselung dessen, was ein mit Krypto bezahlter VPS verbirgt arbeitet den Rest ab, und der Eintrag zu den Fourteen Eyes deckt die Seite des Geheimdienst-Datenaustauschs ab. Betrachtet als eine Schicht unter mehreren, ist LUKS sein Geld mehr als wert. Betrachtet als Schutzschild gegen den eigenen Host, ist es ein Missverständnis.

Das kann zwei Formen annehmen, und die Wahl ist eine Frage des Risikos, nicht der Stärke.

• Ein verschlüsseltes Datenvolume. Ein LUKS-Container neben dem Betriebssystem. Alles, was zählt — Datenbanken, Mail, Schlüssel, Uploads, Backups — liegt darin; das Betriebssystem selbst bleibt im Klartext. Zehn Minuten Arbeit, überhaupt kein Boot-Risiko, und jederzeit reversibel. Das ist es, was die meisten Leser bauen sollten, und genau das tun die Schritte weiter unten.
• Ein verschlüsseltes Root-Dateisystem. Alles liegt darin, einschließlich Logs, Paketlisten und der Shell-History, die Sie vergessen haben. Strikt stärker, und wirklich schwerer auf eine bereits laufende Maschine zu bekommen.

Der Grund für diese Schwierigkeit ist es wert, ausgesprochen zu werden, weil kein Tutorial es je tut: Sie können kein Dateisystem verschlüsseln, das gerade read-write eingehängt ist und Ihre SSH-Sitzung bedient. Beide echten Methoden — Shrink-and-Copy oder cryptsetup reencrypt an Ort und Stelle — benötigen die Root offline. Auf einer Maschine mit Out-of-Band-Konsole booten Sie einen Installer, und das ist Routine. Auf einem VPS ohne Konsole pivotieren Sie das laufende System zunächst in eine RAM-Disk, und wenn dabei irgendetwas schiefgeht, kommt die Maschine nicht zurück, und der Wiederherstellungsweg ist eine Neuinstallation, die die Festplatte löscht.

Also: Bauen Sie das Datenvolume heute, legen Sie alles Wichtige darauf, und behandeln Sie eine verschlüsselte Root als Entscheidung, die Sie zum Deployment-Zeitpunkt auf einer Maschine treffen, die noch nichts zu verlieren hat. Der letzte Abschnitt behandelt diesen Weg, einschließlich dropbear-initramfs, um die Passphrase beim Boot über SSH einzugeben.

Nicht viel, und das ist Teil des Grundes, warum es sich lohnt.

• Ein Plan. Verschlüsselung stellt keine zusätzliche RAM-Anforderung und kostet fast keine CPU. Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) reicht aus; Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) ist die komfortable Größe, wenn die Maschine auch einen echten Dienst betreibt. Die eine Zahl, auf die es ankommt, ist die Diskgröße, weil Ihr verschlüsseltes Volume davon abgeht.
• Debian 12 oder 13 aus der Template-Bibliothek, oder Ubuntu LTS — die Befehle unten sind Debian-typisch, und die Paketnamen unterscheiden sich anderswo. Das Deployment dauert etwa eine Minute, und vollständige KVM-Virtualisierung bedeutet einen echten Kernel mit vorhandenen dm-crypt-Modulen, kein Container, der sich einen fremden Kernel teilt.
• Zehn Minuten grundlegende Härtung zuerst. Verschlüsselung auf einer Maschine, die noch Passwort-Logins akzeptiert, ist ein Schloss an einer Tür ohne Rahmen.
• Eine Passphrase, die Sie nirgendwo sonst verwendet haben, generiert statt erdacht, und irgendwo gespeichert, das den Verlust dieser Maschine übersteht. Es gibt keine Wiederherstellung, kein Zurücksetzen und kein Support-Ticket, das hilft.
• Einen Ort abseits der Maschine für das Header-Backup. Wöchentliche Snapshots sind bei jedem Plan enthalten, aber ein Snapshot eines verschlüsselten Volumes ist immer noch verschlüsselt — nützlich für ein Rollback, nutzlos, wenn die Passphrase weg ist.

Der Standort macht dabei keinen Unterschied, wählen Sie also nach Preis oder Jurisdiktion: Amsterdam, Paris, Bukarest und Sofia liegen zum Grundpreis, während Zürich, Reykjavik, Stockholm und Kuala Lumpur einen Aufschlag tragen.

LUKS2 verwaltet bis zu 32 Keyslots. Jeder enthält eine Kopie desselben Master-Keys, verpackt mit einer jeweils anderen Passphrase — weshalb Sie eine zweite Passphrase hinzufügen können, ohne irgendetwas neu zu verschlüsseln:

cryptsetup luksAddKey /dev/disk/by-partlabel/secure
cryptsetup luksDump /dev/disk/by-partlabel/secure | grep -A2 '^Keyslots'
cryptsetup luksKillSlot /dev/disk/by-partlabel/secure 1

Zwei Passphrasen von Anfang an sind die richtige Grundeinstellung: eine, die Sie benutzen, eine, die aufgeschrieben und anderswo aufbewahrt wird. Den alleinigen Zugriff auf ein Volume durch einen Tippfehler im Passwort-Manager zu verlieren, ist die mit Abstand häufigste Art, wie Menschen LUKS-Daten verlieren — weit vor allem, was ein Angreifer anstellt.

Jetzt die Falle. Ein Header-Backup, das vor einer Passphrase-Rotation erstellt wurde, öffnet das Volume weiterhin mit der alten Passphrase. Keyslots liegen im Header, also ist eine alte Kopie des Headers auch eine alte Kopie der Keyslots — der Master-Key darunter hat sich nie geändert. Wenn Sie rotieren, weil eine Passphrase möglicherweise durchgesickert ist, müssen Sie jedes vor der Rotation erstellte Header-Backup vernichten und ein frisches anlegen. Sonst hat die Rotation nichts erreicht, außer Ihnen ein besseres Gefühl zu geben.

Dieselbe Tatsache macht Header-Backups auch selbst zu einem sensiblen Objekt: Diese 16-MB-Datei plus jede Passphrase, die sie je kannte, genügt, um das Volume zu entschlüsseln. Bewahren Sie sie dort auf, wo Sie auch die Passphrase aufbewahren würden, nicht dort, wo Sie Ihre Snapshots aufbewahren.

cryptsetup benchmark verrät Ihnen in etwa fünfzehn Sekunden die Wahrheit für Ihre spezifische vCPU. Auf jeder CPU mit AES-NI — also praktisch jedem x86-64-Serverprozessor des letzten Jahrzehnts — sind mehrere Gigabyte pro Sekunde für aes-xts zu erwarten, deutlich schneller als das NVMe darunter. Der praktische Overhead bei echten Workloads liegt im niedrigen einstelligen Prozentbereich, und er betrifft die CPU, nicht die Latenz.

Zwei cryptsetup-Optionen zählen bei schnellem Storage, und nur dort:

cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \
  --allow-discards open /dev/disk/by-partlabel/secure secure

Die Workqueue-Flags umgehen die internen Queues von dm-crypt und reichen I/O direkt an das Gerät weiter. Auf einer rotierenden Festplatte ändern sie nichts; auf NVMe-RAID10 beseitigen sie einen echten Flaschenhals bei hoher Queue-Tiefe. Fügen Sie sie der Optionszeile in crypttab als no-read-workqueue,no-write-workqueue hinzu, um sie dauerhaft zu machen.

--allow-discards ist die Option mit einem Kompromiss. Sie leitet TRIM zum NVMe durch, was die Schreibleistung langfristig hochhält — und offenbart zugleich jedem, der die ausgeschaltete Festplatte in Händen hält, welche Blöcke in Gebrauch und welche frei sind. Das ist ein echtes, wenn auch bescheidenes Informationsleck: Es zeigt ungefähr, wie voll das Volume ist, und kann auf die Struktur des Dateisystems hindeuten. Auf einem Allzweck-Server nehmen Sie die Performance mit. Wenn beim Inhalt des Volumes schon dessen Größe sensibel ist, lassen Sie Discards aus.

Wenn Sie alles verschlüsseln wollen, tun Sie das auf einer Maschine, auf der noch nichts liegt — deployen, konvertieren, dann aufbauen. Die Konvertierung selbst ist Standard: das Root-Dateisystem verkleinern, während es offline ist, einen LUKS2-Container im freigewordenen Platz anlegen, das System mit rsync -aHAX hinüberkopieren, /etc/fstab und /etc/crypttab auf das Mapper-Gerät zeigen lassen, dann update-initramfs -u -k all und GRUB neu installieren. Was das zu einem Problem auf einem VPS ohne Konsole macht, sind die Worte während es offline ist: Dorthin zu gelangen ohne Konsole bedeutet, das laufende System zunächst in eine RAM-Root zu pivotieren, und das ist der Schritt, der in einer Neuinstallation endet, wenn er schiefgeht.

Was eine verschlüsselte Root auf einer entfernten Maschine überhaupt erst nutzbar macht, ist dropbear-initramfs — ein rund 200 KB kleiner SSH-Server, eingebacken ins Boot-Image, der lauscht, während der Kernel auf die Passphrase wartet:

apt install dropbear-initramfs cryptsetup-initramfs

# Debian 12/13: /etc/dropbear/initramfs/
cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys

echo 'DROPBEAR_OPTIONS="-I 300 -j -k -p 2222 -s -c cryptroot-unlock"' \
  >> /etc/dropbear/initramfs/dropbear.conf

echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
update-initramfs -u -k all

Sie verbinden sich dann per ssh -p 2222 root@your-ip während des Boots, und der erzwungene cryptroot-unlock-Befehl fragt nach der Passphrase. Drei Dinge sind es wert, das zu wissen, bevor Sie sich darauf verlassen. Das initramfs hat seinen eigenen Host-Key, sodass Ihr Client bei Port 2222 vor einer Abweichung warnt — das ist erwartet und der Grund, ihm einen eigenen Port zu geben. Dieser Host-Key und Ihre authorized_keys liegen auf einer unverschlüsselten Boot-Partition, lesbar für jeden, der die Festplatte in Händen hält, verwenden Sie also einen Unlock-Key, der sonst nichts tut. Und -s deaktiviert Passwort-Logins im initramfs, was nicht optional ist.

Das andere Detail, das bei kleinen Plänen zubeißt, ist dasselbe wie aus Schritt drei, und hier beißt es am härtesten. Das initramfs läuft, bevor der Großteil Ihres RAM für irgendetwas Komfortables verfügbar ist, sodass ein Header, der mit hohen Argon2id-Speicherkosten formatiert wurde, ausgerechnet auf der Maschine, die ihn erstellt hat, nicht mehr entsperrt werden kann. Formatieren Sie mit begrenztem --pbkdf-memory, und testen Sie den Reboot, solange Sie noch nichts zu verlieren haben.

Sehr wenig, und genau das ist der Punkt. Ein geöffnetes LUKS-Volume ist ein gewöhnliches Block-Device; fsck, rsync, df und Ihr Backup-Tool verhalten sich exakt wie zuvor. Kernel-Upgrades sind unberührt, weil dm-crypt im Kernel-Baum steckt. Das Volume nach einem Plan-Upgrade zu vergrößern, ist mit zwei Befehlen erledigt — cryptsetup resize, dann die Größenänderung des Dateisystems selbst —, ganz ohne erneute Verschlüsselung.

Drei Gewohnheiten lohnen sich. Proben Sie den Reboot nach Plan, statt um drei Uhr nachts zu entdecken, dass eine nie aufgeschriebene Passphrase die einzige Kopie ist. Halten Sie die Backups unabhängig verschlüsselt — restic oder borg zu einem Offsite-Ziel, was eine von dem Volume getrennte Kontrolle ist und den kompletten Verlust der Maschine übersteht; das tägliche Offsite-Backup-Add-on kostet $2.00/mo, wenn Sie das nicht selbst aufbauen möchten. Und schließen Sie das Volume, bevor Sie aufhören, sich um die Maschine zu kümmern: cryptsetup close secure vor einem geplanten Shutdown, einer Migration oder Neuinstallation sorgt dafür, dass der Schlüssel aus dem Speicher ist, bevor die Festplatte aufhört, Ihnen zu gehören.

Bei der Richtlinie gibt es nichts zu verhandeln. Sie erhalten vollen Root-Zugriff auf einen KVM-Gast, und was Sie mit der Blockschicht anstellen, ist Ihre Sache; das eigene Volume zu verschlüsseln ist gewöhnliche Systemadministration, kein Grenzfall. Die Nutzungsrichtlinie betrifft Verhalten — die harte Grenze ist kein CSAM und kein Terrorismus — und hat nichts über dm-crypt zu sagen. Was Verschlüsselung ändert, ist die Gestalt eines hypothetischen schlechten Tages: Ein ausgeschaltetes Volume, das dieses Gebäude verlässt, ist Rauschen, und das ist Ihre zehn Minuten wert.