Fileserver und Verschlüsselungstrojaner

[Peter Weinrich 0]

Hallo,

wir haben einen Windows 2019 Fileserver und einen Owncloud-Server. Auf einem weiteren Windows 2019 Server sind die freigegebenen Ordner vom Windows Fileserver und über den Owncloud Client die Cloud-Freigaben eingebunden. Ein Script kopiert die Dateien auf mehrere Festplatten.

Nachdem jetzt eine Uni, eine Klinik und mehrere Firmen von Verschlüsselungs-Trojanern betroffen sind überlege ich wie man eine Datensicherung so einrichtet das ein Trojaner nicht das Backup verschlüsseln kann. Wie macht ihr das?

Vielen Dank für eure Hilfe!

[Nobbyaushb 1.359]

Offline auf Tape

[teletubbieland 139]

Moin.

Verschlüssetes Backup auf NAS mit eigenem Backup-User.

[BOfH_666 568]

vor 9 Stunden schrieb Peter Weinrich:

Wie macht ihr das?

 

Ganz allgemein gesprochen, musst Du einfach sicherstellen, dass kein Account der Schreibrechte auf die ursprünglichen Daten hat, auch Schreibrechte auf die Backup-Daten hat. Ein Verschlüsselungstrojaner verrichtet sein destruktives Werk ja üblicherweise mit den Rechten eines Benutzers, der auf die Nutz-Daten Schreibrechte besitzt.  

[mwiederkehr 351]

Ich würde noch weiter gehen und dafür sorgen, dass auch ein Angreifer mit Adminrechten in der Produktivumgebung die Sicherungen nicht zerstören kann. Virtualisierung ist da schon mal ein Vorteil, da auf Ebene Hypervisor gesichert werden kann und dieser nicht vom Produktivnetzwerk aus erreichbar sein muss. Für die Ablage der Sicherungen gibt es verschiedene Möglichkeiten: Tape, Veeam Cloud Connect mit Insider Protection, S3 mit Object Lock, neuerdings Hardened Repositories.

 

Wichtig sind regelmässige Wiederherstellungs-Tests. Einmal im Monat eine zufällig ausgewählte Datei zurückholen und prüfen, ob sie sich öffnen lässt. Zusätzlich gibt es Lösungen zur automatischen Prüfung, zum Beispiel "Backup Verification" von Synology oder "SureBackup" von Veeam. Die starten VMs aus der Sicherung und schicken ein Video vom Bootvorgang (Synology) bzw. prüfen laufende Dienste (Veeam).

[NorbertFe 1.805]

vor 2 Stunden schrieb teletubbieland:

Verschlüssetes Backup auf NAS mit eigenem Backup-User.

Clever, das is dann schon verschlüsselt. ;)

 

scnr

norbert

[NilsK 2.785]

Moin,

 

vor einer Stunde schrieb NorbertFe:

Clever, das is dann schon verschlüsselt. ;)

an dem Hinweis ist was dran, denn Verschlüsselung wird oft missverstanden und noch öfter falsch gemacht. 

 

In diesem Fall müsste die Verschlüsselung ja so definiert sein, dass der Angreifer die Daten nicht entschlüsseln kann. Reine Offline-Verschlüsselung (wie wir sie z.B. von Bitlocker oder vom Smartphone kennen) nützt hier nichts, denn wenn die Daten offline wären, käme der Trojaner ja sowieso nicht ran, und wenn sie online sind, besteht normaler Zugriff auf die entschlüsselten Daten.

 

Wenn der Schlüssel nur dem Backup-User zugänglich ist, dann könnte das zumindest vom Schutz der Daten her passen (je nachdem, wie man es dann im Detail macht), aber dann besteht eine hohe Abhängigkeit von diesem User und von dem Speicherort des Schlüssels.

 

Vor allem aber müsste man sich fragen, warum die Verschlüsselung der Backup-Daten verhindern sollte, dass diese Backup-Daten zerstört werden (ob nun gelöscht oder noch mal verschlüsselt, ist ja egal). Und das scheint mir hier der eigentliche Knackpunkt zu sein.

 

Verschlüsselung ist in aller Regel ein nicht-triviales Thema, auch wenn sich das Schlagwort leicht in die Runde werfen lässt.

 

Gruß, Nils

 

bearbeitet 23. Dezember 2022 von NilsK

[Gulp 226]

