Wenn etwas schiefgeht

Modul 10: Sicher bleiben · Lesezeit: 11 Minuten

Lernziel: Nach dieser Lektion erkennen Sie die Anzeichen eines gehackten Servers, unternehmen die ersten Schritte, ohne Beweise oder Backups zu zerstören, entscheiden zwischen Bereinigen und Neuinstallieren und wissen, wann Sie eine Datenpanne melden müssen.

Kernbegriffe: Vorfall, Anzeichen, Isolieren, Snapshot als Beweis, Vorfallprotokoll, Neuinstallation, Schlüssel und Passwörter ersetzen, sauberes Backup, Meldepflicht bei Datenpannen (72 Stunden), zuständige Datenschutzaufsichtsbehörde, Notfallplan

Einen Vorfall erkennen

Ein Einbruch kündigt sich selten an. Meistens bemerken Sie etwas, das "seltsam" ist. Anzeichen, die Sie ernst nehmen sollten:

• Hohe Last ohne Grund: Der Prozessor läuft dauerhaft bei 100 %, zum Beispiel wegen eines Kryptominers. Sehen Sie mit top oder htop nach, welcher Prozess es ist und unter welchem Benutzer er läuft.
• Unbekannte Prozesse oder Dienste: ein Programm mit einem merkwürdigen Namen, oft in /tmp, /dev/shm oder /var/tmp, oder ein systemd-Dienst oder Timer, den Sie nicht selbst angelegt haben.
• Ausgehender Verkehr, der nicht stimmt: Ihr Anbieter meldet, dass Ihr Server Spam verschickt oder andere Server angreift, oder die Netzwerkgrafiken im Panel zeigen Spitzen.
• Neue Benutzer oder Schlüssel: eine Zeile in ~/.ssh/authorized_keys, die Sie nicht kennen, ein Benutzer in /etc/passwd mit UID 0, ein neuer Eintrag in /etc/sudoers.d/.
• Geänderte Dateien: unbekannte PHP-Dateien in Ihrer Website, eine geänderte Crontab.
• Logs, die verschwunden oder leer sind: Angreifer verwischen gern ihre Spuren.

Ein paar Befehle, um sich schnell umzusehen:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last zeigt, wer sich wann angemeldet hat, die awk-Zeile listet alle Konten mit UID 0 auf (das sollte nur root sein), und die find-Zeile sucht Units und Cron-Dateien, die neuer sind als eine Datei, die bei der Installation angelegt wurde.

Achtung: Auf einem Server, der wirklich gehackt wurde, können auch diese Befehle manipuliert sein. Sie helfen Ihnen, etwas zu vermuten, nicht zu beweisen, dass alles sauber ist.

Die ersten Schritte: Ruhe, Isolieren, Festhalten

Das Wichtigste in den ersten Minuten ist, nicht in Panik Dinge zu löschen. Gehen Sie in dieser Reihenfolge vor.

1. Beginnen Sie ein Protokoll. Notieren Sie auf Papier oder auf Ihrem Laptop (nicht auf dem Server), was Sie sehen, wann und was Sie tun. Das brauchen Sie später, um die Ursache zu finden, für eine Meldung, eine Anzeige oder Ihre Versicherung. Das empfiehlt auch das niederländische NCSC.

2. Isolieren Sie den Server. Verhindern Sie, dass er weiteren Schaden anrichtet (Spam, Angriffe, Daten abfließen lassen), ohne ihn auszuschalten:

• Schließen Sie in der Firewall Ihres Anbieters (falls vorhanden) alles außer SSH von Ihrer eigenen Adresse; oder
• tun Sie dasselbe auf dem Server selbst, über die Konsole;
• wenn es nicht anders geht: Schalten Sie den Server über das Panel aus. Dann ist allerdings der Inhalt des Arbeitsspeichers verloren.

3. Erstellen Sie einen Snapshot. Ein Snapshot im Panel hält den Zustand fest, wie er jetzt ist. Das ist Ihr Beweis und Ihre Quelle, um später herauszufinden, wie der Angreifer hineingekommen ist, auch wenn Sie den Server danach neu installieren.

