Ist eine "Rewind"-Funktion über ZFS-Snapshots in Proxmox praktikabel?

[div.Autumn]

Hallo zusammen,

ich plane aktuell ein neues Proxmox-Cluster für einen Kunden und evaluiere verschiedene Ansätze zum Schutz vor Ransomware und Bedienfehlern.

Dabei bin ich auf folgendes Konzept gestoßen:

Ein System soll im laufenden Betrieb kontinuierlich eingefroren bzw. gesichert werden, sodass es bei einem Ransomware-Befall oder einem größeren Fehler innerhalb von Sekunden bis wenigen Minuten auf einen früheren Zustand zurückgesetzt werden kann, ohne dass zunächst ein klassisches Backup zurückgespielt werden muss.

Meine Überlegung geht dabei in Richtung:

ZFS als Storage
sehr häufige Snapshots (z.B. alle 5 Minuten mittels Sanoid)
Snapshots lokal auf dem Storage vorhalten
im Fehlerfall Rückkehr auf einen definierten Zeitpunkt per ZFS-Rollback

Mich interessieren eure Praxiserfahrungen zu folgenden Punkten:

Wird ein solches Konzept produktiv eingesetzt?
Wie konsistent sind Rollbacks kompletter VMs bei sehr häufigen ZFS-Snapshots?
Wie löst ihr das Thema Ransomware, wenn sich die Snapshots auf demselben Storage befinden?
Nutzt jemand dafür zusätzlich Syncoid/ZFS-Replikation auf ein zweites System?
Welche Grenzen oder Fallstricke seht ihr im Vergleich zu klassischen Proxmox Backup Server Sicherungen?

Mir ist bewusst, dass Snapshots kein Ersatz für ein echtes Backup sind. Die Idee wäre vielmehr, eine sehr schnelle "Rewind"-Funktion für die letzten Stunden oder Tage zu realisieren und PBS weiterhin als Backup-Lösung zu nutzen.

Ich freue mich auf eure Erfahrungen und Best-Practices.

Grüße

 

[Falk R.]

Hallo zusammen,

ich plane aktuell ein neues Proxmox-Cluster für einen Kunden und evaluiere verschiedene Ansätze zum Schutz vor Ransomware und Bedienfehlern.

Dabei bin ich auf folgendes Konzept gestoßen:

Ein System soll im laufenden Betrieb kontinuierlich eingefroren bzw. gesichert werden, sodass es bei einem Ransomware-Befall oder einem größeren Fehler innerhalb von Sekunden bis wenigen Minuten auf einen früheren Zustand zurückgesetzt werden kann, ohne dass zunächst ein klassisches Backup zurückgespielt werden muss.

Meine Überlegung geht dabei in Richtung:

ZFS als Storage
sehr häufige Snapshots (z.B. alle 5 Minuten mittels Sanoid)
Snapshots lokal auf dem Storage vorhalten
im Fehlerfall Rückkehr auf einen definierten Zeitpunkt per ZFS-Rollback

Mich interessieren eure Praxiserfahrungen zu folgenden Punkten:

Wird ein solches Konzept produktiv eingesetzt?

Produktiv kenne ich das nicht. Aber es gibt Leute die solche Konzepte anbieten.

Wie konsistent sind Rollbacks kompletter VMs bei sehr häufigen ZFS-Snapshots?

Die Häufigkeit ist da egal. Die Häufigkeit hat mehr Einfluß auf den Impact der VMs. Konsistenz erhälst du wenn du wenn du über die Guest Tools konsistent macht, was aber jedes Mal einen Impact im Guest OS hat.

Wie löst ihr das Thema Ransomware, wenn sich die Snapshots auf demselben Storage befinden?

Genau deshalb finde ich das Konzept eher unschön.

Nutzt jemand dafür zusätzlich Syncoid/ZFS-Replikation auf ein zweites System?
Welche Grenzen oder Fallstricke seht ihr im Vergleich zu klassischen Proxmox Backup Server Sicherungen?

Snapshots sind kein Backup! Daher gibts da keinen Vergleich zum PBS. Backup muss trotzdem gemacht werden.

Mir ist bewusst, dass Snapshots kein Ersatz für ein echtes Backup sind. Die Idee wäre vielmehr, eine sehr schnelle "Rewind"-Funktion für die letzten Stunden oder Tage zu realisieren und PBS weiterhin als Backup-Lösung zu nutzen.

