Immutable Backups: Ransomware-Schutz mit WORM, PBS und ZFS Snapshots

Ransomware hat ihr Vorgehen verändert. Moderne Angriffe zielen gezielt auf Backup-Systeme, bevor sie Produktivdaten verschlüsseln. Wenn Backups zusammen mit den Originaldaten kompromittiert werden, bleibt kein Wiederherstellungspunkt. Immutable Backups — unveränderliche Sicherungen, die nachträglich weder gelöscht noch verschlüsselt werden können — sind die letzte Verteidigungslinie.

Das Konzept: WORM und Immutability

Was bedeutet immutable?

Ein immutabler Backup ist eine Datensicherung, die nach dem Schreiben nicht mehr verändert werden kann — weder vom Administrator noch von einem Angreifer mit Root-Zugriff auf das Backup-System.

WORM steht für Write Once, Read Many: Daten können einmal geschrieben und danach beliebig oft gelesen, aber nicht überschrieben oder gelöscht werden.

Warum Backups angreifbar sind

Ein typischer Ransomware-Angriff auf Backup-Infrastruktur:

1. Initiale Kompromittierung (Phishing, Exploit)
2. Lateral Movement im Netzwerk
3. Backup-Credentials ausspähen
4. Backup-Server kompromittieren
5. Backups löschen oder verschlüsseln
6. Produktivdaten verschlüsseln
7. Lösegeldforderung

Zwischen Schritt 1 und 6 vergehen oft Wochen bis Monate. In dieser Zeit hat der Angreifer Zeit, alle erreichbaren Backup-Systeme zu identifizieren und zu kompromittieren.

Drei Verteidigungsebenen

Ebene	Maßnahme	Schutz gegen
1. Immutability	WORM-Backups, unveränderliche Snapshots	Backup-Löschung und -Verschlüsselung
2. Air-Gap	Physische oder logische Trennung	Netzwerk-basierte Angriffe
3. Separation of Credentials	Getrennte Authentifizierung	Credential-Theft

Professioneller Ransomware-Schutz kombiniert alle drei Ebenen.

Proxmox Backup Server: Immutable Datastores

Proxmox Backup Server (PBS) bietet seit Version 3.0 native Unterstützung für Datastore-basierte Immutability.

Retention-basierter Schutz

PBS verhindert das Löschen von Backups innerhalb der konfigurierten Retention-Periode:

Datastore-Konfiguration:
├── Name: production-backups
├── Path: /mnt/datastore/production
├── Retention:
│   ├── Keep Daily:   7
│   ├── Keep Weekly:  4
│   ├── Keep Monthly: 6
│   └── Keep Yearly:  2
└── Verification: Automatisch (täglich)

Namespace-Isolation

PBS unterstützt Namespaces, die Backup-Daten logisch voneinander trennen. Jeder Namespace kann eigene Berechtigungen haben:

# Namespace erstellen
proxmox-backup-manager namespace create production-backups/customer-a

# Berechtigungen: Nur Backup-Client darf schreiben
proxmox-backup-manager acl update /datastore/production-backups/customer-a \
  backup-client@pbs DatastoreBackup

Der Backup-Client hat die Rolle DatastoreBackup (nur schreiben und lesen) — nicht DatastoreAdmin (könnte löschen). Selbst wenn der Proxmox-VE-Host kompromittiert wird, kann der Angreifer mit den Backup-Credentials keine Backups löschen.

Clientseitige Verschlüsselung

PBS unterstützt clientseitige Verschlüsselung mit AES-256-GCM. Die Backups werden auf dem Proxmox-VE-Host verschlüsselt, bevor sie an PBS übertragen werden:

# Encryption Key erstellen
proxmox-backup-client key create /etc/pve/priv/backup-encryption-key.json

# Backup mit Verschlüsselung
proxmox-backup-client backup vm/100.img:/dev/vg/vm-100-disk-0 \
  --keyfile /etc/pve/priv/backup-encryption-key.json \
  --repository backup-user@pbs@backup-server:production-backups

Selbst wenn ein Angreifer Zugriff auf den PBS-Server erlangt, sind die Backup-Daten ohne den Encryption Key wertlos. Den Key sollte man an einem sicheren, separaten Ort aufbewahren.

