Veeam Immutable Backups: Ransomware-resistente Repositories aufbauen

Warum “normale” Backups gegen moderne Ransomware nicht mehr reichen

Vor ein paar Jahren war ein Backup-Server das rettende Ufer nach einem Ransomware-Befall. Heute ist er oft das erste Ziel. Moderne Ransomware-Gruppen (LockBit-Nachfolger, Akira, Cl0p, Medusa) suchen aktiv nach Backup-Infrastruktur, bevor sie die eigentliche Verschluesselung starten - sie loeschen Snapshots, deaktivieren Backup-Jobs, verschluesseln oder exfiltrieren Repositories und erst danach zuenden sie die Payload auf den Produktivsystemen. Wenn dein Backup-Repository ein normal beschreibbares Windows- oder SMB-Share ist, auf das der Backup-Server mit Domain-Credentials zugreift, ist es fuer einen Angreifer mit Domain-Admin-Rechten genauso erreichbar wie jeder andere Server.

Die Antwort darauf heisst Immutability: Backup-Daten werden fuer eine definierte Zeitspanne technisch unveraenderlich gemacht - nicht durch Berechtigungen (die ein Admin umgehen kann), sondern auf Dateisystem- oder Objektspeicher-Ebene. Selbst der Root-User oder ein kompromittierter Domain-Admin kann die Daten innerhalb der Retention-Periode nicht loeschen oder ueberschreiben.

Dieser Artikel zeigt dir, wie du mit Veeam Backup & Replication ein wirklich ransomware-resistentes Repository-Konzept aufbaust: Hardened Linux Repository mit XFS-Immutability, S3 Object Lock in Compliance- und Governance-Mode, die erweiterte 3-2-1-1-0-Regel, Air-Gap-Strategien mit Tape und die eingebaute Ransomware-Erkennung inklusive sauberer Restore-Tests.

Die erweiterte 3-2-1-1-0-Regel

Die klassische 3-2-1-Regel (3 Kopien, 2 Medientypen, 1 Kopie extern) reicht gegen Ransomware nicht mehr aus, weil sie nichts darueber aussagt, ob eine Kopie unveraenderlich ist. Veeam und die Backup-Community haben sie deshalb um zwei Ziffern erweitert:

Wichtig fuer die Praxis: Die “1” fuer Immutable/Air-Gap ist zusaetzlich zu den drei Kopien zu verstehen, nicht als Ersatz. Ein KMU mit begrenztem Budget baut typischerweise so:

1. Primaer-Repository: Hardened Linux Repository mit lokaler Immutability (z. B. 7 Tage) fuer schnelle Restores.
2. Backup Copy Job auf S3-kompatiblen Object Storage mit Object Lock (z. B. 30-90 Tage Immutability) fuer die externe, unveraenderliche Kopie.
3. Monatliches GFS-Restore-Band oder Wechselfestplatten-Rotation als echter Air-Gap fuer Langzeitarchivierung (1-7 Jahre, je nach Compliance-Vorgabe).

Hardened Linux Repository: Immutability auf XFS-Ebene

Das Hardened Linux Repository (auch VHR, Veeam Hardened Repository) ist die On-Premises-Antwort auf Immutability. Es basiert auf einem gehaerteten Linux-Server (offiziell unterstuetzt: Rocky Linux, RHEL-Derivate), auf dem Veeam ueber den Data Mover Dateien in einem XFS-Dateisystem ablegt und per chattr +i (Immutable-Flag im Extended-Attribut-Sinn) unveraenderlich macht.

Warum genau XFS?

Veeam nutzt fuer die Immutability-Funktion zwei XFS-spezifische Eigenschaften:

• Reflink / Fast Clone: XFS unterstuetzt Copy-on-Write-Klone von Blocks (Reflinks). Damit kann Veeam bei synthetischen Volls (Synthetic Fulls) Blocke referenzieren statt physisch zu kopieren - massiv schneller und platzsparender.
• Immutable-Attribut auf Dateiebene: Der Linux-Kernel unterstuetzt das immutable-Flag ueber chattr. Solange dieses Flag gesetzt ist, kann selbst root die Datei nicht loeschen, umbenennen oder ueberschreiben - nur das Flag selbst entfernen, was Veeam erst nach Ablauf der Retention-Periode tut.