Ich freue mich auf eure Erfahrungen und Best-Practices.

Grüße

Ganz ehrlich, diese "Rewind" Funktion wirst du nie nutzen. Wenn Ransomware zugeschlagen hat, weißt du ohne Forensiker nicht wann es wirklich los gegangen ist. Meistens ist es auch nicht nur Ransomware sondern in der Regel Remotezugriff von Erpressergruppen und die sind dann schon lange im System gewesen und so ein kurzer Rollback bringt gar nichts.

Mach dir lieber ein vernünftiges Backupkonzept, wo kritische Daten oft genug gesichert werden. Dann sichere dein Backup gut ab und damit hast du deutlich bessere Karten in einem solchen Fall mit einem blauen Auge davon zu kommen.

Das Einzige wo so ein Rewind super ist, wenn dir mal ein Dateisystem Korrupt geht, aber das gibts extrem selten.

 

[LnxBil]

Sehe das ähnlich wie @Falk R.

Zusätzlich sei noch gesagt sein, dass du mit ZFS kein HA hast, es sei denn du kaufst dir eines dieser ZFS-HA-Storagesysteme, mit denen du einen "richtigen" Cluster betreiben kannst, also ohne Datenverlust (bis auf Crashkonsistenz) bei Knotenausfall einfach auf der anderen Seite starten kannst. Dann hast du das Storage komplett getrennt von deinem PVE und die Snapshots wären dann nicht mehr löschbar von den PVEs aus, aber eben auch nicht zurückrollbar von dort, denn das ist ja die Trennung, die du dann haben willst. Leider ist ZFS nicht für solche Dinge "am Werk" ausgestattet, was eine der größten Fehlentscheidungen bei der Konzeption vor 20 Jahren war und die Entwickler das auch bereuen, aber damals war das eben noch nicht so auf dem Schirm.

PBS ist super um sehr kurze Backupzyklen zu realisieren, klar natürlich mit längeren Restore-Zeiten, aber wie schon gesagt, Ransomware Infektion und "Ausbruch" können Monate auseinanderliegen und mal schnell einen Snapshot wiederherstellen ist in der Praxis keine Lösung dieses Problems, du wiegst dich hier nur in eine falsche Sicherheit. Gibt andere Szenarien wie z.B. Updates, die Dinge kaputtmachen, aber die testet man eh vorher lieber in einem Klone als auf Prod.

 

[proxuser77]

Nur ein paar Gedanken zu den Antworten hier: Fühlt euch frei, mich zu korrigieren, falls ich falsch liege.

1. Wenn zwischen Ransomware-Angriff und -Ausbruch Monate liegen, gilt das doch auch für die Backups. Das heißt, alle Backups der letzten Monate wären ebenfalls bereits infiziert.

2. Ja, ZFS-Snapshots sind kein Backup. Wenn man diese Snapshots jedoch via ZFS-Replication auf ein separates Storage repliziert, würde ich das schon als Backup betrachten.

3. Die mit Abstand größte Angriffsfläche in einem Firmennetz, zumindest wenn wir von Ransomware reden, sind die Endnutzer und somit die Clients. Wenn sich ein User etwas einfängt und die Angreifer alles verschlüsseln, auf das der User Zugriff hat, inklusive Netzlaufwerke und Dateien, die eventuell via Sync Client mit irgendeinem Filesharing-Dienst wie Nextcloud synchronisiert werden, können ZFS-Snapshots serverseitig helfen. Denn dann ist nur der Client mit der Malware infiziert und nicht der Server bzw. die VMs.

4. Wenn die VMs mit den Serverdiensten oder sogar der Hypervisor selbst kompromittiert sind, dann sind zuvor bereits mehrere Dinge extrem schiefgelaufen, und vor allem bei letzterem hat man dann richtig große Probleme. Erlangt ein Angreifer Admin-/Root-Rechte auf dem Proxmox-Server, kann er unter Umständen auch die Backups oder Snapshots löschen, was dann richtig ungünstig ist, ausser man hat noch Backups vom Backup, welche vom ersten Backup Server gepullt wurden, oder die Snapshots via Pull-Replikation gesichert, so dass der Angreifer keinen Zugriff darauf hat.

 

