Immutable Backup

[goldene-zeiten]

Liebe KeyHelp-Freunde,

wie setzt ihr denn mit KeyHelp die Immutable Backups um?

Liebe Grüße von

Hahni

[Tobi]

Was verstehst du unter "Immutable Backups"?

Seit Bestehen des Forums gab es dieses Stichwort noch nicht.
Zumindest liefert die Suche keine Ergebnisse.

Ah und meinst du das alte Backup oder verwendest du schon restic?

[Florian]

Er meint damit das Backup-Dateien nach dem Erstellen gegen Veränderungen geschützt werden. Das kann man sich Bauen auf einem Storage z.B mit chattr

Dass das mit Restic klappt, sehe ich aber nicht, weil das ja nicht funktioniert wenn Dateien nicht geändert werden können, hier muss man eher mit klassischen Backupdaten/ Archiven arbeiten

[goldene-zeiten]

Lieber Tobi,

doch, restic nutze ich und bin sehr zufrieden damit. Einmal habe ich auch den Worst-Case getestet. Aber ich bin auf das Thema eben gekommen, weil bei uns hier eine Medienagentur einen Ransom-Angriff hatte und ich alle Sicherheitskonzepte noch mal zusätzlich auf den Prüfstand stelle:

--
Ein Immutable Backup (unveränderliches Backup) ist eine Sicherungskopie von Daten, die nach ihrer Erstellung für eine festgelegte Zeitspanne nicht mehr geändert, überschrieben oder gelöscht werden kann, selbst durch Administratoren oder Angreifer, was es zu einem entscheidenden Schutz gegen Ransomware, Malware und menschliches Versagen macht und die Einhaltung von Compliance-Vorschriften unterstützt. Diese Daten werden oft mit einer "Objektsperre" versehen, ähnlich dem WORM-Prinzip (Write Once, Read Many), um ihre Integrität zu garantieren.
--

Liebe Grüße

Hahni

[Tobi]

Dann würde ich einfach jeden Monat ein neues Repository anlegen. Oder einmal wöchentlich.

Zusätzlich könnte man es so einrichten, dass das Repository nur für die Dauer des Backups online ist.

[goldene-zeiten]

Das ist ja genau die spannende Frage. Die Repositorys von restic sind ja zunächst mal verschlüsselt. Das ist schon mal gut. Aber sie könnten erneut verschlüsselt werden bei einem Ransomware-Angriff. Dann wären sie wertlos.

Aber die Zugangsdaten zum Server (insbesondere das Passwort) wird ja verschlüsselt gespeichert. Wenn also ein Ransomware-Angriff wäre und alles verschüsselt wäre, dann könnte man doch das Backup zurückspielen. Schlimmstenfalls könnte der Angreifer über KeyHelp ein wertloses Backup aufspielen. Doch da es ja mehrere Snapshots gibt, könnte man einen älteren Stand wiederherstellen.

Die Frage ist aber, ob der Angreifer Zugriff auf den Remote-Speicher vom restic bekommen kann oder nicht. Aber das ginge doch nur mit dem passenden Passwort, welches ja eben verschlüsselt ist? Oder habe ich da schon einen Denkfehler?

[Tobi]

Also wenn du es wirklich sicher willst, dann solltest du einen isolierten In-House-Server in Betracht ziehen.

Mit rsync kannst du dann ein Backup deines KeyHelp-Servers machen und anschließend mit rsnapshot auf dem Backup-Server versionisieren.

Wenn du das Backup als Pull Backup machst und zusätzlich das dafür notwendige ssh Login per private/public key absicherst gibt es kein Passwort welches nach aussen geleakt werden könnte.

Ebenso sollte der In-House-Server nicht über das Internet erreichbar sein. Also keine Portfreigabe in der Fritz!Box einrichten. Das braucht es auch nicht, weil der In-House-Server wie jeder andere Client deines Netzwerkes auf das Internet zugreift. Das verkleinert den Angriffsvektor enorm da gar kein Login von aussen möglich ist.

Zusätzlich bindest du das Backup-Laufwerk deines In-House-Servers als Read-Only mit Samba auf deiner Arbeitsstation ein. Sollte nun die Arbeitsstation angegriffen werden kann diese die Dateien im Backup nicht verändern. Du hast aber immer direkten Zugriff auf alle Dateien deines Backups.

Schöner Nebeneffekt, alle Dateien liegen als Original-Datei vor. Nicht so ein Datenhaufen wie bei restic. Auch keine Verschlüsselung oder Komprimierung. Im Fall der Fälle kannst du die Dateien direkt per (S-)FTP von deinem Samba-Read-Only-Laufwerk auf den KeyHelp Server zurückspielen. Ich denke das dürfte dir gefallen .

[goldene-zeiten]

Ja, die Sache mit den "Rohdaten" gefällt mir grundsätzlich. Vielen lieben Dank für deine ausführlichen Erklärungen. Ich werde parallel dazu auch noch mal FTP und Datenbanken so sichern, dass die separat von restic sind. Man weiß ja nie, ob man kompromittiert ist. Im Fall eines Hosters hier in Regensburg, der nun seit 1 Woche keine Datenbestände hat, muss das ja auch von langer Hand geplant worden sein, bevor alles verschlüsselt wurde. Aber ist denn auf einem Server, der gehackt wurde, ein Zugriff auf ein restric-Backup überhaupt möglich? Nur, weil die Verbindungsdaten dort im KeyHelp hinterlegt sind?

[Tobi]

Aber ist denn auf einem Server, der gehackt wurde, ein Zugriff auf ein restric-Backup überhaupt möglich?

Auf einem gehackten Server ist grundsätzlich alles möglich. Das kommt ganz auf den Angreifer an.

Nur, weil die Verbindungsdaten dort im KeyHelp hinterlegt sind?

Was bedeutet in diesem Fall für dich "nur"?
Die Zugangsdaten deines externen Speichers als auch dein restic-Passwort werden von KeyHelp verschlüsselt und sicher verwahrt. Allerdings liegt es in der Natur der Sache, dass beide Passwörter (Remote und restic) zur Laufzeit des Backups unverschlüsselt vorliegen müssen. Andernfalls könnte KeyHelp das Backup nicht verschlüsseln und hochladen.

Und JA, werden diese beiden Passwörter abgegriffen dann sind dein externer Speicher und auch restic Backup kompromittiert.

[technotravel]

Also wenn ich mir Sorgen machen würde, dass auf meinen remote storage der KH repositories durch einen Hacker missbräuchlich zugegriffen werden könnte würde ich:

- einen zusätzlichen remote storage einrichten
- von diesem über ein mit ssh-keys eingerichtetes rsync die gesamten Repositories rüberziehen (vermutlich dann per cronjob)

So sollten sie vor Hackern und maliziöser Verschlüsselung sicher sein.