Architektur-Grundregeln

Empfohlene Mindest-Anforderungen (Stand Veeam v12/v13):

• Unterstuetzte Linux-Distribution mit XFS als Dateisystem fuer das Repository-Volume (nicht fuer /)
• Separater, dedizierter Host oder VM - nicht der gleiche Host wie der Backup-Server
• Kein Domain-Join, keine gemeinsame Authentifizierung mit dem Windows-AD
• SSH nur fuer Setup, danach idealerweise deaktivieren oder auf Zertifikats-Auth mit stark eingeschraenkter IP-Quelle reduzieren
• NTP korrekt konfiguriert (die Immutability-Periode wird zeitbasiert berechnet - eine falsche Systemzeit kann die Schutzwirkung aushebeln)

Einrichtung: Schritt fuer Schritt

1. Linux-Host vorbereiten (Rocky Linux 9, Beispiel):

# XFS-Partition fuer das Repository anlegen
lsblk
sudo mkfs.xfs -m reflink=1 /dev/sdb1
sudo mkdir -p /mnt/veeamrepo
sudo mount /dev/sdb1 /mnt/veeamrepo

# Dauerhaft in fstab eintragen (UUID ermitteln mit blkid)
echo 'UUID=<deine-uuid> /mnt/veeamrepo xfs defaults 0 0' | sudo tee -a /etc/fstab

# Reflink-Support pruefen
xfs_info /mnt/veeamrepo | grep reflink

2. Dedizierten Backup-Operator-User anlegen (kein root, kein sudo fuer den Data Mover):

sudo useradd -m -d /home/veeamrepo veeamrepo
sudo passwd veeamrepo
sudo chown -R veeamrepo:veeamrepo /mnt/veeamrepo

3. Repository in der Veeam-Konsole hinzufuegen:

• Backup Infrastructure -> Backup Repositories -> Add Repository -> Direct Attached Storage -> Linux (Hardened Repository, Rotated drives o. ae. je nach Zielsetzung)
• Verbindung per SSH mit dem veeamrepo-User herstellen
• Pfad /mnt/veeamrepo auswaehlen
• “Use fast cloning on XFS volumes” aktivieren
• “Make recent backups immutable for [N] days” aktivieren und Periode setzen

Als Konfigurationsbeispiel fuer die Retention in einer Backup-Job-Definition (per PowerShell-Modul Veeam.Backup.PowerShell):

# Repository-Objekt holen und Immutability pruefen/setzen
$repo = Get-VBRBackupRepository -Name "HardenedRepo-XFS01"
$repo.Options

# Neuen Backup Job mit taeglicher GFS-Policy und Immutability-Bezug anlegen (vereinfachtes Beispiel)
Add-VBRViBackupJob -Name "PROD-VMs-Daily" `
  -Entity (Find-VBRViEntity -Name "VM-FileServer01") `
  -BackupRepository $repo `
  -CompressionLevel Optimal

Grenzen des Hardened Repository

• Kein Deduplizierungs-Storage von Drittherstellern kompatibel (kein ReFS-Dedupe, kein Data-Domain-Boost fuer Immutability-Zwecke gleichzeitig)
• Skaliert nur so weit wie ein einzelner Linux-Host bzw. als Scale-Out Backup Repository (SOBR) mit mehreren Hardened-Extents
• Kein Schutz gegen physischen Verlust/Zerstoerung des Hosts (Brand, Diebstahl) - dafuer braucht es weiterhin eine externe/Air-Gap-Kopie

S3 Object Lock: Immutability in der Cloud - Compliance vs. Governance Mode

Fuer die externe, unveraenderliche 3-2-1-1-0-Kopie ist S3-kompatibler Object Storage mit Object Lock die gaengigste Wahl - egal ob AWS S3, Wasabi, Backblaze B2, MinIO on-prem oder ein Schweizer Provider mit S3-API. Object Lock ist ein Feature des S3-Standards (WORM - Write Once Read Many), das Objekte fuer eine definierte Zeit vor Loeschung und Ueberschreibung schuetzt.

Veeam unterstuetzt zwei Object-Lock-Modi:

Veeam nutzt standardmaessig den Compliance Mode. Willst du stattdessen Governance Mode (z. B. weil ein Provider das erfordert oder du versehentlich zu lang gesetzte Retentions korrigieren koennen willst), aktivierst du das serverweit per Registry:

; Auf dem Veeam Backup Server, per Registry-Editor oder PowerShell
; Pfad: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
; Wert: S3GovernanceImmutabilityMode (DWORD)
; 0 = Compliance Mode (Standard), 1 = Governance Mode

New-ItemProperty -Path "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication" `
  -Name "S3GovernanceImmutabilityMode" -PropertyType DWORD -Value 1 -Force

