Strategie Backup & Totalausfall primäres NAS mit redundantem sekundärem NAS

[himitsu]

Bezüglich Ransomware im NAS:
* Sicherung auf zweites NAS
* erstes NAS hat nur Zugriff auf die Shares (kein Admin)
* im zweiten NAS dann mit SnapShots o.Ä. die Daten intern "sichern/kopieren"

Wird das erste NAS befallen, dann hätte es zwar Zugriff auf die aktuellen Daten im Zweiten, aber die Snapshots/Backups innerhalb des Zweiten sind erstmal noch sicher, da ja kein Zugriff besteht.

Auf selbe Weise würde man auch das erste NAS gegen sowas auf den angeschlossenen Geräten (PCs) schützen können.


Im Prinzip ist es relativ einfach.
* auch wenn auf aktuelle Daten ja Zugriff bestehen muß
* kann man die Sicherungen/Backups vor den automatischen Stadard-Zugriffen schützen -> der/die Admin-Account(s) darf natürlich nirgendwo mit Autologin rumliegen oder lesbar gespeicherten Zugangsdaten (am Besten noch 2FA usw.)

 

[sugarDaddy]

@kais2021
Für das Backup von MSSQL habe ich bereits eine Lösung. MSSQL bietet die Möglichkeit .diffs zu backupen. Also nur die Veränderung seit dem letzten Komplett-Backup. Ich denke ich werde zum Tageswechsel ein komplettes Backup machen, und dann zu jeder Stunde ein .diff anlegen. Ggf. kleineres Intervall. Das spart sowohl lokal als auch remote Platz, und erlaubt es mir jeden beliebigen Zustand gemäß der Intervalle wiederherzustellen.
Und danke für den Hinweis mit ShareSync.


Zu den mir jetzt bekannten 3 Arten Daten zu synchronisieren:

• HyperBackup
  Vorteile: simpel; eine Retention zur Vorhaltung früherer Backups is möglich
  Nachteile: braucht man die Daten auf dem sekundär-NAS muss man sie aufwendig dekomprimieren; und Du hast wirklich nur die Zustände von Backup zu Backup
  
  
• SnapshotReplication
  Vorteile: simpel; komplexe Retention möglich; bewahrt die Dateihistorie des Original-Dateisystems; dürfte sparsam mit Daten bei Synchronisation umgehen, da nur die Deltas transferiert werden (Vorteil gegenüber HyperBackup?)
  Nachteile: mir war es in meinem Test-Setup nicht möglich im replizierten shared-folder auf dem sekundären NAS "zu arbeiten", ich denke fast ich müsste die Inhalte in neue shared-folders kopieren, um damit arbeiten zu können. Ich müsste die Daten zumindest nicht dekomprimieren, im Gegensatz zu HyperBackup. Allerdings müsste ich auf dem sekundären NAS ausreichend Platz vorhalten, um die Daten duplizieren zu können. Liege ich hier richtig?
  
  
• ShareSync
  Das habe ich noch nicht ausprobiert. Aber es klingt als hätte es den "Nachteil" von SnapshotReplication nicht, und die synchronisierten shares auf beiden System wären auf beiden System auch direkt bearbeitbar.

@himitsu
Bei klassischer Ransomware gehe ich davon aus, dass einer der mit dem Netzlaufwerk (shared-folders im primär-NAS) verbundenen PCs befallen wird. Die Ransomware verschlüsselt dann jede Festplatte an die sie mit den gegebenen credentials rankommt.

Lasse ich sämtliche shared-folders als Snapshot laufen und mache in kurzen Intervallen snapshots, so kann zwar alles verschlüsselt werden, aber das erzeugt dann nur einen nutzlosen snapshot. Ich kann jederzeit zum vorigen zurückspringen, da die Ransomware nicht auf Dateisystemebene frühere snapshots löschen oder verändern kann. Ich synchronisiere die shared-folders zwar auch aufs zweite NAS, aber schon das erste sollte sicher sein. Auf die shared-folders für Docker, DB und DB-Backups gibt es ja keinen zugriff per SMB usw.

Gegen nicht automatisierte Angriffe sieht die Sache anders aus. Da gilt natürlich updates zu fahren, Accounts sauber zu trennen und die Zugänge sicherstmöglich zu handhaben.

Wenn allerdings jemand seit 3 Monaten in Deinem System ist und sich Vollzugriff auf alles erarbeitet hat sieht es schlecht aus. Dann musst Du hoffen mit einem USB-Backup was seit 3 Monaten nicht mehr am Netz war wieder neu aufzubauen.

 

[Synchrotron]