Verify-Jobs

PBS kann Backups automatisch verifizieren, um sicherzustellen, dass sie nicht korrumpiert sind:

# Verify-Job konfigurieren (prüft Integrität aller Chunks)
proxmox-backup-manager verify-job create daily-verify \
  --store production-backups \
  --schedule "daily" \
  --outdated-after "7d"

Verify-Jobs erkennen Bitrot, beschädigte Chunks und andere Integritätsprobleme, bevor sie bei einer Wiederherstellung auffallen.

TrueNAS ZFS Snapshots als Immutable Backup

ZFS-Snapshots sind von Natur aus read-only: Ein Snapshot kann nicht verändert werden, nachdem er erstellt wurde. Das macht sie zu einer natürlichen Basis für immutable Backups.

Warum ZFS-Snapshots nicht automatisch sicher sind

Ein Angreifer mit Root-Zugriff auf das TrueNAS-System kann Snapshots löschen:

# Ein Angreifer mit Root-Zugriff kann:
zfs destroy tank/data@backup-2026-04-12
# Snapshot gelöscht — kein immutable Schutz!

ZFS-Snapshot-Schutz durch Holds

ZFS bietet die Hold-Funktion, die das Löschen eines Snapshots verhindert:

# Hold auf Snapshot setzen
zfs hold keep tank/data@backup-2026-04-12

# Jetzt schlägt destroy fehl:
zfs destroy tank/data@backup-2026-04-12
# cannot destroy 'tank/data@backup-2026-04-12': dataset is busy

# Holds anzeigen
zfs holds tank/data@backup-2026-04-12

# Hold entfernen (nur mit explizitem Befehl)
zfs release keep tank/data@backup-2026-04-12

Holds bieten einen gewissen Schutz, sind aber nicht wirklich immutable — ein Angreifer mit Root-Zugriff kann den Hold entfernen und dann löschen.

Echte Immutability: Replikation auf separates System

Für echte Immutability müssen die Snapshots auf ein separates System repliziert werden, auf das der Angreifer keinen Zugriff hat:

# Auf dem Quell-System: Replikation konfigurieren
zfs send -Ri tank/data@snap-001 | ssh backup-nas zfs recv -F backup-pool/data

# Auf dem Ziel-System (backup-nas):
# - Eigene Credentials (kein gemeinsames Root-Passwort)
# - Eigenes Netzwerk-Segment
# - Nur eingehende Replikation erlaubt (kein SSH-Zugriff vom Quell-System)

Air-Gap Strategien

Physischer Air-Gap

Der klassische Air-Gap: Das Backup-Medium ist physisch vom Netzwerk getrennt.

Wochentag    Aktion
Montag       Backup auf USB-HDD "A", dann trennen und lagern
Dienstag     Backup auf USB-HDD "B", dann trennen und lagern
...
Sonntag      Wöchentliches Full-Backup auf Band/RDX

Vorteile: Maximaler Schutz, Angreifer kann das Medium nicht erreichen Nachteile: Manueller Aufwand, menschliche Fehler (Medium vergessen einzustecken)

Virtual Air-Gap

Ein Virtual Air-Gap emuliert die physische Trennung durch logische Maßnahmen:

┌─────────────────┐         ┌─────────────────┐
│  Produktivnetz  │         │  Backup-Netz    │
│  10.0.1.0/24    │         │  10.0.99.0/24   │
│                 │         │                 │
│  Proxmox VE    │────X────│  PBS / TrueNAS  │
│  TrueNAS       │         │  (Backup-Ziel)  │
└─────────────────┘         └─────────────────┘
        │                          │
   ┌────┴────┐                ┌────┴────┐
   │ VLAN 10 │                │ VLAN 99 │
   └─────────┘                └─────────┘

Firewall-Regeln für den Virtual Air-Gap:

# OPNsense Firewall Rules (VLAN 99 - Backup-Netz):
# ALLOW: Produktivnetz → Backup-Netz (Port 8007, PBS)
# ALLOW: Produktivnetz → Backup-Netz (Port 22, SSH für Replikation)
# DENY:  Backup-Netz → Produktivnetz (ALLES)
# DENY:  Backup-Netz → Internet (ALLES)

