Nach einem Einbruch will man das System reparieren. Das ist verständlich und meistens der teurere Weg: Ein Angreifer, der root hatte, kann an Stellen etwas hinterlassen haben, die keine Prüfung vollständig abdeckt, Systemdienste, Bibliotheken, Zeitgeber, Paketquellen, Kernelmodule, initramfs.
Der Unterschied ist keine Frage der Sorgfalt, sondern der Beweisbarkeit: Nach dem Säubern kann man nicht belegen, dass nichts mehr da ist. Nach dem Neuaufbau kann man belegen, dass alles, was läuft, aus einer bekannten Quelle kommt. Im Zweifel zählt die zweite Aussage, gegenüber Kunden ebenso wie gegenüber sich selbst.
Wann Säubern trotzdem vertretbar ist#
Es gibt Fälle: ein Webhosting-Konto ohne Systemrechte, ein kompromittiertes Anwendungspasswort ohne Hinweis auf Ausführung, ein Fund, der nachweislich vor dem Zugriff scheiterte. Gemeinsam ist ihnen, dass kein Prozess mit Systemrechten unter fremder Kontrolle stand. Sobald das unklar ist, gilt der Neuaufbau.
Der Ablauf#
1. Alte Maschine bleibt stehen, getrennt. Sie ist Beweismittel und Nachschlagewerk. Erst abschalten, wenn der Ersatz läuft.
2. Neue Maschine, saubere Quelle. Frisches Abbild vom Anbieter, aktueller Stand, keine Übernahme des alten Systemabbilds. Härtung von Anfang an, die Reihenfolge dieser Seite: Passwort-Login abschalten, eingehend dichtmachen, automatische Sicherheitsupdates, Rechte eng.
3. Daten übernehmen, nichts Ausführbares.
| Übernehmen | Nicht übernehmen |
|---|---|
| Datenbankinhalte (Dump, geprüft) | Systemdateien, Binärdateien |
| Hochgeladene Dateien der Nutzer | Skripte und Anwendungscode von der alten Maschine |
| Inhalte, Bilder, Dokumente | Cronjobs, systemd-Units, authorized_keys |
| Konfiguration gelesen, neu geschrieben | Konfiguration kopiert |
Anwendungscode kommt aus der Versionsverwaltung, nicht vom befallenen Server. Wenn es keine Versionsverwaltung gibt, ist der Code vor der Übernahme durchzusehen, das ist der Punkt, an dem der Aufwand real wird.
# Hochgeladene Dateien: alles Ausführbare auffällig machen, bevor es mitkommt
find /alte-daten/uploads -type f \( -name '*.php' -o -name '*.phar' -o -name '*.sh' \) -printf '%T+ %p\n' | sort
# In einem Upload-Verzeichnis hat davon nichts etwas verloren.4. Alle Geheimnisse sind neu. Datenbankpasswörter, API-Tokens, SSH-Schlüssel, Zertifikatsschlüssel, Sitzungsschlüssel der Anwendung. Auch die, von denen man annimmt, sie seien nicht betroffen (Geheimnisse gehören nicht ins Repo).
5. Die Lücke schließen, die den Einstieg ermöglicht hat. Sonst wiederholt sich das Ganze in Wochen. Wenn der Einstiegspunkt nach der Spurensicherung unklar bleibt, gilt der harte Weg: alles, was von außen erreichbar war, ist verdächtig, Erreichbarkeit reduzieren, Version aktualisieren, zweiten Faktor einführen.
6. Sitzungen und Benutzer. Nach dem Umzug alle Anwendungssitzungen ungültig machen und Kundinnen und Kunden zur Passwortänderung auffordern, wenn Zugangsdaten betroffen sein konnten. Das ist zugleich Teil der Benachrichtigungspflicht, siehe Meldefristen.
Ein Wiederaufbau deckt gnadenlos auf, was nicht dokumentiert war: undokumentierte Konfiguration, per Hand nachinstallierte Pakete, ein Zertifikat, das jemand einmal hochgeladen hat. Wer diesen Aufbau protokolliert, hat danach eine Aufbauanleitung und die ist beim nächsten Mal, geplant oder nicht, mehr wert als jede Sicherung.
Die alte Maschine zum Schluss#
Bevor sie verschwindet: Abbild sichern (Beweislage, Fristen), Protokolle exportieren, Zeitpunkt der ersten Auffälligkeit festhalten. Erst dann löschen und beim Anbieter darauf achten, dass auch Schnappschüsse und alte Sicherungen der befallenen Maschine mit verschwinden, sofern sie nicht als Beweismittel gebraucht werden.
Wie man den Zustand der neuen Maschine danach beobachtet, damit derselbe Weg nicht ein zweites Mal unbemerkt funktioniert: Einen Einbruch erkennen und Angriffsfläche von außen messen.
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.
