ubuntuusers.de

Hallo zusammen!

Ihr habt doch sicher schon alle von Ransomware wie Locky gehört. Aktuell greifen die ja sehr schnell um sich und können gerade bei kleineren, mittelständischen Unternehmen wirklich großen Schaden anrichten. Davor möchte ich mich jetzt bestmöglich schützen. Gefährdet ist natürlich vorallem der Windows-Client. Ich habe im Netzwerk einen kleinen Linuxserver laufen, der den Clients Freigaben bereitsstellt. Die Clients legen auf diesen ihre Backups ab. Jetzt ist aber das Problem an Locky und Konsorten, dass die durchaus auch in der Lage sind, eingebundene Netzwerkfreigaben zu verschlüsseln. Da bringen mir meine Backups natürlich auch nichts mehr, wenn die einfach mit verschlüsselt sind. Jetzt war meine Überlegung, einen Share für diese Backups einzurichten und in der smb.conf mit den Einträgen "force user = backup", "force group = backup" und "create mode = 0600" zu bewirken, dass angelegte Backups vom Client aus weder gesehen, noch verändert werden können. Ähnlich dem "Briefkasten", den es auf OS X gibt. Wenn ich dann doch mal ein Backup brauche, kann ich die Rechte der entsprechenden Datei ja von Hand wieder ändern. Wir haben in den letzten Zehn Jahren vielleicht drei oder vier mal ein Backup gebraucht, der Arbeitsaufwand wäre also zu vertreten.

Könnte ich meine Backups so vor dieser Bedrohung schützen, oder gibt es noch andere, effektivere Methoden?

Lustig, mit etwas ähnlichem beschäftige ich mich auch gerade.

Die ideale Lösung wäre ja, nicht die Rechner die Backups zum Server pushen zu lassen, sondern den Server die Backups von den Rechnern ziehen zu lassen. So haben die (potentiell infizierten) Rechner nie Schreibzugriff auf die Backups. In der Theorie ganz toll, klappt aber nicht immer.

Eine andere, nicht ganz unwichtige Sache: Mehrere Backups an unterschiedlichen Orten haben. Hilft nicht nur gegen Angriffe durch Ransomware, sondern auch, wenn die Bude mal abfackelt.

Der Ansatz den ich derzeit verfolge ist, eine (beschreibbare) Freigabe auf dem Server zu haben, die nur neue Backups entgegen nimmt und eine zweite (nur lesbare) Freigabe, die einen Zugriff auf alte Backups ermöglicht. Wichtig dabei: Beide Freigaben zeigen auf unterschiedliche Verzeichnisse. Über die beschreibbare Freigabe kann nicht auf die existierenden backups zugegriffen werden. Der Server selbst geht dann des Nachts hin, integriert die über den Tag angefallenen Backups in den großen Pool und löscht sie von der beschreibbaren Freigabe. So kann eine Ransomware maximal die Backups eines Tages vernichten. Wobei sich der Zeitraum natürlich auch verkürzen lässt.

In meinem speziellen Fall missbrauche ich dabei eine Funktion des Backup-Tools StoreBackup, welches dafür gedacht ist Backups in einer isolierten Umgebung zu machen. Oder besser, ich plane es dafür zu missbrauchen. Die Umsetzung steht noch aus. Dadurch lassen sich neue Backups trotzdem mit alten verknüpfen, was enorm Speicherplatz spart.

Nur interessehalber: Wenn man das Backup via rsync macht und das Backup-Skript unter einem extra (entsprechend eingeschränkten) Benutzer laufen lässt, sollte man sicher sein? RSync würde doch quasi alle Dateien als "geändert" (da verschlüsselt) erkennen und alles "neu" backuppen, aber die alten ("guten") Dateien unangetastet lassen? Hätte den Nebeneffekt dass man eine Infektion sofort bemerken würde - wenn plötzlich das RSync nicht mehr 2 Minuten sondern 20 Stunden braucht 😉

Das rsync selbst würde die Daten als neu erkennen, ja. Ob es dann die alten unangetastet lässt oder überschreibt, hängt davon ab wie du rsync benutzt.

Das Problem ist hier aber noch ein anderes. Um die Backups machen zu können, muss rsync Schreibzugriff auf das Verzeichnis haben, in welches es sichern soll. Was hindert einen potentiellen Schädling jetzt daran, auf rsync zu pfeifen, und das Verzeichnis einfach direkt zu verschlüsseln, mit allen Daten und alten Backups die sich darauf befinden? So nette Ransomware wie Locky verschlüsseln ja inzwischen nicht mehr bloß die lokale Festplatte, sondern durchsuchen das komplette Netzwerk nach allem, was sich irgendwie beschreiben lässt und verschlüsseln dann fröhlich drauf los.

