Festplattenverschlüsselung auf einem VPS: LUKS und Remote-Unlock

Was Ihr Anbieter wirklich sehen kann

Beginnen Sie bei der Physik statt bei der Richtlinie, denn eine Richtlinie kann sich ändern, Physik nicht. Auf einer virtuellen Maschine liegt das Disk-Image auf Hardware, die jemand anderes ins Rack geschraubt hat. Ist dieses Image nicht verschlüsselt, kann es jeder lesen, der am Ende den Datenträger in Händen hält: ein Betreiber mit Hypervisor-Zugriff, ein Techniker, der eine defekte NVMe aus einem RAID-1-Paar tauscht, wer auch immer diese Platte irgendwann bei der Ausmusterung erhält, und — der Fall, um den es allen eigentlich geht — jeder, der mit einer bindenden Anordnung eines Gerichts erscheint, das für die Maschine zuständig ist. Nichts davon erfordert Bösartigkeit oder eine Hintertür. Ein unverschlüsseltes Volume ist schlicht eine Datei, und Dateien lassen sich kopieren.

Die zweite Schicht ist der Arbeitsspeicher. Unsere VPS-Pläne sind KVM-Vollvirtualisierung, Sie fahren also Ihren eigenen Kernel, statt sich einen zu teilen — aber der Hypervisor besitzt weiterhin das RAM, das er Ihnen zuteilt, und jeder Hypervisor kann eine Gastinstanz technisch introspizieren. Die dritte Schicht ist alles, was die Festplatte nie berührt: der Traffic, der Ihre Netzwerkschnittstelle verlässt, die Metadaten, die Ihre Anwendung erzeugt, das DNS, das Sie auflösen. Auf der Kontoseite halten wir bewusst sehr wenig vor — einen argon2id-Passwort-Hash, Ihr Guthaben samt Kontobuch, die Bestelldaten und Zugriffsprotokolle, die nach 14 Tagen rotiert werden, ohne Namen, Adresse, Telefonnummer oder Karte irgendwo darin, wie auf der No-KYC-Richtlinienseite aufgeführt. Nichts über Sie vorzuhalten ist eine andere Garantie als Ihre Festplatte nicht lesen zu können, und nur eine der beiden lässt sich von Ihnen selbst durchsetzen.

Was Festplattenverschlüsselung behebt — und was nicht

Festplattenverschlüsselung ist eine Kontrolle für Daten im Ruhezustand. Sie deckt genau die oben genannten Szenarien ab, in denen ein Volume den Besitzer wechselt, während die Maschine aus ist oder die Kopie offline gezogen wird: ein ausgemustertes oder per RMA eingeschicktes Laufwerk, eine Festplatte, von der ein Abbild gezogen wurde, ein aus der Speicherschicht geklontes Volume, ein kalter Snapshot, der Ihnen unter den Füßen weggezogen wird. In jedem dieser Fälle ist ein verschlüsselter LUKS-Container ein undurchsichtiger Datenblock, und wer ihn in Händen hält, braucht eine Passphrase, die es immer nur in Ihrem Kopf oder auf Ihrem Laptop gab. Das ist eine echte, harte Grenze, und es ist die größte einzelne Verbesserung, die die meisten Leute an einem gemieteten Server vornehmen können.

Genauso wichtig ist es, bei der anderen Hälfte ehrlich zu sein. Ein laufender Server hat den Schlüssel im RAM — genau das macht das Dateisystem für die eigenen Prozesse lesbar —, sodass Verschlüsselung nichts gegen eine aktive Root-Kompromittierung ausrichtet, gegen einen bösartigen Prozess innerhalb des Gastsystems, einen Speicherauszug, der bei laufender Box gezogen wird, oder einen Hypervisor, der diesen Speicher introspiziert. Sie verschlüsselt nicht, was den Netzwerk-Port verlässt, und sie hilft nicht, wenn Ihre Anwendung Geheimnisse in ein Log schreibt, das Sie anschließend woandershin verschicken. Wenn Ihr Bedrohungsmodell Hypervisor-Introspektion wirklich ausschließt, lautet die ehrliche Antwort nicht ein besserer Cipher: Es ist dedizierte Hardware ab $66.00/Monat, wo über Ihnen überhaupt kein Hypervisor mehr sitzt. Für alles darunter deckt Verschlüsselung im Ruhezustand zusammen mit einem Anbieter, der fast nichts vorhält, die realistischen Fälle ab — die hier verwendeten Begriffe sind im Glossar definiert.

