VPS-Festplatte mit LUKS verschlüsseln

Verschlüsselung ist keine allgemeine Datenschutzeinstellung. Sie beantwortet genau eine Frage: Kann jemand diese Blöcke ohne den Schlüssel lesen? Alles andere – wer weiß, dass Sie den Server gemietet haben, ob sich der Datenverkehr Ihnen zuordnen lässt, ob ein Gericht irgendetwas erzwingen kann – spielt sich anderswo ab.

Auf einem VPS schützt LUKS wirksam gegen:

• Ausgemusterte und defekte Hardware. NVMe-Laufwerke werden ersetzt. Secure-Erase auf einem defekten Gerät ist nicht immer möglich – manchmal ist es so kaputt, dass der Controller keine Befehle mehr annimmt, und es verlässt das Rack trotzdem.
• Ein Offline-Image. Ein Volume, das kopiert wird, während der Server ausgeschaltet ist – bei einer Beschlagnahmung, einer Migration, einem Fehler –, ist Chiffretext und bleibt Chiffretext.
• Backups und Snapshots, die die Maschine verlassen. Alles, was die Maschine verlässt, verlässt sie verschlüsselt, wenn es unterhalb Ihrer Kontrolle auf Blockebene entnommen wird, und sollte clientseitig verschlüsselt werden, wenn es oberhalb davon entnommen wird.
• Restblöcke. Wenn Sie einen Server löschen, werden die zugrunde liegenden Extents irgendwann wiederverwendet. Verschlüsselung macht die Überbleibsel zu Rauschen statt zu Daten.

Sie schützt nicht vor einer laufenden Maschine. Solange Ihr Server läuft, liegt der Masterschlüssel im Kernel-Speicher, und jeder, der diesen Speicher auslesen kann, liest Ihre Festplatte, unabhängig von der Passphrase. Bei gemieteter Infrastruktur bedeutet das: der Hypervisor-Betreiber. Das sagen wir in unserem Datenschutzhinweis, und wir sagen es auch hier: Keine Disk-Encryption-Funktion irgendeines Anbieters ändert daran etwas, unsere eingeschlossen, und jeder Anbieter, der etwas anderes behauptet, beschreibt Marketing statt Kryptografie.

Bevor Sie ein Terminal öffnen, wählen Sie das Modell. Sie unterscheiden sich enorm im Aufwand, und die meisten Menschen brauchen das erste.

1. Ein verschlüsseltes Datenvolume. Das System startet normal und unverschlüsselt; ein einzelner Verzeichnisbaum – ein Maildir, eine Datenbank, ein Archiv – liegt in einem LUKS-Container, den Sie nach jedem Boot von Hand öffnen. Zehn Minuten Arbeit, kein Rescue-Modus, kein Risiko, sich selbst auszusperren. Wenn es Ihnen um einen einzelnen Datenbestand geht und nicht um die gesamte Maschine, hören Sie hier auf – Sie erhalten den größten Teil des Nutzens bei einem Minimum an Störanfälligkeit. Das ist das Muster, das wir auf der Seite anonymer Mailserver empfehlen.

2. Ein verschlüsseltes Root-Volume mit Remote-Entsperrung. Alles außer /boot ist verschlüsselt, und jeder Boot hält im initramfs an, bis Sie sich per SSH einloggen und die Passphrase eingeben. Auf diesem Modell baut der Rest dieser Anleitung auf. Es kostet beim ersten Mal eine Stunde und danach einen SSH-Befehl pro Neustart, und es ist das einzige Modell, bei dem auch Logs, Paket-Caches, Shell-Verlauf und Swap abgedeckt sind – die Stellen, an denen Daten austreten, ohne dass es jemand so entschieden hätte.

3. Ein verschlüsseltes Root, das sich selbst gegen einen von Ihnen kontrollierten Schlüsselserver entsperrt. Wie Modell 2, aber Clevis holt das Entsperrmaterial von einem Tang-Server auf einer Maschine in einer anderen Jurisdiktion, sodass Neustarts unbeaufsichtigt ablaufen. Der Kompromiss ist präzise und lohnt sich zu verstehen: Der Server kann sich jetzt selbst entschlüsseln, solange Ihr Schlüsselserver zustimmt – das heißt, Sie haben das Geheimnis verlagert statt es zu beseitigen –, aber Sie haben auch einen Remote-Kill-Switch gewonnen. Mehr dazu weiter unten.

