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
• Datastore.Reader — darf bestehende Backups lesen (für Restore)
• NICHT Datastore.Modify — kein Löschen, kein Prune

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

Wenn der Angreifer den Token klaut, kann er noch Backups schreiben (was Dir nicht schadet), aber nichts löschen. Prune und GC machst nur Du als Admin, manuell oder per Schedule auf dem Datastore-Level.

Das ist die einfachste Schutzschicht. Sie reicht gegen die meisten Ransomware-Szenarien.

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 “kann nicht löschen” (Schicht 1) ist das doppelt sicher.

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.Reader.
2. Datastore-Prune-Job läuft Admin-seitig: Dein PVE-Host kann nichts löschen.
3. Wir bei xaweho machen ZFS-Snapshots auf der PBS-Hardware: heißt, selbst wenn Du als Admin bei uns auf der PBS-GUI Snapshots löschst, gibt’s ZFS-Snapshots davon, aus denen wir restoren können. Frag bei kritischer Sache nach — wir machen das nicht standardmäßig, aber auf Wunsch.
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 es, mein PVE-Backup-User schreibgeschützt zu machen? Für die häufigste Ransomware-Variante ja. Profi-Angreifer suchen aktiv nach PBS-Setups und versuchen sie zu kompromittieren — daher zusätzliche Schichten sinnvoll.

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? Mit “least privilege” als PVE-User kannst Du das vom PVE aus nicht — Du müsstest Dich am PBS einloggen. Versehentliche Löschung passiert dann nur, wenn Du absichtlich am PBS-Admin-Login bist und prunst.

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