Verschlüsseltes Datenvolume oder verschlüsselte Root?

Es gibt zwei Designs, und sie passen zu unterschiedlichen Situationen. Das erste ist ein verschlüsseltes Datenvolume: Das Betriebssystem bleibt im Klartext, und Sie legen alles, was zählt — Ihren Anwendungszustand, Ihre Datenbank, Ihren Dokumentenspeicher, Ihre Schlüssel — in einen LUKS-Container, der an einem Pfad Ihrer Wahl eingehängt wird. Es lässt sich auf einer Box installieren, die bereits produktiv läuft, blockiert nie einen Neustart, und schützt das Material, das ohnehin jeder haben will. Lesbar bleibt die Form des Systems: Ihre Paketliste, Ihre systemd-Units, Ihre nginx-vhosts, Ihre Shell-History, Ihre Logs.

Die zweite ist eine verschlüsselte Root, bei der alles außer einer kleinen Boot-Partition im Container liegt. Nichts an der Maschine ist lesbar, wenn sie aus ist — das Ergebnis, das die meisten Leute vor Augen haben, wenn sie von einem verschlüsselten Server sprechen. Der Preis wird bei jedem Neustart fällig: Ein Reboot bleibt an einem Passphrase-Prompt auf einer Konsole stehen, die Sie nicht sehen können, bis Sie ihm einen Weg geben, Sie aus der Ferne zu fragen. Genau deshalb gibt es den nächsten Abschnitt. Als Faustregel: Verschlüsseln Sie die Root, wenn Sie eine Box von Grund auf neu aufbauen und sie testen können, bevor sie irgendetwas trägt; verschlüsseln Sie ein Datenvolume, wenn die Box bereits existiert und Ausfallzeit teuer ist. Die In-place-Umwandlung einer laufenden Root mit cryptsetup reencrypt ist unter LUKS2 möglich und ist nichts, was wir für einen Produktivserver empfehlen würden, den Sie nicht neu aufbauen können.

Remote-Unlock: ein winziger SSH-Server im initramfs

Der Kniff, der eine verschlüsselte Root auf einer entfernten Maschine praktikabel macht, heißt dropbear-initramfs. Das initramfs ist das Miniatursystem, das der Kernel entpackt, bevor die eigentliche Root existiert; weil Sie den Kernel auf einem KVM-VPS selbst besitzen, können Sie einen sehr kleinen SSH-Daemon hineinlegen. Beim Booten bringt die Maschine ihre Netzwerkschnittstelle hoch, startet diesen Daemon und wartet. Sie verbinden sich, führen einen Befehl aus, die Passphrase entsperrt den Container, der Bootvorgang läuft weiter ins echte System, und der winzige Daemon verschwindet. Von außen sieht es aus wie ein Server, der dreißig Sekunden länger und eine bewusste Aktion mehr braucht, um wieder da zu sein.

Zwei Details verursachen fast den gesamten Ärger. Das erste ist, dass der SSH-Server im initramfs seinen eigenen Host-Key hat, der sich von dem des laufenden Systems auf derselben Adresse unterscheidet — lassen Sie ihn auf Port 22, verweigert Ihr Client die zweite Verbindung jedes Mal wegen eines nicht übereinstimmenden Host-Keys. Geben Sie ihm einen eigenen Port und eine eigene known_hosts-Datei, und das Problem verschwindet. Das zweite ist das Timeout: Der Daemon sollte nicht ewig dort sitzen, wenn Sie schlafen, aber auch nicht aufgeben, bevor Sie ein Terminal erreichen können. Fünf Minuten sind ein sinnvoller Standardwert. Beschränken Sie den Schlüssel so, dass er nichts außer Entsperren kann, und behandeln Sie die Adresse dieses Boot-Listeners als etwas, das Sie nicht veröffentlichen — derselbe Instinkt, der auch beim Fernhalten des eigenen Namens von einem Server mitschwingt.

Key-Slots, Header und der Fehler, den irgendwann jeder macht