Object Storage als Capacity Tier vs. eigenstaendiges Repository

Zwei gaengige Architekturen fuer S3 mit Veeam:

1. Scale-Out Backup Repository (SOBR) mit Capacity Tier: Lokales Hardened Repository als Performance Tier, S3-Bucket mit Object Lock als Capacity Tier. Aeltere Restorepoints wandern automatisch (oder sofort per “Move backups to object storage as soon as data is created” fuer maximale Immutability-Abdeckung) in den unveraenderlichen Cloud-Speicher.
2. Direkter Backup Copy Job auf S3-Repository: Eigener Job kopiert taeglich/woechentlich vom Primaer-Repository auf den S3-Bucket. Klarere Trennung, aber doppelter Netzwerk-Traffic und weniger Automatisierung als SOBR-Tiering.

Fuer die meisten Schweizer KMU ist Variante 2 (separater Backup Copy Job) einfacher zu verstehen, zu ueberwachen und im Fehlerfall zu debuggen - Variante 1 (SOBR-Tiering) lohnt sich eher ab groesseren Datenmengen, wo die automatische Storage-Optimierung Kosten spart.

Air-Gapped Tape und Rotationsmedien

Auch wenn Object Storage und Hardened Repositories den grossen Teil der Praxis abdecken, bleibt Tape (LTO) die einzige Technologie mit echtem, physikalischem Air-Gap - ein Band, das aus dem Laufwerk entnommen und im Tresor gelagert wird, kann von keinem Angreifer der Welt über das Netzwerk erreicht werden.

Typisches GFS-Tape-Konzept mit Veeam

• Grandfather-Father-Son (GFS)-Retention-Policy im Backup-to-Tape-Job: taegliche Baender (Son), woechentliche Vollsicherung (Father), monatliche/jaehrliche Langzeitarchivierung (Grandfather)
• Rotation ueber mehrere Bandsaetze, sodass immer mindestens ein Satz offline im Tresor liegt, waehrend der naechste beschrieben wird
• WORM-Tapes (Write Once Read Many, physisch durch eine Kassettenmechanik geschuetzt) fuer die Langzeit-Grandfather-Kopie, wo gesetzliche Aufbewahrungsfristen gelten (z. B. Buchhaltungsdaten nach OR Art. 958f: 10 Jahre)

# Beispiel: Backup-to-Tape-Job per PowerShell abfragen und Medien-Pool pruefen
Get-VBRTapeJob | Select-Object Name, LastResult, NextRun
Get-VBRTapeMediaPool -Name "GFS-Monthly-Pool"

Fuer KMU ohne eigene Tape-Library ist eine kostenguenstigere Alternative die Wechselfestplatten-Rotation: Ein Hardened-Repository-aehnliches Konzept auf USB- oder eSATA-Wechseldatentraegern, die nach dem Backup manuell entfernt und in einem Safe oder an einem zweiten Standort gelagert werden. Wichtig dabei: Der Datentraeger darf nicht dauerhaft am Backup-Server angeschlossen bleiben, sonst ist der Air-Gap wirkungslos.

Ransomware-Erkennung direkt in Veeam: Inline Entropy Scan

Seit Veeam v12 (und deutlich ausgebaut in v12.1/v13) bringt Veeam Backup & Replication eine eingebaute Malware-Erkennung mit, die waehrend des Backup- oder Restore-Vorgangs verdaechtige Muster erkennt - ganz ohne separates Security-Produkt.

Wie die Erkennung funktioniert