Eben, man sollte auch das Drumherum nicht vergessen und daran denken, dass Malware auch "nur" den Timeserver/die Timesettings des Backup Hosts ändern braucht, um die eingestellte Routine zum Aufräumen alter Sicxherungen den "Job" fürs löschen der Backups machen zu lassen ......

 

Grüsse

 

Gulp

[teletubbieland 139]

vor 11 Minuten schrieb Gulp:

Eben, man sollte auch das Drumherum nicht vergessen und daran denken, dass Malware auch "nur" den Timeserver/die Timesettings des Backup Hosts ändern braucht, um die eingestellte Routine zum Aufräumen alter Sicxherungen den "Job" fürs löschen der Backups machen zu lassen ......

 

Grüsse

 

Gulp

Dafür gibt es natürlich die 2te Backup-Destination, zyklisch getauscht wird (Ext. HDD oder Tape...)

[Squire 211]

3-2-1 Regel - Siehe: https://www.veeam.com/blog/321-backup-rule.html

 

ich zieh die Daten per Veeam in ein Repository (Backup Server ist nicht in der Domäne), dann gibt es eine weitere Kopie in einer Quantum Dedup Appliance (kann nicht über NFS oder SMB angesprochen werden, sondern über ein eigenes Protokoll. Ähnlich DellEMC Datadomain -> DBBoost oder HPE StoreOnce -> Catalyst) und dann wird noch auf LTO rausgeschrieben.

 

von der Quantum gibt es eine Community Version mit 5 TB RAW Kapazität. Dedup Raten bis zu 20:1 ... aktuell lieg ich hier bei 7,4:1 - je mehr Sicherungen da reinlaufen, desto höher das Dedup Verhältnis. Ich hab jetzt 28 Restore Points da drinnen mit GFS Settings aktiv. Für eine kleine Firma durchaus ausreichend ...

[daabm 1.185]

vor 4 Stunden schrieb Squire:

ich zieh die Daten per Veeam in ein Repository

 

In dem Ausschnitt steckt wohl der entscheidende Punkt für trojanerfeste Backups: Das Backup wird gezogen, nicht geschoben. Oder anders formuliert: Nicht der Client "schreibt" sein Backup auf den Backupserver, sondern der Backupserver "liest" es vom Client.

 

Die Alternative, die wohl die meisten Backupsysteme bieten dürften, ist: Der Backup-Client kann nur Backups erstellen, er kann aber bestehende Backups weder lesen noch schreiben.

 

Beides funktioniert explizit NICHT, wenn man einfach auf eine SMB-Freigabe schreibt   Die Bastellösung (sorry...) mit Skripts, die irgendwelche Daten mehrfach auf irgendwelche Freigaben schreiben, wird niemals trojanerfest sein.

[NorbertFe 1.805]

vor 32 Minuten schrieb daabm:

Das Backup wird gezogen, nicht geschoben.

Welches Backup (Software) schiebt denn? Kenn ich eigentlich nur tsm (Tivoli) bei denen das so war, und da konnte der Backup Admin immer noch bestimmen.

[Squire 211]

naja, eigentlich jede Agent basierte Software. Der Backup Server triggert zwar den Agent, aber der schiebt dann.

Networker hat das, neben TSM/SpectrumProtect auch so gemacht.

[NorbertFe 1.805]

vor 23 Minuten schrieb Squire:

Der Backup Server triggert zwar den Agent, aber der schiebt dann.

 Bist du da sicher? Und falls das stimmt, welche Backup software macht das denn anders?

[Squire 211]

Zum Beispiel die Sicherungen mit Veeam Agents (Windows/Linux/Applications) - die werden vom Backup Server angetriggert und schreiben dann alleine in ein Repository. Ich hab z.B. an einem Remote Standort einen Hyper-V mit einem Repository auf einer QNAP ... der Hyper-V Agent schreibt dort direkt in den Share. (Sieht man schon anhand der Schreibrate, da geht nix über den VPN Tunnel zum Backup Server - nur die Session Statistics und Sesson Metadaten)

 

Oder eben Spectrum Protect oder Networker ... die Agents bei letzerem schreiben da über DBBoost z.B. direkt in die Datadomain rein.

 

Die klassischen Snapshot Sicherungen (auch bei Storage Snapshots) bei Veeam sind da anders - da zieht der Backup Server die Daten vom Snapshot   

bearbeitet 24. Dezember 2022 von Squire