Ein LUKS2-Container verschlüsselt Ihre Daten nicht mit Ihrer Passphrase. Er verschlüsselt einen Hauptschlüssel mit Ihrer Passphrase, speichert diese verpackte Kopie in einem Schlüssel-Slot im Header und verschlüsselt das Volume mit dem Hauptschlüssel. Die Konsequenz lohnt sich zu verinnerlichen: Es gibt mehrere Slots, Sie können also eine zweite Passphrase oder eine Schlüsseldatei hinzufügen, ohne ein einziges Byte neu zu verschlüsseln, und Sie können einen davon widerrufen, ohne die anderen anzufassen. Die andere Konsequenz ist schärfer — der Header ist die Daten. Überschreiben Sie die ersten paar Megabyte dieses Volumes, und jeder Slot ist auf einen Schlag weg, zusammen mit jeder Aussicht auf Wiederherstellung. Sichern Sie den Header ab, außerhalb der Maschine, in dem Moment, in dem Sie den Container erstellen, und erneut jedes Mal, wenn Sie einen Schlüssel hinzufügen oder entfernen.

Dann gibt es noch den Ausfallmodus, den dieser Host ungewöhnlich schonungslos offenlegt. Die Registrierung hier ist ein Benutzername und ein Passwort mit acht Wiederherstellungscodes und ganz ohne E-Mail im gesamten Ablauf, genau damit es keine Identität gibt, die durchsickern könnte — was auch bedeutet, dass es für nichts einen identitätsbasierten Wiederherstellungsweg gibt, Sie eingeschlossen. Niemand kann für Sie bürgen, und niemand hat eine Kopie Ihrer Passphrase. Bauen Sie die verschlüsselte Maschine also auf, solange Sie noch eine funktionierende haben, starten Sie sie bewusst neu und entsperren Sie sie aus der Ferne, bevor sie Daten trägt, bewahren Sie das Header-Backup und einen zweiten Schlüssel-Slot an einem Ort auf, den Sie auch nach dem Verlust Ihres Laptops noch erreichen, und stellen Sie sicher, dass Ihr Wiederherstellungsplan bei neu ausrollen und aus dem Backup wiederherstellen endet und nicht dabei, dass jemand anderes eine Passphrase für Sie eintippt.

Die Lecks an den Rändern: Swap, Snapshots und Backups

Eine verschlüsselte Root mit einer Swap-Partition im Klartext ist ein Schloss an einer Tür mit offenem Fenster — der Kernel lagert alles, einschließlich Schlüsselmaterial, in diesen Swap aus. Die Lösung ist, den Swap bei jedem Boot neu aus /dev/urandom zu verschlüsseln, was nichts kostet, weil Swap keinen Neustart überstehen muss. Geben Sie /tmp die gleiche Behandlung mit tmpfs, wo immer möglich, deaktivieren Sie den Ruhezustand auf einem Server, und denken Sie an discard, bevor Sie es aktivieren: TRIM an die Speicherschicht durchzureichen ist gut für das Laufwerk, verrät aber das Muster, welche Blöcke in Benutzung sind — eine kleine, aber reale Preisgabe darüber, wie voll Ihr Volume ist und wo.

Backups verdienen einen eigenen Gedanken, denn ein Backup ist eine Kopie Ihrer Daten an einem Ort, den die gerade konfigurierte Verschlüsselung nicht erreicht. Unser Add-on für tägliche verschlüsselte Backups speichert Snapshots bei VPS-Plänen außerhalb der Maschine, und manuelle Snapshots — die auf demselben Host liegen — sind eine Rollback-Annehmlichkeit und kein Backup, wie es die FAQ formuliert. Wenn Sie den Anbieter in Ihr Bedrohungsmodell einbeziehen, verschlüsseln Sie clientseitig, bevor irgendetwas die Maschine verlässt, mit einem Schlüssel, der nicht darauf gespeichert ist. Diese eine Gewohnheit macht den Wiederherstellungsweg zudem portabel: Ein Backup, das nur Sie lesen können, ist ein Backup, das Sie überall wiederherstellen können, auch auf einem anderen VPS-Plan in einer anderen Region.

Wo Verschlüsselung im Offshore-Bedrohungsmodell steht

Verschlüsselung ist eine von drei Kontrollen, die unabhängig voneinander versagen können, weshalb der Einsatz aller drei keine Paranoia ist, sondern normales Engineering. Die erste ist was der Host über Sie weiß — nichts, wenn das Konto ein Benutzername ist, finanziert durch ein vorausbezahltes Krypto-Guthaben ab $30.00, über 8 Coins und Netzwerkvarianten hinweg, die 7 Währungen abdecken, ganz ohne Karte und ohne Dokument in der Kette; das ist das Thema von Hosting anonym bezahlen. Die zweite ist welches Recht gilt, was davon entschieden wird, wo die Maschine steht, und nicht, wo Sie sitzen, und wird Region für Region ausgearbeitet in welchen Offshore-Standort sollten Sie wählen? und rechtlich in Offshore-Hosting-Gerichtsbarkeiten im Vergleich.