Das Backup-Netz kann zwar empfangen, aber nicht nach außen kommunizieren. Selbst wenn ein Angreifer das Produktivnetz kompromittiert, kann er keine Verbindung zum Backup-System aufbauen (keine Antwortpakete möglich).

Zeitgesteuerter Air-Gap

Eine elegante Variante: Das Backup-System ist nur zu definierten Zeiten erreichbar:

# Cron-Job auf der Firewall: Backup-Netz nur nachts erreichbar
# 02:00 Uhr: Firewall-Regel aktivieren
0 2 * * * pfctl -a backup_window -f /etc/pf-backup-allow.conf

# 04:00 Uhr: Firewall-Regel deaktivieren
0 4 * * * pfctl -a backup_window -F rules

Außerhalb des Backup-Fensters ist das Backup-System vollständig isoliert — auch für einen Angreifer, der den Produktivserver kontrolliert.

Credential-Trennung

Separate Accounts

Das Backup-System muss eigene, unabhängige Credentials verwenden:

Komponente	Benutzername	Passwort/Key	Bemerkung
Proxmox VE	root@pam	Passwort A	Hypervisor-Admin
PBS	backup-admin@pbs	Passwort B	PBS-Admin (separat!)
PBS API	backup-client@pbs	API-Token	Nur Backup-Rechte
TrueNAS (Backup)	admin	Passwort C	Separates System

Niemals dasselbe Root-Passwort oder denselben SSH-Key für Produktiv- und Backup-Systeme verwenden.

Kein Domain-Join für Backup-Systeme

Das Backup-System sollte nicht der Active-Directory-Domain beitreten. Ein Angreifer, der Domain-Admin wird, hätte sonst automatisch Zugriff auf alle domänenverbundenen Systeme — einschließlich der Backups.

Praxisbeispiel: 3-2-1-Strategie mit Immutability

Backup-Tier 1: Proxmox PBS (lokal, SSD)
├── Retention: 7 daily, 4 weekly, 6 monthly
├── Verschlüsselung: Clientseitig (AES-256-GCM)
├── Verify-Jobs: Täglich
└── Credentials: Nur backup-client@pbs (kein Admin-Zugriff von PVE)

Backup-Tier 2: TrueNAS (VLAN 99, Virtual Air-Gap)
├── ZFS-Replikation von PBS (Pull-Modus)
├── Snapshots mit Holds
├── Eigenes Admin-Konto
└── Firewall: Nur eingehende Replikation erlaubt

Backup-Tier 3: Offsite (Cloud oder physisch)
├── PBS Remote-Sync oder ZFS Send
├── Verschlüsselt (Keys offline gespeichert)
├── Physisch oder geographisch getrennt
└── Monatliche Restore-Tests

Test und Validierung

Immutable Backups sind wertlos, wenn sie nicht wiederhergestellt werden können. Regelmäßige Tests sind Pflicht:

# PBS: Backup-Integrität prüfen
proxmox-backup-client verify --repository backup-user@pbs@server:store

# TrueNAS: Snapshot-Integrität prüfen
zfs list -t snapshot -o name,used,refer tank/data | tail -10

# Restore-Test: VM aus Backup wiederherstellen (auf Test-Host)
qmrestore /mnt/pbs/dump/vzdump-qemu-100-2026_04_12.vma 999 --storage local-lvm

Mindestens einmal pro Quartal sollte ein vollständiger Restore-Test durchgeführt werden — von der Backup-Integrität bis zur erfolgreichen VM-Boot-Prüfung.

Fazit

Immutable Backups sind keine optionale Ergänzung mehr — sie sind eine Notwendigkeit in jeder IT-Umgebung. Proxmox PBS bietet mit Namespace-Isolation, clientseitiger Verschlüsselung und Verify-Jobs eine solide Basis. TrueNAS mit ZFS-Snapshots und Replikation ergänzt als zweite Ebene. Ein Virtual Air-Gap mit dediziertem VLAN und restriktiven Firewall-Regeln macht das Backup-System selbst für einen Angreifer im Produktivnetz unerreichbar. Die Kombination aller drei Maßnahmen — Immutability, Air-Gap und Credential-Trennung — bietet den bestmöglichen Schutz gegen Ransomware.