Dieser Artikel handelt von einem großartigen neuen Feature in VBR v11: Hardened Repository - Unveränderbares Repository. Hier zu lesen:
- Was bedeutet unveränderlich (immutable)?
- Anforderungen
- Setup
- So funktioniert es
Was bedeutet unveränderlich (immutable)?
Unveränderlich bedeutet hier, dass Backup Dateien weder verändert, noch gelöscht werden können. Das ist nur machbar mit Root-Rechten im Linux OS. So kann selbst ein Administrator, am Backup Server, im Repository Dateien weder verändern noch löschen.
Warum ist das wichtig? Zum Beispiel wegen Ransomware. Ransomware ist heutzutage derart intelligent, dass es Backup Dateien ausfindig machen kann und diese verschlüsselt oder löscht. Genau das wird mit unveränderbaren Backup Dateien massiv erschwert.
Anforderungen
Was braucht man für ein Immutable Repository? Zuerst: Veeam Backup&Replication v11. Das ist die erste Version, die Hardened Repository unterstützt. Zweitens, einen Linux Server, der das Backup Repository hält. In v11 kann der Linux Server nur die Repository Rolle übernehmen, wenn Immutable. Das bedeutet, dass ein separater Server für die Proxy Rolle notwendig ist wenn Hardened Repository genutzt wird.
Welches Filesystem soll benutzt werden? Veeam nutzt das Immutable Flag in Linux, um unveränderliche Dateien bereitzustellen. Es kann also jedes Dateisystem benutzt werden, dass Immutable Flags unterstützt. Das sind so ziemlich alle. Veeam unterstützt in Linux Repositories auch reflink/Fast Clone mit XFS. Darum gilt XFS als das empfohlene Filesystem.
Welche Linux Distribution? Aktuell gibt es dazu noch keine Empfehlungen. Ich denke aber, dass das Feature die Auswahl an Distributionen nicht einschränken wird. Mit der Nutzung von XFS gibt es somit eine erste Wahl: Ubuntu 20.04 LTS (long-term support). Nämlich weil: (1) Ubuntu ist von Veeam voll unterstützt. (2) 20.04 kommt mit Kernel Version 5.4. Die scheint die beste Qualität für reflink zu bieten und ist von Veeam getestet.
Drittens: Backup Kette muss mit Immutable Dateien kompatibel sein. Was bedeutet das? Weil bestehende Dateien nicht verändert werden können, darf die Kette nur neue Dateien erstellen. Somit sind nur vorwärts Inkremental mit periodischen synthetischen oder aktiven Vollsicherungen erlaubt. Für Backup Copy Jobs, müssen GFS Restore Points definiert werden.
Setup
Hardened Repository wird auf Repository-Ebene aktiviert. Entweder bei der Erstellung des Repositorys oder bei bestehenden.
Die Einstellungen sind soweit selbsterklärend:
So funktioniert es
Das schöne an dem Feature ist, dass es ein natives Filesystem Feature nutzt. In Linux kann für jede Datei das Attribute i gesetzt werden. Wenn gesetzt, kann die Datei weder verändert noch gelöscht werden. Nachdem Veeam eine Backup Datei erzeugt hat, setzt es das Flag. Nach der gesetzten Zeitdauer wird das Flag entfernt und die Datei kann gelöscht werden.
Um das Immutable Flag zu einer Datei zu sehen, kann der Befehl lsattr filename in der Linux Shell ausgeführt werden. Hier ein Beispiel:
Beachte, dass Flags nur von ganzen Backup Ketten entfernt werden, nicht von einzelnen Dateien.
Die Frage könnte nun gestellt werden, wie das Flag von Veeam gesetzt wird. Denn wenn nur ein User mit Root-Rechten das Flag setzen kann, könnte das von einem Hacker benutzt werden um Zugriff zu erhalten. An sich stimmt das, nur das Flag wird nicht durch den Transport-Service User gesetzt, es wird tatsächlich durch Root gesetzt. Das wird durch einen eigenen Service bewerkstelligt, der die Flags setzt/entfernt: veeamimmureposvc.
Beachte: Dieser Service bietet keinerlei Netzwerkverbindungen, und kann somit nicht remote kompromittiert werden!
Apropos Netzwerk: Welche Ports werden benutzt? Ebenfalls neu in v11 ist, dass für die Kommunikation mit dem Repository nur noch ein Port benutzt wird: TCP/6162. Während eines Backups können zusätzliche Ports nach Bedarf geöffnet werden.
Der gesamte, detailliertere Artikel - in Englisch - kann hier gelesen werden:
https://vnote42.net/2020/11/23/new-in-veeam-v11-hardened-repository-immutable-backups-part-1/
