Angriffe auf IT-Infrastrukturen sind in letzter Zeit immer raffinierter geworden. Sie verschlüsseln nicht nur Live-Daten und ganze virtuelle Maschinen, sie haben auch gelernt, ganze Backups zu löschen, oder zu verschlüsseln. Dabei spielt es keine Rolle, ob Ihre Online-Backups in einem lokalen Repository, oder auf einem Cloud-Share gespeichert sind. Wenn dieser Fall eintritt und Sie kein Offline Backup wie beispielsweise Tape, oder einen sonstigen Plan B in der Hinterhand haben, werden Sie alt aussehen. Schlimmer noch: Wenn Sie in Ihrem Unternehmen für die Datensicherung verantwortlich sind, müssen Sie sich unangenehmen Fragen seitens der Geschäftsführung stellen.
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? Gute Nachrichten. Es gibt Licht am Ende des Tunnels (und ich verspreche, es ist nicht der entgegenkommende Zug).
Unveränderliche (Immutable) Backups
Bevor wir ins Detail gehen, müssen wir klären, was unveränderliche Backups bedeuten. Die Idee ist, dass man einmal schreibt und dann die Dateien (Backups) für eine selbst definierte Zeitspanne geschützt sind. Selbst der Backup-Administrator kann sie nicht löschen, bevor die definierte Zeitspanne verstrichen ist.
Veeam Backup & Replication v11 wird eine native Funktion des Linux XFS-Dateisystems nutzen. 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.
Alles, was Sie benötigen, ist ein mit XFS formatiertes Linux-Repository und Veeam Backup & Replication v11, das demnächst erscheinen wird. (Update: Geplantes Erscheinungsdatum ist der 24.02.2021)
Testbedingungen
- vSAN 7 Update1
- Veeam Backup 11.0.0.591 BETA 2
- Proxy Server: Ubuntu 20.04 LTS
- Repository Server: Ubuntu 20.04 LTS
Alle in diesem Artikel gezeigten Beispiele stammen aus einer POC-Laborumgebung mit Fokus auf dem Attribut “immutable”. Andere Einstellungen, die Sie sehen, sind möglicherweise nicht empfehlenswert für Produktivumgebungen.
Repository einrichten
Grundsätzlich ist ein neues 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. Sie werden möglicherweise auf ein Problem mit den Schreibrechten stoßen, wenn Sie einen bestehenden Linux-Repository-Server wiederverwenden. Aber keine Sorge, das ist leicht zu beheben.
In meinem Fall war der /backup-Pfad mit einem anderen Konto erstellt worden und mein Backup-Benutzer “veeam” hatte keine Schreibrechte für den Ordner. Alles, was Sie tun müssen, ist die Besitzrechte auf den Backup-Benutzer zu übertragen.
sudo chown -R veeam:veeam /backup
Der Parameter [-R] setzt die Besitzrechte rekursiv auf alle Unterordner. Dazu gibt man Benutzer und Gruppe in der Form Benutzer:Gruppe an. In meinem Fall gehört der Benutzer “veeam” zur Gruppe “veeam” und der Pfad zur Übernahme der Besitzrechte ist /backup. Jetzt kann der Backup-Benutzer veeam in das Repository schreiben.
Überprüfung der Ergebnisse
Ich habe einen kleinen Testauftrag “Testjob2” erstellt und ihn zweimal laufen lassen. Beim ersten Durchlauf hat er eine Vollsicherung (vbk) und beim zweiten Durchlauf eine inkrementelle Sicherung (vib) erstellt. Werfen wir einen Blick auf den Backup-Repository-Server. Wir wechseln in das Verzeichnis /backup und überprüfen die Dateiattribute.
cd /backup lsattr
Wir können sehen, dass unsere beiden Sicherungsdateien ein [i]-Attribut haben, was anzeigt, dass sie geschützt (unveränderlich) sind.
Aber es gibt noch mehr zu sehen. Schauen wir uns den Inhalt unseres /backup-Verzeichnisses an.
veeam@repo01:/backup/Testjob2$ ls -la
total 6861212
drwxr-xr-x 2 veeam veeam 133 Jan 22 15:09 .
drwxr-xr-x 4 veeam veeam 37 Jan 22 15:01 ..
-rw-r--r-- 1 root root 201 Jan 22 15:09 .veeam.1.lock
-rw-r--r-- 1 veeam veeam 23833 Jan 22 15:09 Testjob2.vbm
-rw-r--r-- 1 veeam veeam 6999216128 Jan 22 15:05 Testjob2D2021-01-22T150152_EC83.vbk
-rw-r--r-- 1 veeam veeam 26636288 Jan 22 15:09 Testjob2D2021-01-22T150855_3C8F.vib
Es gibt dort ein File mit Namen .veeam.1.lock. Schauen wir uns das einmal näher an:
Wie man hier sehen kann, enthält es alle Daten zur Aufbewahrung für jede unveränderliche Sicherungsdatei. Beachten Sie, dass der Zeitstempel sowohl für die Vollsicherung als auch für das Inkrement identisch ist, obwohl sie zu unterschiedlichen Zeiten erstellt wurden.
Versuch der Löschung
Versuchen wir jetzt einmal, die Backups aus der Veeam GUI zu löschen (Delete from disk).
Veeam Backup wird zunächst nach einer Bestätigung für den Vorgang fragen und dann versuchen die Daten zu löschen. Betrachtet man die Ausgabe des Logs, so erkennt man, dass der Löschversuch gescheitert ist.
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.
Kontrollieren wir das, indem wir eine aktive Vollsicherung hinzufügen.
veeam@repo01:/backup/Testjob2$ ls -la
total 13678532
drwxr-xr-x 2 veeam veeam 176 Jan 22 15:50 .
drwxr-xr-x 4 veeam veeam 37 Jan 22 15:01 ..
-rw-r--r-- 1 root root 291 Jan 22 15:50 .veeam.2.lock
-rw-r--r-- 1 veeam veeam 34466 Jan 22 15:50 Testjob2.vbm
-rw-r--r-- 1 veeam veeam 6999216128 Jan 22 15:05 Testjob2D2021-01-22T150152_EC83.vbk
-rw-r--r-- 1 veeam veeam 26636288 Jan 22 15:09 Testjob2D2021-01-22T150855_3C8F.vib
-rw-r--r-- 1 veeam veeam 6980923392 Jan 22 15:49 Testjob2D2021-01-22T154716_B467.vbk
veeam@repo01:/backup/Testjob2$
Wie Sie feststellen können, hat sich der Name der Sperrdatei geändert. Wir können sehen, dass es zwei verschiedene Zeitstempel für den Schutz gibt (gelbe und grüne Kästen). Einen für die alte Sicherungskette und einen für die neue.
Merke: Eine Sicherungskette kann nicht gelöscht werden, bevor das jüngste Inkrement aus dem Schutzzeitraum herausgealtert ist.
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$
Schade, leider verloren. Das haben wir auch erwartet. 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.
veeam@repo01:/backup/Testjob2$ lsattr
----i--------------- ./Testjob2D2021-01-22T150152_EC83.vbk
----i--------------- ./Testjob2D2021-01-22T150855_3C8F.vib
-------------------- ./Testjob2D2021-01-22T154716_B467.vbk
-------------------- ./Testjob2.vbm
Jetzt ist das Attribut [i] der Datei Testjob2D2021-01-22T154716_B467.vbk wieder entfernt worden.
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.
Einschränkungen und Anforderungen
- Wenn Sie unveränderliche Backups auf Linux-Repositorys verwenden, können Sie die Proxy-Rolle nicht auf demselben Server haben.
- Die Unveränderlichkeit funktioniert nur bei “Forward Incremental” Sicherungen und Jobs mit periodischen Vollsicherungen ohne Rollbacks.
- Bei der Verwendung paralleler Repositories auf demselben Server müssen entweder alle Repositories unveränderlich oder alle veränderlich sein.
- Änderungen an der Sicherungskette werden nicht unterstützt.
- Alle Repositories eines SOBR müssen von der gleichen Art sein. Entweder veränderbar oder unveränderbar.
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.