[Johannes S]

Denn dann ist nur der Client mit der Malware infiziert und nicht der Server bzw. die VMs.

Woher weißt du das? Envtl. hat die Ransomware auch schon Server übernommen und ihre Spuren im Log verwischt, ohne dass du es mitbekommst.
Sobald ein System komprpmittiert wurde, muss man alle als kompromittiert betrachten und neu aufsetzen, nützt alles nichts.

4. Wenn die VMs mit den Serverdiensten oder sogar der Hypervisor selbst kompromittiert sind, dann sind zuvor bereits mehrere Dinge extrem schiefgelaufen, und vor allem bei letzterem hat man dann richtig große Probleme. Erlangt ein Angreifer Admin-/Root-Rechte auf dem Proxmox-Server, kann er unter Umständen auch die Backups oder Snapshots löschen, was dann richtig ungünstig ist, ausser man hat noch Backups vom Backup, welche vom ersten Backup Server gepullt wurden, oder die Snapshots via Pull-Replikation gesichert, so dass der Angreifer keinen Zugriff darauf hat.

Darum hat man ja auch ein offsite-Backup, was sich zwar Backups pullen kann, selbst aber nicht vom lokalen Systemen erreichbar ist. Wenn man das nicht hat, dann hat man eh kein Backupkonzept, was den Namen verdient.

 

[Falk R.]

Nur ein paar Gedanken zu den Antworten hier: Fühlt euch frei, mich zu korrigieren, falls ich falsch liege.

1. Wenn zwischen Ransomware-Angriff und -Ausbruch Monate liegen, gilt das doch auch für die Backups. Das heißt, alle Backups der letzten Monate wären ebenfalls bereits infiziert.

Ja natürlich, deshalb installiert man auch alles neu und spielt nur die reinen Nutzdaten zurück.

2. Ja, ZFS-Snapshots sind kein Backup. Wenn man diese Snapshots jedoch via ZFS-Replication auf ein separates Storage repliziert, würde ich das schon als Backup betrachten.

Theoretisch ja, wenn du die Versionierung sauber im Griff hast.

3. Die mit Abstand größte Angriffsfläche in einem Firmennetz, zumindest wenn wir von Ransomware reden, sind die Endnutzer und somit die Clients. Wenn sich ein User etwas einfängt und die Angreifer alles verschlüsseln, auf das der User Zugriff hat, inklusive Netzlaufwerke und Dateien, die eventuell via Sync Client mit irgendeinem Filesharing-Dienst wie Nextcloud synchronisiert werden, können ZFS-Snapshots serverseitig helfen. Denn dann ist nur der Client mit der Malware infiziert und nicht der Server bzw. die VMs.

Wenn vom Client aus verschlüsselt wird ja. Aber das habe ich seit 3 Jahren nicht mehr gesehen. Heutzutage gehen die über die Clients lateral weiter durchs Netz bis die auf Servern landen.

4. Wenn die VMs mit den Serverdiensten oder sogar der Hypervisor selbst kompromittiert sind, dann sind zuvor bereits mehrere Dinge extrem schiefgelaufen, und vor allem bei letzterem hat man dann richtig große Probleme. Erlangt ein Angreifer Admin-/Root-Rechte auf dem Proxmox-Server, kann er unter Umständen auch die Backups oder Snapshots löschen, was dann richtig ungünstig ist, ausser man hat noch Backups vom Backup, welche vom ersten Backup Server gepullt wurden, oder die Snapshots via Pull-Replikation gesichert, so dass der Angreifer keinen Zugriff darauf hat.

Wenn du dein PBS richtig konfiguriert hast, löschst du vom PVE aus gar nichts.
Deshalb immer sauber absichern und korrekt einrichten.

 

[LnxBil]

Ja natürlich, deshalb installiert man auch alles neu und spielt nur die reinen Nutzdaten zurück.

Nur um das nochmal zu unterstreichen:
Das ALLES ist wichtig, wenn nur ein einziger Rechner im Netz übrig bleibt von vorher, kann von dort aus der Angriff wieder erfolgen. Manchmal werden ja unbekannte Lücken ausgenutzt, sodass dein gerade neu aufgebauter Rechner direkt wieder infiziert ist. Wenn du Pech hast ebenfalls erst Wochen / Monate später erkannt.

 