Viele Hosting-Anbieter bewerben „Verschlüsselung im Ruhezustand“ als Häkchen auf einer Checkliste. Es lohnt sich, genau zu klären, was diese Formulierung meist bedeutet, denn dahinter verbergen sich zwei sehr unterschiedliche Dinge.

Verschlüsselung mit einem Schlüssel, den der Anbieter besitzt, schützt vor einer gestohlenen Festplatte und sonst nichts. Wenn der Anbieter Ihren Server booten kann, ohne Sie irgendetwas zu fragen, kann der Anbieter Ihren Server auch entschlüsseln, ohne Sie irgendetwas zu fragen – und das kann dann auch jeder, der den Anbieter dazu zwingen kann. Das ist ein echter Schutz gegen Diebstahl und ein rein dekorativer gegen rechtlichen Zwang.

Verschlüsselung mit einem Schlüssel, den Sie selbst besitzen, ist die Version, die etwas bringt, und sie verhindert konstruktionsbedingt den unbeaufsichtigten Neustart. Das ist kein Mangel, den man wegkonstruieren sollte – das ist genau die Eigenschaft, die die Arbeit leistet.

Wir liefern ausschließlich die zweite Option, unkonfiguriert, und überlassen Ihnen die Entscheidung. Was wir tatsächlich besitzen, ist enger gefasst und dokumentiert: Root-Passwörter der Server werden auf Zeilenebene AES-256-CBC-verschlüsselt gespeichert, wir bewahren keine Flow-Logs oder Paketmitschnitte auf, und ein signierter Warrant Canary wird nach Zeitplan veröffentlicht. Nichts davon ersetzt Ihren eigenen Schlüssel – es ist der Teil, an dem man uns in der Zwischenzeit messen kann.

Die Standardwerte sind gut. Zwei davon lohnt es sich zu überschreiben.

Cipher. aes-xts-plain64 mit einem 512-Bit-Schlüssel ist die Voreinstellung und die richtige Wahl – die 512 Bit sind zwei 256-Bit-Schlüssel, das ist also AES-256 im XTS-Modus, und jede CPU, die wir betreiben, hat AES-NI. Auf einer Maschine ohne AES-Beschleunigung würden Sie xchacha20,aes-adiantum-plain64 vorziehen, aber das ist nicht unsere Hardware und vermutlich auch nicht Ihre.

Schlüsselableitung. LUKS2 verwendet standardmäßig Argon2id, das absichtlich speicherintensiv ist. cryptsetup benchmarkt Ihre Maschine beim Formatieren und wählt anhand des sichtbaren RAM einen Speicherkostenwert – und hier liegt die Falle, die für die meisten Meldungen der Art „mein verschlüsselter Server startet nicht mehr“ verantwortlich ist: Im initramfs steht weniger nutzbarer Speicher zur Verfügung als im laufenden System, und wenn Sie das Volume in einer Rescue-Umgebung mit mehr RAM formatiert haben, als der Zielplan besitzt, kann die Entsperrung beim Booten fehlschlagen oder abgebrochen werden. Legen Sie den Wert deshalb explizit fest. Ein GiB Argon2-Speicher ist für einen Angreifer eine ernsthafte Hürde und für einen S1 mit 4 GB problemlos machbar:

cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 --hash sha256 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 \
  /dev/vda2

--pbkdf-memory wird in KiB angegeben, 1048576 entspricht also 1 GiB. Prüfen Sie im Anschluss mit cryptsetup luksDump /dev/vda2, was tatsächlich im Header gelandet ist – der Abschnitt zu den Key-Slots zeigt die Speicher- und Iterationswerte an, die verwendet werden, und das einmal nachzulesen ist billiger als ein fehlgeschlagener Boot.

Die Passphrase. Argon2 verschafft Zeit gegen eine schwache Passphrase; es rettet sie nicht. Verwenden Sie eine Diceware-Phrase aus mindestens sechs Wörtern. Sie ist das einzige Geheimnis im System, und keine Schlüsselableitungsfunktion gleicht eine schlechte aus.