1. Inline Entropy Scan: Waehrend der Datenstrom fuer ein Backup verarbeitet wird, misst Veeam die Entropie (statistische Zufaelligkeit) der Datenblocke. Verschluesselte Dateien haben eine sehr hohe, gleichmaessige Entropie - ein typisches Muster fuer Ransomware-verschluesselte Nutzdaten. Ueberschreitet der Anteil “verdaechtig hoher Entropie”-Blocke einen Schwellwert innerhalb eines Backup-Jobs, markiert Veeam den Restorepoint als potenziell kompromittiert.
2. Signatur- und Artefakt-Erkennung: Zusaetzlich sucht Veeam nach bekannten Ransomware-Artefakten - Lösegeldforderungen (Ransom Notes), typische Dateiendungen bekannter Verschluesselungs-Familien, .onion-Adressen im Klartext, YARA-Regeln fuer bekannte Malware-Familien (z. B. Medusa, Cl0p).
3. I/O-Anomalie-Erkennung (Veeam ONE): Ergaenzend ueberwacht Veeam ONE das I/O-Verhalten von VMs - ploetzlich massiv erhoehte Schreib-Last oder ungewoehnliche Dateizugriffsmuster koennen auf einen laufenden Verschluesselungsvorgang hindeuten, noch bevor das naechste Backup ansteht.

# Malware-Erkennungsstatus eines Restorepoints per PowerShell pruefen
Get-VBRBackup -Name "PROD-VMs-Daily" | Get-VBRRestorePoint |
  Select-Object VmName, CreationTime, IsMalwareDetected

Praktisch bedeutet das: Wenn ein Malware-Detection-Alarm auf einem Restorepoint auftaucht, markiere alle folgenden (und ggf. einige vorherige) Restorepoints als verdaechtig und arbeite dich rueckwaerts durch die Kette, bis du einen garantiert sauberen Punkt findest - genau dafuer brauchst du eine ausreichend lange Restorepoint-Historie (siehe Immutability-Periode oben).

Entscheidungsbaum: Welches Immutability-Konzept fuer welches Szenario?

Start: Brauche ich Immutability fuer dieses Repository?
│
├─ Ist es das Primaer-/Performance-Repository (schnelle taegliche Restores)?
│   └─ JA → Hardened Linux Repository (XFS, lokal, 14-30 Tage Immutability)
│
├─ Brauche ich eine externe/Offsite-Kopie?
│   └─ JA → S3-Object-Storage mit Object Lock
│         ├─ Regulatorische Vorgaben / maximale Sicherheit? → Compliance Mode
│         └─ Betriebliche Flexibilitaet noetig?           → Governance Mode
│
├─ Gibt es gesetzliche Aufbewahrungsfristen (>1 Jahr, Buchhaltung etc.)?
│   └─ JA → GFS-Tape oder WORM-Tape als Grandfather-Kopie
│
└─ Ist das Budget sehr klein (kein Tape, kein Cloud-Storage moeglich)?
    └─ Rotated-Drives-Repository (Wechselfestplatten, manuell ausgesteckt)

Restore-Test nach simuliertem Befall: SureBackup als Generalprobe

Ein unveraenderliches Backup nutzt nichts, wenn du im Ernstfall nicht weisst, ob und wie schnell du damit wirklich wieder online bist. SureBackup startet VMs direkt aus dem Backup-File heraus (ohne vorherigen vollstaendigen Restore) in einer isolierten Virtual Lab-Netzwerkumgebung und prueft automatisiert:

• Bootet die VM ueberhaupt sauber?
• Antworten die konfigurierten Dienste (Ping, Port-Checks, benutzerdefinierte Skripte)?
• Laeuft ein Antiviren-/Malware-Scan gegen das gemountete Dateisystem sauber durch?

Ablauf eines realistischen Restore-Tests nach Ransomware-Verdacht