Is halt blöd, wenn der Schädling nicht nur die Original-Daten verschlüsselt, sondern auch alle Backups aus denen man sonst sicherheitshalber wiederherstellen könnte.

Lookbehind schrieb:

Was hindert einen potentiellen Schädling jetzt daran, auf rsync zu pfeifen, und das Verzeichnis einfach direkt zu verschlüsseln, mit allen Daten und alten Backups die sich darauf befinden?

Deshalb

[...] und das Backup-Skript unter einem extra (entsprechend eingeschränkten) Benutzer laufen lässt [...]

Zugriff aufs Backup (zu Restore-Zwecken) nur im Read-Only-Modus. Die Clients dürfen keine Schreibrechte haben sondern müssen umgekehrt dem Backupserver die nötigen Leserechte einräumen. Dadurch hält der Linux-Backup-Server die Fäden in der Hand...

Vielleicht geht BackupPC in die Richtung.

In freier Wildbahn siehe auch Uberspace https://wiki.uberspace.de/system:backup

Dort werden Backups von extern angelegt (unter .ssh/authorized ist ein entsprechender Eintrag) und man hat nur Read-Only Zugriff darauf und dabei auf den Zustand der letzten X Tage / X Wochen also inkrementelle Backups. Wenn man nach 3 Tagen merkt daß die Kiste gehackt worden und die Dateien verschlüsselt sind kann man das 4 Tage alte Backup wieder auslesen...

Um ein Backup vom Server holen zu lassen, müsste ich die Verzeichnisse auf dem Client aber freigeben. Das möchte ich eigentlich möglichst vermeiden.

Ich habe jetzt in meiner Samba-Conf etwas gespielt und folgende Einträge an einen Share hinzugefügt:

create mask = 0400
directory mask = 0700
security mask = 0400
directory security mask = 0700

So richtig klappt das aber auch noch nicht. Erstelle ich (immer vom Win-Client aus) eine Datei, kann ich sie nicht ändern. Wenn ich sie aber löschen möchte, bekomme ich die Fehlermeldung, dass sie sich nicht mehr an ihrem Speicherort befindet. Und sie ist dann auch tatsächlich gelöscht. Ordner kann ich öffnen, umbenennen und löschen. Auch, wenn sich darin bereits Dateien befinden.

derflo26 schrieb:

Um ein Backup vom Server holen zu lassen, müsste ich die Verzeichnisse auf dem Client aber freigeben. Das möchte ich eigentlich möglichst vermeiden.

In irgendeine Richtung muss die Datenübertragung eben stattfinden. Die Freigabe darf wie gesagt nicht für alle sein, nur für die Kiste die eben die Backups machen darf/soll.

Wenn du wirklich den Client schreiben lassen willst, dann musst du dafür auf dem Server ein eigenes Zielverzeichnis anlegen das dann seinerseits auf dem Server nochmal konserviert wird so daß der Client eben doch wieder am Ende, eine Read-Only Ansicht auf Backups vergangener Tage/Wochen bekommt.

Mit normalen Rechten kriegt man das nicht so hin.

Zuerst mal Danke an euch, für eure Beiträge. Sind wirklich interessante Ansätze!

frostschutz schrieb:

Mit normalen Rechten kriegt man das nicht so hin.

Ja, das musste ich jetzt wohl so auch einsehen. Trotzdem nochmal ein ähnlicher Ansatz: Ich mache eine Freigabe in die der Client sein Backup ablegt. Nachts, wenn keiner in der Firma ist, führe ich über Cron aus:

chown -R backup pfad/zum/share
chmod -R 550 pfad/zum/share
chmod 777 pfad/zum/share

Zuerst ändere ich den Eigentümer aller Dateien im Ordner zu backup (der keinen eigenen Samba-Account hat). Dann ändere ich die Berechtigungen, dass die Dateien nur vom neuen Eigentümer und der usrprünglichen Gruppe gelesen werden kann. Dann noch die Ordnerberechtigung ändern, dass ich neue Dateien vom Client aus ablegen kann. So könnten auch Backups mit Hardlinks genutzt werden, um Platz zu sparen. Das erscheint mir gerade als einfachste Lösung, die sich relativ schnell umsetzen lässt. Oder habe ich einen Denkfehler drin?

Zumindest bei Linux wäre das eine schlechte Idee... die Backupdateien sollen ja die Original-Eigentümer und -Rechte besitzen, da das ja durchaus relevant sein kann. z.B. ~/.ssh/authorized_keys funktioniert mit falschen Rechten / Eigentümern nicht. Wenn du diese Rechte dann im Backup mit chmod veränderst ist das Backup verfälscht.

Wie Windows jetzt darauf reagiert kann ich nicht beurteilen... vielleicht ist es da nicht so kritisch, vielleicht aber doch wenn alle Dateien auf einmal ein readonly-Flag haben das beim Wiederherstellen dann womöglich mit übernommen wird (oder halt auch nicht).