Die dritte ist was im Ruhezustand lesbar ist, und die liegt allein bei Ihnen — kein Anbieter kann das für Sie erledigen, denn ein Anbieter, der Ihren Schlüssel verwahrt, hat das Problem, das Sie eigentlich beunruhigt hat, nicht gelöst. Stapeln Sie sie, und jede deckt ein eigenes Versagen ab: Ein Identitätsleck legt nicht die Festplatte offen, eine juristische Überraschung übergibt keine Passphrase, und ein gestohlenes Laufwerk nennt nicht Ihren Namen. Es gibt 6 Regionen zur Auswahl unter unseren Standorten, mit einem VPS online in etwa 15 min; bei dedizierter Hardware, übergeben in 2–12 h mit IPMI-Zugangsdaten, können Sie noch weiter gehen und Ihren eigenen Installer booten, statt einem vom Anbieter gelieferten Image überhaupt zu vertrauen.

Performance, und die Boxen, die keine Verschlüsselung verdienen

Die Performance-Frage ist größtenteils durch die Hardware geklärt. Jeder VPS in der Flotte läuft auf einem AMD EPYC 9354 mit AES-NI, sodass aes-xts-plain64 Daten mit mehreren Gigabyte pro Sekunde und Kern verarbeitet — weit über das hinaus, was ein einzelner Workload von einem NVMe-RAID-1-Array verlangt. Führen Sie cryptsetup benchmark auf der Box aus und lesen Sie die Zahlen, statt einem Blogpost zu vertrauen, unserem eingeschlossen. Der tatsächlich messbare Overhead zeigt sich in der Latenz statt im Durchsatz, und nur bei Workloads, die bereits fsync-limitiert sind: eine schreiblastige relationale Datenbank, ein stark frequentierter Mail-Spool, eine Warteschlange, die jede Nachricht einzeln committet. Für einen Webserver, ein Application-Backend, einen VPN-Endpunkt oder einen Filespeicher geht die Kosten gegen null.

Die nützlichere Frage ist, welche Maschinen das zusätzliche bewegliche Teil nicht verdienen. Eine Box ohne privaten Zustand gewinnt nichts durch Verschlüsselung und handelt sich einen Neustart ein, der nicht unbeaufsichtigt durchlaufen kann — ein öffentlicher statischer Mirror, ein Cache-Node, ein Tor-Middle-Relay, dessen einziges Geheimnis ein Identitätsschlüssel ist, den Sie in einer Minute rotieren könnten. Verschlüsseln Sie dort, wo es etwas zu verlieren gibt: die Datenbank, den Mail-Speicher, das Backup-Ziel, die Maschine, die Ihren WireGuard-Tunnel terminiert und deren private Schlüssel hält. Entscheiden Sie pro Box, nicht pro Flotte, und schreiben Sie auf, welche welche ist — der Betreiber in sechs Monaten sind Sie selbst, mit weniger Kontext und einer schlechteren Nachtruhe.

Schritt für Schritt

1. 01

   Entscheiden, was Sie schützen, und das Design wählen

   Schreiben Sie den einen Satz auf, der zählt: Welche Dateien würden schaden, wenn eine Kopie dieses Volumes das Gebäude verließe. Wenn die Antwort eine Datenbank und ein Schlüsselverzeichnis ist, reicht ein verschlüsseltes Datenvolume, und Sie behalten unbeaufsichtigte Neustarts. Wenn die Antwort die ganze Maschine erzählt eine Geschichte, die ich lieber nicht erzählt hätte lautet, bauen Sie eine verschlüsselte Root und akzeptieren Sie, dass Sie bei jedem Boot gebraucht werden. Fangen Sie nicht an zu tippen, bevor dieser Satz existiert.

2. 02

   Einen frischen VPS aufsetzen und vor allem anderen härten

   Deployen Sie über das Panel — ein VPS ist online in etwa 15 min — und erledigen Sie zuerst die langweilige Arbeit, auf einer sauberen Box, solange ein Fehler noch nichts kostet. SSH nur per Schlüssel, eine Default-Deny-Firewall, unbeaufsichtigte Sicherheitsupdates, und cryptsetup installiert.

   apt update && apt full-upgrade -y
   apt install -y cryptsetup ufw unattended-upgrades
   ufw allow OpenSSH
   ufw enable