[fireon]

ZFS als Storage
sehr häufige Snapshots (z.B. alle 5 Minuten mittels Sanoid)
Snapshots lokal auf dem Storage vorhalten
im Fehlerfall Rückkehr auf einen definierten Zeitpunkt per ZFS-Rollback

Zu dem Thema kann ich dir berichten. Hatte ich auch beim Kunden so am Laufen, und verwende ich selbst seit Jahren. Gar nicht so wegen Ransomware in den VMs. Mehr als Bequemlichkeit nutze ich Autosnapshots: https://deepdoc.at/dokuwiki/doku.ph...s_autosnapshots_auf_zvol_und_datasets_mounten

Wenn mal was Böses passiert, oder ich gerade was teste und es geht schief, einfach mal die letzten 5/10/XX Minuten ein Rollback machen. Das geht wesentlich schneller als ein Backup vom PBS zu recovern. Natürlich, wie hier schon in dem Thread erwähnt wurde, Backup brauchste trotzdem
Also ohne Autosnap, würde ich nicht mehr wollen. Das Arbeiten mit VMs oder auch direkten ZFS-Datasets ist damit sooo viel entspannter.

 

[Johannes S]

Naja gegen ransomware ( darum hong es ja dem op ) ist der Nutzwert von zfs-auto-snapshots halt ohne Replikation eher begrenzt. Rein für VMS/Container finde ich https://github.com/Corsinvest/cv4pve-autosnap angenehmer, für zfs selbst sanoid/synchoid. Aber: Für ransomware. hilft das nur bedingt

 

[jsterr]

Naja gegen ransomware ( darum hong es ja dem op ) ist der Nutzwert von zfs-auto-snapshots halt ohne Replikation eher begrenzt. Rein für VMS/Container finde ich https://github.com/Corsinvest/cv4pve-autosnap angenehmer, für zfs selbst sanoid/synchoid. Aber: Für ransomware. hilft das nur bedingt

Wird man denke ich aber auch merken, wenn man z.B. im Ceph alle 5-10 Minuten einen Snapshot macht und alte ggf. aufräumt? Schonmal mit Ceph kombiniert?

 

[Johannes S]

Wird man denke ich aber auch merken, wenn man z.B. im Ceph alle 5-10 Minuten einen Snapshot macht und alte ggf. aufräumt? Schonmal mit Ceph kombiniert?

Nein, für mein Homelab wäre Ceph hoffnungslos überdimensioniert und mein Arbeitgeber ist leider aus diversen Gründen nach wie vor auf vmware unterwegs. Grundsätzlich müsste (ähnlich wie zfs-Replikation) auch die Replikation zwischen Ceph-Clustern dafür funktionieren, ich bin aber auch generell kein Fan von Backups, die nur mit einen bestimmten Storage-Backend funktionieren.

 

[Bu66as]

Bei Sanoid kommt noch dazu: Snapshots, die du außerhalb von PVE anlegst, kennt PVE nicht. Wenn dann pvesr oder normale VM-Snapshots im Spiel sind, kracht das zusammen, und ein zfs rollback wirft alles weg was nach dem Ziel-Snapshot kam, inklusive der PVE-eigenen Snapshots. Zum Rollback eines zvols muss die VM eh runter, live geht das nicht.

Das Problem dabei: Der Zustand ist crash-consistent, also wie wenn du den Stecker ziehen würdest. RAM/VM-State steckt im ZFS-Snapshot nicht drin. Dateisysteme stecken das meist weg, DBs nicht immer. Bei mehreren Disks pro VM musst du alle zvols auf den passenden Snapshot ziehen, sonst hast du Mischzustände.

Für Ransomware würde ich beim PBS ansetzen statt beim Storage: ein Offsite-PBS, der sich die Backups per Sync-Job selbst zieht (Pull statt Push), mit einem Token auf dem Quellsystem, der nur Datastore.Read hat (Rolle DatastoreReader). So kann ein gehackter Quell-Host die Offsite-Kopie nicht löschen. Dazu noch Verify-Jobs und lange Aufbewahrung auf dem Ziel. Wenn du zusätzlich schnelles Rewind brauchst, kommst du mit normalen PVE-Snapshots und pvesr auf einen zweiten Node weit, und bleibst dabei auf PVE-eigenen Wegen.