Ein Linux-Boot mit verschlüsseltem Root hat ein Henne-Ei-Problem: Kernel und initramfs müssen geladen werden, bevor überhaupt nach einer Passphrase gefragt werden kann, und beide liegen auf der Festplatte, die Sie entsperren wollen. Die Standardlösung ist eine kleine unverschlüsselte /boot-Partition mit Kernel, initramfs und Bootloader. Alles andere liegt innerhalb von LUKS.

Das initramfs hält dann an und fragt nach der Passphrase. Auf einem Laptop tippen Sie sie ein. Bei einem Server dreitausend Kilometer entfernt brauchen Sie eine von zwei Möglichkeiten:

• Die Konsole. Jeder Server in Ihrem Dashboard hat eine noVNC-Konsole, und sie funktioniert – aber die Tastatureingaben durchlaufen unsere Infrastruktur, also genau die Partei, die Ihr Schlüssel eigentlich ausschließen soll. Für eine einmalige Rettungsaktion in Ordnung, als Routine falsch.
• Ein SSH-Server im initramfs. dropbear-initramfs ist etwa 200 KB groß, bringt das Netzwerk hoch, lauscht auf einem Port Ihrer Wahl, akzeptiert einen Ihrer Public Keys und führt Sie direkt zur Passphrase-Abfrage. Die Passphrase ist Ende-zu-Ende verschlüsselt, von Ihrem Laptop bis zum initramfs. Das ist die richtige Antwort.

Zwei Details bringen Leute aus dem Konzept. Das Dropbear im initramfs hat seinen eigenen Host-Key, sein Fingerabdruck weicht also von dem Ihres normalen SSH-Daemons ab – das ist zu erwarten, kein Man-in-the-Middle, und es verdient eine eigene known_hosts-Datei statt der Angewohnheit, einfach yes einzutippen. Und der Interface-Name muss stimmen: virtio-NICs kommen unter Debian 13 meist als ens3 oder enp1s0 hoch, nicht als eth0. Prüfen Sie das mit ip -br link, bevor Sie die Konfiguration schreiben, denn ein falscher Name bedeutet ein initramfs ohne Netzwerk und einen Ausflug zur Konsole.

Wenn die Maschine von selbst wieder hochkommen muss – nach einem Kernel-Update, einem Host-Neustart, einem Stromausfall –, ist das Eintippen einer Passphrase keine Option. Clevis bindet einen LUKS-Key-Slot an eine externe Richtlinie, und Tang ist ein winziger Schlüsselaustausch-Server, der die einfachste brauchbare davon umsetzt.

# on a small server you control, elsewhere
apt install -y tang
systemctl enable --now tangd.socket

# on the encrypted VPS
apt install -y clevis clevis-luks clevis-initramfs
clevis luks bind -d /dev/vda2 tang '{"url":"http://tang.internal:7500"}'
update-initramfs -u -k all

Beim Booten führt das initramfs einen McCallum-Relyea-Austausch mit Tang durch und gewinnt den Schlüssel zurück, ohne dass der Tang-Server ihn je erfährt oder die Passphrase zu sehen bekommt. Die Eigenschaften lohnt es sich, genau zu benennen:

• Der VPS entschlüsselt sich selbst nur, solange er Tang erreichen kann. Schalten Sie Tang ab, oder rotieren Sie dessen Schlüssel, bleibt der nächste Boot stehen. Das ist ein echter Remote-Kill-Switch – ungewöhnlich und nützlich.
• Tang sollte nicht im öffentlichen Internet stehen. Erreichen Sie es über WireGuard oder als Tor-Onion-Dienst; die Tunnel-Seite behandeln wir in der WireGuard-Anleitung.
• Platzieren Sie Tang in einer anderen Jurisdiktion als die Daten. Unsere Jurisdiktionsseiten existieren genau für diese Art von Aufteilung.
• Bewahren Sie eine Passphrase in einem weiteren Key-Slot auf. Clevis ist eine Komfortschicht, nicht Ihr einziger Weg hinein.

Machen Sie sich klar, was Sie da gebaut haben: Eine unbeaufsichtigte Maschine hält ihren eigenen Schlüssel stellvertretend bereit, sodass ein Angreifer, der den VPS im laufenden Betrieb beschlagnahmt oder Ihren Tang-Server erreichen kann, an die Daten kommt. Das ist eine echte Schwächung gegenüber einer Passphrase, die nur in Ihrem Kopf existiert. Wählen Sie diesen Weg, wenn Verfügbarkeit wichtiger ist als das letzte bisschen Geheimhaltung, und nicht standardmäßig.

