lutzerhase
Goto Top

DFS Sicherheit

Ich plane gerade eine neue Serverlandschaft für einen relativ kleinen Nutzerkreis, dieser erschließt sich aber doch über 4 Standort.
Jetzt war mein Gedanke Die Domäne über Standorte auszurollen und DFS einzusetzen.
Einfach das für mich im "Notfall" alle Daten an einem Standort sind. Und natürlich einen Austausch herstellen zu können usw....

Jetzt stelle ich aber auf Grund von Verschlüsselungstrojanern oder anderer Schadsoftware usw. dieses Konstrukt in Frage. Weil dann habe ich es ja automatisch überall.
Wie setzt Ihr das ein und ist mein Bedenken gerechtfertigt?

Content-ID: 621885

Url: https://administrator.de/forum/dfs-sicherheit-621885.html

Ausgedruckt am: 22.12.2024 um 11:12 Uhr

Th0mKa
Th0mKa 13.11.2020 um 13:39:22 Uhr
Goto Top
Moin,

Mal Trojaner und Co beiseite gelassen, was machst du denn wenn ein Nutzer eine Datei löscht?

/Thomas
LutzerHase
LutzerHase 13.11.2020 um 14:26:17 Uhr
Goto Top
Das wäre nicht schlimm, denn das kann der ja jetzt auch...
Jeder Standort würde natürlich trotzdem weiter nur die Daten seines Standortes "sehen".
Also für die User ändert sich nichts.
support-m
support-m 13.11.2020 um 14:46:07 Uhr
Goto Top
Ich weiß jetzt nich, wie groß da gedacht wird oder so.
Aber für mich klingt das nach einem guten Grund für einen Terminalserver im Zusammenspiel mit einem reinem Fileserver (oder ein Samba-Share auf einem Linuxunterbau. Hier könntest du dir vielleicht TrueNAS anschauen und deren Snapshot-Funktion - hab ich aber selber noch nicht getestet).
Wichtig ist eine ordentliche Backupstrategie. Die Gefahr von Verschlüsselungstrojanern besteht leider immer, daher ist das Backup so wichtig. Wenn du nun 4 Einfallmöglichkeiten bietest mit den 4 Standorten hast du meiner Meinung nach damit nichts erreicht. Bei einem TS-Server begrenzt du die Einfallmöglichkeit wenigstens auf 1 Server (den man relativ leicht wiederherstellen kann).

MfG
Th0mKa
Th0mKa 13.11.2020 um 14:47:42 Uhr
Goto Top
Zitat von @LutzerHase:

Das wäre nicht schlimm, denn das kann der ja jetzt auch...
Jeder Standort würde natürlich trotzdem weiter nur die Daten seines Standortes "sehen".
Also für die User ändert sich nichts.

Naja, wenn ein Trojaner die Daten verschlüsselst stellst du sie halt aus dem Backup wieder her, so wie jetzt auch wenn ein Nutzer etwas löscht.

/Thomas
LutzerHase
LutzerHase 13.11.2020 um 19:25:58 Uhr
Goto Top
Ja, gute Schadware wartet halt eine Runde ab bis die Backups alle duch sind...
maretz
maretz 13.11.2020 um 19:50:24 Uhr
Goto Top
Ja - aber wo ist der unterschied zu "jetzt"? Deshalb hat man ja nich nur ein Backup sondern eben mehrere Generationen... Die Replikation ist ja auch gar nich als Backup zu sehen sondern eben als replikation. Denn wenn ein Benutzer ne Datei löscht is die auch weg und du nimmst das Backup - der Krypto-Trojaner löscht halt alle Dateien... Was würdest du denn machen wenn ein Benutzer eine Datei vor ner Woche (oder vor 4) versehentlich überschrieben hat, das aber erst heute merkt? Dann wäre die Rotation ja ggf. auch schon durch...
Chaos0815
Lösung Chaos0815 15.11.2020 um 17:03:42 Uhr
Goto Top
Meiner Erfahrung nach ist die Replikation per DFS-R generell kein so richtig gelungenes Produkt und braucht auch immer ein wenig Pflege.

Man könnte es nun noch so einstellen, dass die Daten nur nach einem abweichenden Zeitplan synchronisiert werden. Dann hättest du das Problem erst zeitversetzt und könntest ggf. noch reagieren.

Auch über VSS-Snapshots und die "Vorgängerversionen" lassen sich ggf. verschlüsselte Dateien wiederherstellen - abhängig davon wie "gut" der Trojaner ist bis wo er Zugriff bekommt.

Ein gut gemachtes Backup-Konzept ist aber in jedem Fall wichtig - egal ob DFS oder nicht DFS!
LutzerHase
LutzerHase 18.11.2020 um 16:08:58 Uhr
Goto Top
Backup ist ganz klar ein ganz anderes Thema und für mich unabhängig davon.

So richtig bin ich auch nicht mehr überzeugt von dfs. Denn außer das ich als admin alle Daten überall hätte, habe ich auch keinen weiteren Nutzen.
Für die User gibt es ja andere Möglichkeiten für gemeinsame Dateien. Da ist dfs eh zu langsam...