1. Virtual Lab einrichten: Isoliertes Netzwerksegment ohne Route ins Produktivnetz, ggf. mit Proxy-Appliance fuer IP-Masquerading, damit die getestete VM mit denselben IPs wie in Produktion laufen kann, ohne Konflikte zu verursachen.
2. Application Group definieren: Bei mehrstufigen Anwendungen (z. B. Domain Controller vor Fileserver vor ERP-App-Server) die Startreihenfolge und Abhaengigkeiten festlegen.
3. SureBackup-Job gegen die verdaechtigen Restorepoints laufen lassen - inklusive Malware-Scan-Integration (Veeam kann hier auch Antivirus-Engines Dritter in die Boot-Sequenz einhaengen).
4. Manuelle Verifikation: Bei kritischen Systemen zusaetzlich per RDP/Console in die isolierte Lab-VM einloggen und stichprobenartig pruefen (Dateien vorhanden? Datenbank konsistent? Keine Ransom Notes?).
5. Dokumentation: Ergebnis, getesteter Restorepoint-Zeitstempel und RTO (tatsaechlich gemessene Zeit bis Verfuegbarkeit) im Notfallplan festhalten - siehe auch IT-Notfallplanung & Disaster Recovery.

# SureBackup-Job manuell anstossen und Ergebnis abfragen
Start-VBRJob -Job (Get-VBRJob -Name "SureBackup-PROD-Quarterly")
Get-VBRTaskSession -Job (Get-VBRJob -Name "SureBackup-PROD-Quarterly") |
  Select-Object Name, Status, Result

Haeufige Fallstricke in der Praxis

• Immutability-Periode zu kurz gewaehlt: 3-5 Tage reichen oft nicht, weil Ransomware-Gruppen sich teils wochenlang unentdeckt im Netz bewegen, bevor sie zuschlagen.
• Backup-Server-Credentials im gleichen AD wie die Produktivumgebung: Wenn der Veeam-Server-Account Domain-Admin-Rechte hat oder mit denselben Credentials wie Produktivsysteme laeuft, ist ein kompromittiertes Konto ein direkter Weg zum Backup-Server. Empfehlung: dediziertes Service-Konto mit minimalen Rechten, MFA fuer die Konsole, idealerweise eigene Management-VLAN-Zone (siehe Zero-Trust-Architektur im KMU).
• Kein Offline-Restore-Test: Ein Restore, der nur “auf dem Papier” funktioniert, weil er nie ausprobiert wurde, ist ein Restore, der im Ernstfall scheitert.
• SOBR-Tiering ohne Object Lock im Capacity Tier: Wenn im Scale-Out Backup Repository nur das Performance Tier immutable ist, aber das Capacity Tier auf einem simplen SMB-NAS liegt, ist die “Offsite-Immutable”-Kopie in Wahrheit gar nicht unveraenderlich.
• XFS-Volume ohne Reflink-Support formatiert: Wird beim Anlegen der Partition reflink=1 vergessen, funktioniert Fast Clone nicht und synthetische Volls werden unnoetig langsam und platzintensiv.
• Vergessene Lizenz-/Kapazitaetsgrenzen bei Governance Mode: Nicht jeder S3-kompatible Anbieter unterstuetzt beide Object-Lock-Modi zuverlaessig - vor dem Providerwechsel unbedingt in der Herstellerdoku pruefen (“Veeam Ready Object” Zertifizierung ist ein guter Indikator).

Zusammenfassung: Minimal-Setup fuer ein Schweizer KMU

Wer klein anfangen will, aber trotzdem ransomware-resistent sein moechte, braucht mindestens:

1. Ein Hardened Linux Repository (XFS, 14-30 Tage Immutability) als Primaerziel.
2. Einen Backup Copy Job auf S3-Object-Storage mit Object Lock (Compliance Mode) fuer die externe Kopie.
3. Eine quartalsweise SureBackup- oder manuelle Restore-Uebung mit Dokumentation der gemessenen RTO.
4. Dedizierte, MFA-geschuetzte Zugangsdaten fuer die Veeam-Konsole, getrennt vom Produktiv-AD.
5. Regelmaessige Patches fuer Veeam Backup & Replication selbst.

Das ist kein Hexenwerk, aber es erfordert bewusste Architekturentscheidungen - “einfach ein Share als Repository anlegen” ist der Weg, der im Ernstfall zum Totalausfall fuehrt.

Weiterlernen

• Hardened Repository - Veeam Backup & Replication User Guide
• How Immutability Works - Veeam Help Center
• Inline Scan / Malware Detection - Veeam Help Center
• Backup Recovery Verification Tests (SureBackup) - Veeam Help Center
• Was ist die 3-2-1-Backup-Regel - Veeam Blog
• Immutable Backup Solutions: Linux Hardened Repository - Veeam Blog

Videos

YouTube