3. 03

   Den LUKS2-Container erstellen und ein Dateisystem hineinlegen

   Für ein Datenvolume ist ein dateibasierter Container die am wenigsten invasive Option und verhält sich identisch zu einer Partition. Dimensionieren Sie ihn nach dem, was er enthält, nicht nach der Festplatte. Wählen Sie eine Passphrase, die Sie auch unter Stress aus dem Gedächtnis tippen können — das ist kein Passwort, das Sie aus einem Manager einfügen, auf einer Maschine, die noch nicht gebootet hat.

   fallocate -l 40G /var/lib/vault.img
   cryptsetup luksFormat --type luks2 /var/lib/vault.img
   cryptsetup open /var/lib/vault.img vault
   mkfs.ext4 /dev/mapper/vault
   mkdir -p /srv/vault && mount /dev/mapper/vault /srv/vault

4. 04

   Einen zweiten Schlüssel hinzufügen und den Header außerhalb der Maschine sichern

   Ein einzelner Schlüssel-Slot ist nur einen schlechten Tag von einem Totalverlust entfernt. Fügen Sie eine zweite Passphrase oder eine Schlüsseldatei hinzu, exportieren Sie den Header in eine Datei, und kopieren Sie diese Datei irgendwohin außerhalb des Servers — ein verschlüsseltes Volume auf Ihrem Laptop oder Offline-Speicher. Wiederholen Sie den Export jedes Mal, wenn Sie einen Slot ändern; ein veraltetes Header-Backup kann einen Schlüssel wiederbeleben, den Sie für widerrufen hielten.

   cryptsetup luksAddKey /var/lib/vault.img
   cryptsetup luksHeaderBackup /var/lib/vault.img \
     --header-backup-file /root/vault-header.img
   cryptsetup luksDump /var/lib/vault.img

5. 05

   Für eine verschlüsselte Root: den SSH-Daemon im initramfs installieren

   Nur relevant, wenn die Root selbst verschlüsselt ist. Legen Sie Ihren Public Key dorthin, wo das initramfs ihn findet, verschieben Sie den Listener von Port 22 weg, damit er nie mit dem echten Host-Key kollidiert, bringen Sie die Schnittstelle per DHCP hoch, und bauen Sie das initramfs neu. Die Pfade haben sich in Debian 12 verschoben: Dort ist es /etc/dropbear/initramfs/, unter Debian 11 /etc/dropbear-initramfs/.

   apt install -y dropbear-initramfs
   cat ~/.ssh/id_ed25519.pub > /etc/dropbear/initramfs/authorized_keys
   echo 'DROPBEAR_OPTIONS="-p 2222 -s -j -k -I 300"' \
     >> /etc/dropbear/initramfs/dropbear.conf
   echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
   update-initramfs -u -k all

6. 06

   Bewusst neu starten, solange die Box noch leer ist

   Das ist der Schritt, den Leute überspringen und später bereuen. Starten Sie bewusst neu, bevor Daten vorhanden sind, und entsperren Sie über das Netzwerk genau so, wie Sie es um drei Uhr morgens tun würden. Bewahren Sie den Boot-Listener in seiner eigenen known_hosts-Datei auf, damit sein Host-Key nie mit dem echten in Konflikt gerät. Kommt die Box nicht wieder hoch, haben Sie eine Test-Box verloren statt einer Produktiv-Box.

   reboot
   ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.boot root@203.0.113.10
   # inside the initramfs:
   cryptroot-unlock

7. 07

   Die Lücken schließen und den Wiederherstellungsplan aufschreiben

   Verschlüsseln Sie den Swap bei jedem Boot neu aus /dev/urandom, damit nichts Ausgelagertes einen Neustart übersteht, lassen Sie den Ruhezustand deaktiviert, und verschlüsseln Sie Backups clientseitig, bevor sie die Maschine verlassen. Schreiben Sie anschließend das Runbook für die Wiederherstellung — wo das Header-Backup liegt, welcher Slot welcher ist, und der Weg über Neuausrollen und Wiederherstellen, den Sie gehen, wenn Entsperren keine Option ist. Ein Plan, den Sie nicht aufgeschrieben haben, ist kein Plan, den Sie haben.

   # /etc/crypttab — swap re-keyed at every boot
   swap  /dev/vda3  /dev/urandom  swap,cipher=aes-xts-plain64,size=256