4. Sichern Sie Ihre Backups. Prüfen Sie, ob Ihre Backups außerhalb des Servers noch intakt sind, und sorgen Sie dafür, dass der gehackte Server nicht mehr darauf zugreifen kann (zum Beispiel, indem Sie den Zugangsschlüssel des Servers zum Backup-Speicher widerrufen). Angreifer versuchen auch, Backups zu löschen oder zu verschlüsseln.

Bereinigen oder neu installieren?

Die verlockende Antwort lautet: die verdächtige Datei entfernen, den Kryptominer stoppen, fertig. Aber Sie wissen nicht, was ein Angreifer sonst noch getan hat: eine zweite Hintertür, ein verändertes Programm, ein zusätzlicher Schlüssel, ein Timer, der alles wiederherstellt. Einem Server, auf dem jemand root-Rechte hatte, können Sie nicht mehr vertrauen.

Der Rat von Administratoren und auch des niederländischen NCSC lautet deshalb: Installieren Sie betroffene Systeme neu und stellen Sie Ihre Daten aus einem Backup wieder her, das selbst nicht infiziert ist. Konkret:

1. Eine Neuinstallation (Neuinstallation im Panel oder ein neuer Server).
2. Sofort die Grundlagen aus diesem Kurs: Updates, normaler Benutzer mit sudo, SSH mit neuen Schlüsseln, Firewall (Modul 2 bis einschließlich 5).
3. Ihre Anwendungen neu aus offiziellen Quellen installieren, am besten mit Ihren Compose-Dateien oder Notizen (Lektion 10.4).
4. Daten (Datenbank, Uploads) aus einem Backup von vor dem Vorfall zurückspielen. Spielen Sie Code oder Konfiguration nicht blind zurück: Darin kann die Hintertür stecken. Prüfen Sie auch zurückgespielte Daten kritisch; ein Angreifer kann schon länger im System gewesen sein, als Sie denken.
5. Die Lücke schließen, durch die der Angreifer hineingekommen ist. Sonst passiert es erneut. Der Snapshot aus Schritt 3 hilft bei der Untersuchung.

Alles ersetzen, was abgeflossen sein kann

Gehen Sie davon aus, dass alles, was auf dem Server lag, in den Händen des Angreifers ist:

• SSH-Schlüssel: Entfernen Sie die öffentlichen Schlüssel, die auf dem Server lagen, überall; erstellen Sie neue Schlüsselpaare, wenn private Schlüssel auf dem Server lagen.
• Passwörter von Datenbanken, Verwaltungspanels und Benutzern Ihrer Anwendung.
• API-Schlüssel und Tokens (Mail, Zahlungen, Cloud-Speicher, Backup-Speicher) aus .env-Dateien und Konfiguration: beim jeweiligen Dienst widerrufen und ersetzen.
• Zertifikate: Der private Schlüssel Ihres Zertifikats lag auf dem Server. Lassen Sie das Zertifikat widerrufen und beantragen Sie ein neues (mit Let's Encrypt geht das schnell, Lektion 7.3).

Melden: die DSGVO und andere

Lagen personenbezogene Daten auf dem Server (Kundendaten, Konten, E-Mail-Adressen), liegt möglicherweise eine Datenpanne (Verletzung des Schutzes personenbezogener Daten) vor. Die DSGVO (Artikel 33) besagt, dass der Verantwortliche eine Datenpanne unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde, der Aufsichtsbehörde meldet. Das ist die zuständige Datenschutzaufsichtsbehörde (für Unternehmen die Landesdatenschutzbehörde Ihres Bundeslandes); die Meldung erfolgt in der Regel über deren Online-Formular. Einige wichtige Punkte:

• Eine Meldung ist nicht nötig, wenn die Panne voraussichtlich zu keinem Risiko für die Betroffenen führt; im Zweifel melden Sie;
• haben Sie noch nicht alle Informationen, melden Sie trotzdem innerhalb von 72 Stunden und ergänzen Sie später;
• die Personen, deren Daten betroffen sind, informieren Sie, wenn für sie ein hohes Risiko besteht;
• jede Datenpanne dokumentieren Sie in einem eigenen Register, auch wenn Sie nicht melden müssen.

Verwalten Sie den Server für einen Kunden, sind Sie meist Auftragsverarbeiter: Dann müssen Sie den Kunden (den Verantwortlichen) unverzüglich informieren, damit dieser melden kann. Diese Lektion ist keine Rechtsberatung; schauen Sie im Zweifel auf der Website Ihrer zuständigen Datenschutzaufsichtsbehörde nach.

Außerdem: Melden Sie Missbrauch, der von Ihrem Server ausging, Ihrem Anbieter (der hat ihn oft schon bemerkt), und erstatten Sie bei einem schweren Angriff Anzeige bei der Polizei (online über die Onlinewache der Polizei Ihres Bundeslandes). Fällt Ihre Organisation unter das BSI-Gesetz (BSIG) in der Fassung des NIS-2-Umsetzungsgesetzes, gelten gesonderte, kürzere Meldefristen.

Vorbereiten: der Notfallplan

Ein Vorfall passiert immer zu einem ungünstigen Zeitpunkt. Was Sie vorab geregelt haben, spart Stunden:

• Wissen Sie, wie Sie die Konsole und die Snapshot-Funktion Ihres Anbieters erreichen, und bewahren Sie die Zugangsdaten zum Panel (mit Zwei-Faktor-Authentifizierung) irgendwo außerhalb des Servers auf.
• Wissen Sie, wo Ihre Backups liegen, wie Sie sie zurückspielen und dass sie funktionieren (Lektion 8.2).
• Führen Sie eine Liste aller Geheimnisse, die auf dem Server liegen, damit Sie wissen, was Sie ersetzen müssen.
• Führen Sie eine Telefonliste: Ihr Anbieter, wer sonst noch über den Server Bescheid wissen muss (Kunde, Kollege) und die Kontaktdaten für die Meldung einer Datenpanne.

In der Praxis

In der VPS-Ansicht von WebOké finden Sie die Konsole, Snapshots, Backups und die Schaltfläche zum Neuinstallieren; bei anderen Anbietern heißen diese ungefähr gleich (Console oder VNC, Snapshot, Rescue, Reinstall). Dieser Kurs ist Hilfe zur Selbsthilfe: Niemand schaut auf Ihrem Server mit und niemand räumt einen Vorfall für Sie auf. Gerade deshalb ist ein Notfallplan, den Sie selbst umsetzen können, so wichtig.

Zusammenfassung

• Anzeichen: unerklärliche Last, unbekannte Prozesse, Dienste oder Schlüssel, seltsamer ausgehender Verkehr, geänderte oder verschwundene Dateien und Logs.
• Erste Schritte: Protokoll führen, den Server isolieren, einen Snapshot als Beweis erstellen, Backups sichern.
• Einen Server, auf dem jemand root-Rechte hatte, bereinigen Sie nicht, sondern installieren ihn neu; Daten aus einem sauberen Backup zurückspielen und die Lücke schließen.
• Ersetzen Sie alle Schlüssel, Passwörter, Tokens und Zertifikate, die auf dem Server lagen.
• Personenbezogene Daten betroffen? Eine Datenpanne melden Sie möglichst binnen 72 Stunden der zuständigen Datenschutzaufsichtsbehörde, und Sie dokumentieren jede Panne.

Quiz

Aufgabe

Aufgabe O10.3: Ihr Notfallplan auf einer Seite. Schreiben Sie für Ihren eigenen Server einen Notfallplan von höchstens einer DIN-A4-Seite: Wie gelangen Sie ins Panel, zur Konsole und zu den Snapshots; wo liegen Ihre Backups und wie spielen Sie sie zurück; welche Geheimnisse liegen auf dem Server; wen müssen Sie informieren (und müssen Sie bei einer Datenpanne melden); und welche ersten fünf Schritte unternehmen Sie bei Verdacht auf einen Einbruch. Bewahren Sie den Plan außerhalb des Servers auf.

Weiterführende Informationen

• Kein Zugriff mehr auf Ihren VPS: Was nun?
• Snapshots und Backups Ihres VPS
• Eine eigene ISO einbinden oder Ihren VPS neu installieren
• Niederländisches NCSC, Gehackt, wat nu? (niederländische Quelle): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Datenschutzkonferenz, Übersicht der Datenschutzaufsichtsbehörden: https://www.datenschutzkonferenz-online.de/datenschutzaufsichtsbehoerden.html