Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS
IT-Infrastrukturen werden immer raffinierteren Angriffen ausgesetzt. Ransomeware verschlüsselt nicht nur Live-Daten und ganze virtuelle Maschinen, inzwischen sind auch ganze Backups betroffen. Dabei spielt es keine Rolle, ob Ihre Online-Backups in einem lokalen Repository, oder auf einem Cloud-Share gespeichert sind.
Nun stellt sich die Frage, wie Sie die Backup-Daten schützen, falls ein Angreifer Zugriff auf Ihren Backup-Server erhält. Sobald er die Zugangsdaten zum Server hat, kann er alles tun, was der Backup-Administrator tun kann. Das Löschen von Backups zum Beispiel. Ein erster Schritt besteht darin, Ihre Backup-Systeme von Ihrer Domain zu trennen. Für den Fall, dass der Domain-Administrator-Account kompromittiert wird, gibt es immer noch eine (kleine) Barriere zwischen Angreifern und Ihren Backup-Systemen. Aber trotzdem werden Sie nie wissen, ob Angreifer Kenntnis von einem Zero-Day-Exploit haben, um Ihren Backup-Server zu übernehmen. Ein besserer Ansatz wäre es, Backups für eine definierte Zeitspanne gegen das Löschen zu schützen. Eine ähnliche Option gibt es bei AWS S3-Buckets, die üblicherweise als Offsite-Sicherungskopien verwendet werden. Das Zurückholen von Offsite-Backups nimmt eine beträchtliche Zeitspanne in Anspruch. Im Falle eines Kryptoangriffs ist die Zeit entscheidend und die Uhr tickt. Wäre es nicht großartig, unveränderliche Backups auf Ihren primären Repositories vor Ort zu haben?
Die Lösung:
Unveränderliche (Immutable) Backups
Die Idee dahinter ist, dass man einmal schreibt und dann die Backupfiles für eine selbst definierte Zeitspanne geschützt sind. Selbst der Backup-Administrator kann sie nicht löschen, bevor die definierte Zeitspanne verstrichen ist.
Seit der Version v11 von Veeam Backup & Replication kann die native Funktion des Linux XFS-Dateisystems genutzt werden. XFS kann ein erweitertes Dateiattribut [i] setzen, das die Datei vor Umbenennung, Änderung, Löschung oder Hard-Linking schützt. Der Clou dabei ist, dass Backups mit einem nicht privilegierten Konto übertragen und geschrieben werden und das Immutable-Attribut von einem Dienst auf dem Repository-Server gesetzt und entfernt wird, der erhöhte Rechte hat und auf den von außen nicht zugegriffen werden kann.
Hierzu ist ein Kontrollkästchen zu setzen, wenn man ein neues Backup-Repository hinzufügt (siehe roter Rahmen im Bild unten). Die Mindestzeitspanne für die Unveränderlichkeit beträgt 7 Tage.
Sobald das erste Linux-XFS-Repository eingerichtet ist, kann man einen Testlauf durchführen.
Die eventuell erscheinende Fehlermeldung bzgl. Schreibrechten
lässt sich beheben, indem der Backup-Benutzer entsprechende Schreibrechte auf den Ordner erhält: z.B.
sudo chown -R veeam:veeam /backup
Nach durchgeführten Backups sehen die Backupfiles wie folgt aus:
cd /backup lsattr
Hier wurde das [i]-Attribut gesetzt, was anzeigt, dass die Dateien geschützt (unveränderlich) sind.
Auch ein Löschen via Veeam GUI ist nicht möglich:
Der Schutz gilt für die gesamte Sicherungskette. Das bedeutet, dass das jüngste inkrementelle Backup den Schutz aller Backup-Dateien in der Sicherungskette definiert, auch wenn das älteste (vollständige) Backup älter ist als der Schutzzeitraum. Man kann die Vollsicherung nicht entfernen, während es unveränderliche inkrementelle Sicherungen gibt, die sich auf sie beziehen. Daher ist es notwendig, periodisch aktive Voll-Backups in der Sicherungskette zu haben.
Manipulation des Attributes auf der CLI
Wir haben gezeigt, dass Backups gegen das Löschen von der Backup-GUI geschützt sind. Was ist aber mit einem nicht privilegierten Benutzer (veeam) auf der Shell? Der Befehl zum Entfernen des unveränderlichen Attributs lautet:
chattr -i <file>
Wir probieren dies mit der neuesten Vollsicherungsdatei Testjob2D2021-01-22T154716_B467.vbk aus.
veeam@repo01:/backup/Testjob2$ lsattr
----i--------------- ./Testjob2D2021-01-22T150152_EC83.vbk
----i--------------- ./Testjob2D2021-01-22T150855_3C8F.vib
----i--------------- ./Testjob2D2021-01-22T154716_B467.vbk
-------------------- ./Testjob2.vbm
veeam@repo01:/backup/Testjob2$ chattr -i ./Testjob2D2021-01-22T154716_B467.vbk
chattr: Operation not permitted while setting flags on ./Testjob2D2021-01-22T154716_B467.vbk
veeam@repo01:/backup/Testjob2$
Der Benutzer veeam darf das Attribut [i] nicht ändern. Gut so!
Und was ist mit sudo?
sudo chattr -i ./Testjob2D2021-01-22T154716_B467.vbk
Durch das Ausführen von Befehlen mit sudo erheben wir die Benutzerrechte zu root-Rechten. Und natürlich müssen wir die Zugangsdaten für root eingeben. Im Grunde genommen verwandeln wir unseren nicht privilegierten Benutzer in einen root-Benutzer.
Jetzt ist das Attribut [i] der Datei Testjob2D2021-01-22T154716_B467.vbk wieder entfernt worden und die Dateien könnten gelöscht werden.
Ist das ein Problem? Nicht wirklich, denn der Benutzer root darf sich nicht über SSH anmelden. Der Benutzer root wird für keine Remote-Verbindung verwendet. Weder für Veeam Backup noch für irgendetwas anderes. Jeder, der root-Zugangsdaten hat, kann alles auf einem Linux-System tun – genau das ist die Aufgabe des Root-Benutzers.
Zusammenfassung
Die Verwendung von unveränderlichen Attributen für Backup-Dateien in Linux-Repositorys ist ein großer Schritt in Richtung Backup-Sicherheit. Wir sollten unsere Strategien überdenken und Repositories von Windows-Servern auf Linux-Repositories verlagern. Absolute Sicherheit gibt es zwar nicht, aber je mehr Hindernisse wir Angreifern in den Weg legen, desto weniger wahrscheinlich werden wir zu deren Opfern.