Backups vor Ransomware schützen — Append-Only und Sync-Strategien

Eine moderne Ransomware-Attacke versucht zwei Sachen: erstens Deine Daten verschlüsseln, zweitens Deine Backups löschen, damit Du zahlen musst. Wenn Dein PBS-Token vom kompromittierten PVE-Host aus die volle Permission auf den Datastore hat, kann der Angreifer Snapshots prunen und GC anstoßen — Backups sind weg.

Es gibt drei Schutzschichten, die Du kombinieren kannst.

Schicht 1 — Permissions-Prinzip “least privilege”

Der häufigste Fehler: PVE-Host nutzt einen User mit Admin-Rechten auf den ganzen Datastore. Bei einer Kompromittierung kann der Angreifer alles.

Lösung: Eigener User pro PVE-Host mit minimalen Rechten:

• Datastore.Backup — darf neue Backups schreiben und die eigenen lesen
• Datastore.Read — darf bestehende Backups lesen (für Restore)
• NICHT Datastore.Modify — keine fremden Backup-Gruppen, kein Datastore-weites Prune

Permissions im PBS unter Configuration → Access Control → Permissions vergeben.

Wieg Dich damit aber nicht in falscher Sicherheit: Datastore.Backup erlaubt dem Owner laut Proxmox-Doku ausdrücklich, seine eigenen Backup-Gruppen zu lesen, zu restoren — und zu löschen. Ein kompromittierter PVE-Host ist Owner genau der Backups, die er geschrieben hat. Mit dem gestohlenen Token kann der Angreifer also genau diese Backups wegräumen. Was er nicht kann: fremde Backup-Gruppen anfassen oder ein Datastore-weites Prune/GC fahren.

Least Privilege begrenzt den Schaden, verhindert ihn aber nicht. Echten Lösch-Schutz gibt es erst durch Schicht 2 (Sync auf einen zweiten PBS, an den der Token nicht rankommt) — und für einzelne wichtige Snapshots durch das Protected-Flag, siehe Prune erklärt.

Schicht 2 — Sync zu einem zweiten PBS mit Pull-only-Permission

Stärkere Schicht: Backups werden zu einem zweiten PBS gespiegelt, an dem der Angreifer gar keine Permissions hat.

Setup:

1. Quell-PBS (bei uns): hier laufen die regulären Backups.
2. Ziel-PBS (separater Standort, eigene Hardware oder zweiter xaweho-Tarif): zieht per Sync Job regelmäßig vom Quell-PBS.
3. Sync Job auf Target läuft mit eigenem User: dieser User hat nur Remote.Audit und Remote.Read auf der Quelle.
4. Auf dem Target-PBS hat Dein PVE-Host gar keinen Zugriff.

Selbst wenn der Angreifer Deinen ganzen PVE und den Quell-PBS-Datastore zerstört: der Target-PBS hat eine vollständige, intakte Kopie, die er niemals erreicht hat.

Das ist die robustere Schicht — sie kostet einen zweiten PBS-Tarif, lohnt sich aber für Setups mit echten Compliance-Anforderungen.

Schicht 3 — Tape oder Append-Only-Storage (Air Gap)

Die ultimative Schicht: Backups landen auf einem Medium, das physisch nicht modifizierbar ist.

PBS unterstützt nativ Tape-Backups (LTO). Wir betreiben kein Tape-Setup, also ist das bei uns keine Option. Aber Du kannst:

• Lokal Tape betreiben: Eigenes LTO-Laufwerk zuhause oder im Büro. PBS schreibt regelmäßig Tapes weg, die Du physisch ausstöpselst.
• Append-Only-S3: Cloud-Storage mit Object-Lock-Policy (z.B. AWS S3 Object Lock). Backup landet als Object, das für N Tage nicht löschbar ist. Aber: Komplexer in PBS, oft zusätzliche Software-Schicht.

Für die meisten Privatkunden und kleine Firmen reicht Schicht 1 + 2.

Zusätzliche Hardening-Maßnahmen

Token-Lifetime begrenzen

API-Tokens auf dem Quell-PBS bekommen eine Ablaufzeit. So wird ein gestohlener Token spätestens nach Ablauf wertlos. Setup:

1. Configuration → Access Control → API Token → Add.
2. Feld Expire: Ablaufdatum, z.B. 90 Tage in der Zukunft.
3. Vor Ablauf neuen Token erzeugen und in PVE-Storage updaten.

Verschlüsselung erzwingen

Mit clientseitiger Verschlüsselung kann der Angreifer Backups, die er klaut, nicht lesen — er kann sie nur löschen oder zurückspielen.

In Kombination mit Schicht 2 (eine Kopie, an die der Angreifer gar nicht rankommt) ist das doppelt abgesichert.

Verify-Jobs als Frühwarn-System

Wenn ein Angreifer Backup-Chunks manipuliert, schlägt die nächste Verification fehl. Konfiguriere Verify-Jobs mit kurzer Frequenz (z.B. wöchentlich) und Mail-Notifications, damit Du bei Manipulation sofort Bescheid weißt.

Multi-Faktor auf dem PBS-Admin-Login

Wenn der Angreifer per Web-GUI auf den PBS kommt, ist alles weg. Schütze den Admin-Login mit MFA: Configuration → Two-Factor Authentication → Add TOTP.

Wir empfehlen MFA dringend für jeden Admin-Account.

Konkretes Setup für Privatkunden

Für die meisten Privatkunden reicht eine pragmatische Variante:

1. Eigener PBS-User pro PVE-Host: nur Datastore.Backup und Datastore.Read. Denk dran: die eigenen Backup-Gruppen kann dieser User trotzdem löschen — dagegen helfen Protected-Flag und Schicht 2.
2. Datastore-Prune-Job läuft Admin-seitig: Dein PVE-Host braucht keine Modify-Rechte.
3. Wichtige Snapshots als Protected markieren: ein Snapshot mit Protected-Flag übersteht Prune und manuelles Löschen — siehe Prune erklärt. Wenn Du Schutz gegen gezielte Lösch-Angriffe brauchst, richten wir Dir auf Anfrage auch einen separaten Append-Only-Datastore ein — schreib uns ein Ticket.
4. MFA auf Deinem PBS-Admin-Account: dringend empfohlen.

Das schützt gegen 95 % aller Ransomware-Szenarien.

Häufige Fragen

Was passiert, wenn der Angreifer mein PBS-Admin-Passwort hat? Er kann alles löschen, auch mit “least privilege”-Setup. Daher: MFA auf dem PBS-Admin-Login. Plus: zweiter PBS als Sync-Target schützt zusätzlich.

Reicht Least Privilege allein als Ransomware-Schutz? Nein. Mit Datastore.Backup kann der Owner seine eigenen Backups weiterhin löschen — genau die, die ein kompromittierter Host geschrieben hat. Least Privilege verkleinert die Angriffsfläche, gegen gezielte Backup-Löschung hilft erst der Sync auf einen zweiten PBS oder das Protected-Flag.

Kann ich nachträglich auf “least privilege” umstellen? Ja, jederzeit. Im PBS einen neuen Token mit reduzierten Rechten erstellen, im PVE-Storage hinterlegen, alten Token revoken.

Was, wenn ich versehentlich selbst Backups lösche? Das kann auch mit “least privilege” passieren — die eigenen Backup-Gruppen kann der Backup-User löschen. Schutz für einzelne wichtige Snapshots: Protected-Flag setzen. Schutz für alles: Sync auf einen zweiten PBS mit eigener, längerer Retention.

Ist Air Gap zuhause realistisch? Für Privatkunden eher nicht. Wer ein LTO-Laufwerk zuhause betreibt, hat schon einen Profi-Setup. Für die meisten ist die Kombi „PBS bei xaweho + Sync zu zweitem PBS” + MFA + Verschlüsselung ausreichend.

Bekommt jemand Backups durch CLOUD-Act-Anfrage? Nein. Wir sind eine deutsche UG, Hardware in Deutschland, kein US-Bezug. Dazu sind verschlüsselte Backups auch ohne Schlüssel wertlos — selbst wenn jemand physisch unsere Disks bekommen würde.

Weiter geht’s

• Sync Jobs — Backups an einen zweiten PBS spiegeln
• Verschlüsselungs-Schlüssel erstellen und sicher aufbewahren
• E-Mail-Notifications einrichten