Nach dem Erstbefall wird standardmäßig weitere Schadsoftware vom c&c-Server nachgeladen. Darunter sind Keylogger und Screengrabber. Wenn man sich mit deinem Netzwerk die Mühe macht es zu knacken, dann liefern diese Tools oft die nötigen Daten.

Das ist in Heimnetzwerken weniger wahrscheinlich (soll auch schon passiert sein), aber ein mittelständischer Betrieb dürfte bereits als lohnendes Ziel gelten. Ein paar Tausender Erpressungssumme liegen da schnell auf dem Tisch.

Der beste Schutz ist daher, wenn der Backup-Rechner sich selbst auf der Backupquelle einwählt und das Backup von dort zieht. Dann müssen im Hauptnetz nirgendwo Zugangsdaten zum Backuprechner liegen. Trotzdem mit 2FA absichern, wegen Keyloggern.

 

[sugarDaddy]

@Synchrotron "Der beste Schutz ist daher, wenn der Backup-Rechner sich selbst auf der Backupquelle einwählt ..." good point! Danke.

Ich habe sämtliche PCs im Netzwerk quasi schon "abgeschrieben". Das sind alles DAUs und früher oder später fangen die sich was ein. Aber jeder von denen kriegt nur einmal die Zugänge (non-Admin) um per SMB auf Ihre 2-3 shared-folders zuzugreifen. Was auf den PCs verlustig geht ist mir egal. Verschlüsselte Dateien auf den genannten shared-folder hole ich mir aus nem Snapshot zurück.

Ich und ein weiterer Admin habe ihre eigenen Admin-Accounts auf den Synologys und nutzen kein SMB. Sind wenn, dann auf der DSM-GUI unterwegs, und dass von eigenen Rechnern aus, meist ausserhalb des Unternehmens per VPN.

Wenn, müssten Sicherheitslücken genutzt werden, oder die Rechner der Admins.

 

[Synchrotron]

Typischer Infektionsweg: Ein Windowsrechner wird infiziert (Mailanhang, Link, erste Schadsoftware wird geladen). Einige Zeit später stellt ein Drucker den Betrieb ein (Windows, Druckerproblem - da denkt sich keiner was).

Ein Admin schaut vorbei: Treiber zerschossen. Anmeldung als lokaler Admin, der Rechner wird repariert. Geht wieder - und der Keylogger schickt alles an den c&c server.

Jetzt entscheidet es sich: Der gleiche Login wird auch als Netzadmin verwendet ? Bingo, man kommt weiter. Nein ? Abwarten, es gibt weitere Chancen, oder irgendwo eine nicht gepatchte Komponente oder oder …

Die schwarzen Hoodies müssen ja nicht jedes infizierte Netzwerk knacken - vermutlich reichen denen ein paar Prozent der Erstinfektionen.

 

[sugarDaddy]

Hey @Synchrotron wo Du schreibst "Der beste Schutz ist daher, wenn der Backup-Rechner sich selbst auf der Backupquelle einwählt und das Backup von dort zieht".

Ich habe eben versucht auf meinem "remote" NAS ein "SnapshotReplication Task" anzulegen, welches sich im primären NAS an einem shared-folder bedienen soll um dieses zu sich selbst rüber zu replizieren.

Aber es gibt beim Erzeugen eines Replication Task nur "Local" und "Remote". Wobei "Local" nur lokal agiert. Und "Remote" nach einem "Destination Server" fragt. Der sollte ja aber doch er selber sein. Der "Source Server" lässt sich auswählen, aber "localhost" als "Destination Server" will er nicht annehmen. Auch in den "Advanced Settings ließ sich meine Kombination nicht einrichten.

Weißt Du ob SnapshotReplication das doch kann, und der Fehler bei mir liegt? Oder wie hattest Du das gemeint?

 

[Synchrotron]

Mein Hinweis bezog sich konkret auf ActiveBackup for Business unter DSM 6. Bin noch nicht migriert und habe aktuell auch keine Eile mit DSM 7. Wichtig ist dabei dass beide DSen unter BTRFS aufgesetzt wurden - das heißt auch die Backupmaschine muss einen Intelprozessor haben.

Leider scheitert diese Strategie daher bei mir persönlich (siehe Signatur). Ich helfe mir damit, dass die BackupDS wirklich nur zum Backup eingeschaltet wird.

 

[sugarDaddy]

Ah ok. ABB ist natürlich eine andere Sache. Logisch, dass die DS da beim jeweiligen PC vorbeischaut und sagt "gib mal her die Daten".

Bei mir sinds zwar DSM 7 und BTRFS, allerdings gehts mir drum ein NAS#2 sich zwecks Replication bei NAS#1 bedienen zu lassen, analog zu deiner Bemerkung.

Ich wende mich damit nochmal ans Forum. Dir vielen Dank für die Antwort.