Ein verschlüsseltes Root deckt den größten Teil der Angriffsfläche ab, aber ein paar Pfade schreiben daran vorbei oder überleben es.

• Swap. Alles, was im RAM liegt, kann auf die Festplatte ausgelagert werden – Schlüssel, Nachrichteninhalte, entschlüsselte Puffer. Liegt Swap als Swapfile innerhalb des verschlüsselten Volumes, ist es abgedeckt. Eine separate Swap-Partition ist es nicht, außer Sie tragen sie mit einem zufälligen Schlüssel, der bei jedem Boot wechselt, in /etc/crypttab ein: cryptswap /dev/vda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256. Auf einem VPS ist das Swapfile einfacher, und es gibt keinen Grund, die Partition vorzuziehen.
• /tmp. Binden Sie es als tmpfs ein (tmpfs /tmp tmpfs defaults,nosuid,nodev,size=512M 0 0), damit es die Festplatte überhaupt nie berührt. Auch schneller.
• Ruhezustand. Schreibt den gesamten RAM, einschließlich Ihres Masterschlüssels, auf das Swap-Gerät. Aktivieren Sie das nicht. Auf unseren Images ist es standardmäßig deaktiviert.
• Das unverschlüsselte /boot. Kernel, initramfs-Images und die GRUB-Konfiguration sind für jeden mit Offline-Zugriff auf die Festplatte lesbar und, wichtiger noch, beschreibbar. LUKS gibt Ihnen Vertraulichkeit, keine Boot-Integrität. Wenn Ihr Bedrohungsmodell jemanden einschließt, der am Bootloader manipuliert, wird Verschlüsselung allein das nicht bemerken – protokollieren Sie die Hashes von /boot nach jedem Kernel-Update und prüfen Sie sie von außerhalb, oder nehmen Sie diese Lücke bewusst in Kauf.
• Bestehende Snapshots und alte Volumes. Heute zu verschlüsseln bringt nichts für ein Image, das gestern erstellt wurde. Wenn der Server jemals unverschlüsselt mit Daten lief, die Ihnen wichtig sind, behandeln Sie diese Daten als offengelegt und rotieren Sie alles, was sich davon ableitet.

Der Overhead ist gering genug, dass er nicht die Entscheidung treiben sollte, aber er ist nicht null. Messen Sie, statt zu spekulieren:

cryptsetup benchmark

Auf unseren EPYC-Nodes benchmarkt aes-xts mit einem 512-Bit-Schlüssel im niedrigen einstelligen Gigabyte-pro-Sekunde-Bereich pro Kern – deutlich über dem, was ein einzelnes NVMe-Volume je verlangen wird. Was sich tatsächlich bemerkbar macht, sind Latenz und CPU-Last bei kleinen zufälligen Schreibzugriffen, nicht der Durchsatz.

Zwei LUKS2-Flags sind auf NVMe relevant, wo die dm-crypt-Work-Queues des Kernels eher Latenz hinzufügen als sie zu entfernen. Setzen Sie sie und schreiben Sie sie dauerhaft in den Header:

cryptsetup refresh cryptroot \
  --perf-no_read_workqueue --perf-no_write_workqueue --persistent

Das dritte Flag, --allow-discards, reicht TRIM an das darunterliegende Gerät durch. Es hält die Schreibverstärkung über die Lebensdauer des Volumes niedrig, auf Kosten dessen, dass sichtbar wird, welche Blöcke ungenutzt sind – was jedem, der das Rohgerät ausliest, die ungefähre Größe und Form Ihrer Daten verrät. Aktivieren Sie es für einen Allzweck-Server; lassen Sie es aus, wenn schon die Tatsache, dass ein Volume zu 3 % gefüllt ist, für sich genommen sensibel ist. Es gibt keine universell richtige Antwort, nur eine Entscheidung, die Sie bewusst treffen sollten.

