Erpressungssoftware ist bei kleinen Betrieben nicht dramatischer geworden, sondern gründlicher: Bevor verschlüsselt wird, werden Daten abgezogen (damit man auch ohne Schlüsselbedarf erpressbar bleibt), und vorher werden die Sicherungen gesucht. Sie stehen ganz oben auf der Liste, weil sie die einzige Antwort sind, die kein Lösegeld kostet.
Eine Sicherung, die mit denselben Zugangsdaten erreichbar ist wie der Server, ist im Ernstfall keine Sicherung. Wer sich auf sie verlässt, hat den Zustand „wir haben Backups“ ohne den Zustand „wir können wiederherstellen“ und merkt den Unterschied genau einmal.
Die drei Eigenschaften, auf die es ankommt#
1. Getrennte Zugangsdaten. Der Server darf schreiben, aber nicht löschen und nicht überschreiben. Wo das Ziel per SSH oder S3 erreicht wird, heißt das: eigenes Konto, eingeschränktes Recht.
# SSH-Zugang, der nur einen einzigen Befehl zulässt (Ziel-authorized_keys)
command="borg serve --restrict-to-path /srv/sicherungen/web01 --append-only",restrict ssh-ed25519 AAAA... web01-sicherung--append-only ist der entscheidende Teil: Wer den Server übernimmt, kann neue Daten schreiben, aber vorhandene Archive nicht entfernen.
2. Unveränderlichkeit auf der Zielseite. Bei Objektspeicher heißt das Objektsperre mit Aufbewahrungsfrist; bei ZFS oder Btrfs Schnappschüsse, die vom Zielsystem verwaltet werden, nicht von der Quelle. Entscheidend ist immer: Die Löschentscheidung liegt nicht bei der Maschine, die kompromittiert wurde.
3. Aufbewahrung, die den Zeitraum davor abdeckt. Wenn die Hintertür seit sechs Wochen liegt und die Aufbewahrung 14 Tage beträgt, existiert kein sauberer Stand mehr. Vier Wochen sind das Minimum, drei Monate sind ruhiger.
Prüfen, ob es wirklich so ist#
# Kann der Server sein eigenes Archiv löschen? (Testlauf auf einer Kopie!)
borg delete --dry-run ssh://sicherung@ziel/srv/sicherungen/web01::probe
# erwartet: Fehler wegen append-only
# Wie alt ist der älteste vorhandene Stand?
borg list ssh://sicherung@ziel/srv/sicherungen/web01 | head -3
# Objektspeicher: ist die Sperre aktiv?
aws s3api get-object-lock-configuration --bucket sicherungenNicht „läuft der Sicherungsauftrag“, sondern: Wie lange dauert es, aus dem vorhandenen Stand einen laufenden Dienst zu machen? Diese Zahl kennt fast niemand, und sie ist die einzige, die im Ernstfall zählt. Einmal messen, Datum notieren, in der Doku festhalten, das ist ein Nachmittag Arbeit und ersetzt jede Diskussion.
Verschlüsselung: notwendig, aber mit Haken#
Sicherungen gehören verschlüsselt, sonst ist die Kopie eine zweite Angriffsfläche. Der Haken ist der Schlüssel: Liegt er nur auf dem Server, ist er nach dem Vorfall weg. Er gehört an einen zweiten, unabhängigen Ort, offline oder in einem Passworttresor, auf den man auch ohne die betroffene Infrastruktur kommt.
Wenn es passiert ist#
- Nicht sofort zurückspielen. Erst den Zeitpunkt der Kompromittierung eingrenzen (Die erste Stunde).
- Sauberes System, dann Daten, nicht das befallene System mit alten Daten überschreiben (Neu aufsetzen statt säubern).
- Nicht zahlen, ohne die Lage zu kennen. Zahlung garantiert weder Entschlüsselung noch Löschung der abgezogenen Daten und kann je nach Empfänger rechtlich problematisch sein. Diese Entscheidung gehört nicht auf einen Betriebsabend.
- Meldepflichten prüfen, beim Datenabfluss läuft die Uhr: Meldefristen: 24, 72, ein Monat.
Der unbequeme Teil#
Die häufigste Ursache bei kleinen Betrieben ist kein raffinierter Angriff, sondern eine erreichbare Verwaltungsoberfläche oder ein wiederverwendetes Passwort ohne zweiten Faktor. Beides steht hier: Verwaltungsoberflächen im Internet und Zweiter Faktor, der wirklich trägt. Die Sicherung ist die Antwort auf den Fall, dass beides nicht gereicht hat, nicht der Ersatz dafür.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