Der LUKS-Header ist etwa 16 MB groß und liegt am Anfang der Partition; er enthält die verschlüsselten Kopien des Masterschlüssels. Beschädigen Sie ihn – ein vertipptes dd, ein Partitionierungstool, das hilfsbereit den Anfang des Geräts überschreibt –, ist jedes Byte dahinter verloren. Es gibt keinen Wiederherstellungsdienst. Wir besitzen keine Kopie.

# back it up, off the server, before you put data on the volume
cryptsetup luksHeaderBackup /dev/vda2 \
  --header-backup-file luks-header-$(date +%F).img

# add a second passphrase while you still have the first
cryptsetup luksAddKey /dev/vda2

# see what is in the header
cryptsetup luksDump /dev/vda2

Zwei Dinge zu diesem Backup. Es ist genauso sensibel wie die Festplatte selbst: Es enthält Key-Slots, sodass ein altes Header-Backup, das nach einem Passphrase-Wechsel wiederhergestellt wird, klaglos die alte Passphrase akzeptiert. Bewahren Sie es so auf wie die Passphrase, und vernichten Sie veraltete Kopien, wenn Sie rotieren. Zweitens: LUKS2 gibt Ihnen 32 Key-Slots – nutzen Sie mindestens zwei, wobei der Ersatz eine lange, zufällige Passphrase sein sollte, die an einem anderen Ort aufbewahrt wird als Ihre tägliche. Der Fehlerfall, den das verhindert, ist banal und häufig: Sie rotieren die Passphrase, vertippen sie beim zweiten Mal auf dieselbe falsche Weise, und bemerken es erst beim nächsten Neustart statt beim nächsten Login.

Sorgen Sie auch für einen Weg zurück hinein. Der Rescue-Modus bootet den Server von unserer ISO mit Ihren injizierten SSH-Keys, ohne das verschlüsselte Volume anzurühren – das heißt, Sie können mit cryptsetup open /dev/vda2 rescue && mount /dev/mapper/rescue /mnt ein defektes crypttab oder ein kaputtes initramfs reparieren, ohne die Daten zu verlieren. Testen Sie das einmal bewusst, solange nichts kaputt ist.

Das Nützlichste, was eine Anleitung wie diese tun kann, ist, ihre eigenen Grenzen zu markieren.

• Sie schützt keinen laufenden Server. Der Masterschlüssel liegt vom Entsperren bis zum Herunterfahren im Kernel-Speicher. Speicherzugriff auf Hypervisor-Ebene hebelt das aus. Speicherverschlüsselung – AMD SEV-SNP und Vergleichbares – ist die einzige Technologie, die daran wirklich etwas ändert, und wir bieten sie heute nicht an; ein Anbieter, der ohne SEV behauptet, Ihre laufende VM sei dagegen undurchsichtig, irrt sich oder lügt.
• Sie macht Sie nicht anonym. Eine verschlüsselte Festplatte in Zürich hat trotzdem eine IP, eine Zahlungsspur und eine SSH-Sitzung, die irgendwo begonnen hat. Das ist ein anderes Problem, und wir haben aufgeschrieben, wie es dabei schiefgeht, in den Fehlern, die Sie deanonymisieren.
• Sie ändert nichts daran, was ein Gericht anordnen kann. Jurisdiktion regelt den Zwang, Verschlüsselung regelt die Lesbarkeit. In manchen Jurisdiktionen können Sie persönlich zur Offenlegung einer Passphrase verpflichtet werden. Unsere Anleitung zu rechtlichen Verfahren beschreibt, was wir umsetzen und was nicht.
• Sie übersteht keine verlorene Passphrase. Das ist Absicht, und es lohnt sich, es zu wiederholen, denn das Support-Ticket mit der Bitte um Hilfe erreicht uns etwa einmal im Monat, und die Antwort ist immer dieselbe.
• Sie authentifiziert nicht die Boot-Kette. Vertraulichkeit ist keine Integrität. /boot ist offline lesbar und veränderbar.

Was sie tatsächlich tut: eine ganze Klasse von Angriffsfläche beseitigen – alles, was einer Festplatte passiert, wenn sie nicht läuft, und das ist das meiste, was Festplatten passiert. Das ist eine Stunde wert. Kombinieren Sie es mit einer No-KYC-Anmeldung, Zahlung mit Monero und einer bewusst gewählten Jurisdiktion, und jede Schicht deckt einen anderen Fehlerfall ab. Keine davon deckt sie alle ab.