Der Moment ist unangenehm und immer gleich: irgendetwas stimmt nicht, ein fremder Prozess, eine Beschwerde des Anbieters, ausgehender Verkehr auf Port 25. Was in den nächsten sechzig Minuten passiert, entscheidet darüber, ob man später rekonstruieren kann, was geschehen ist.
Die häufigsten Fehler passieren aus Hilflosigkeit: neu starten, Schadcode löschen, „mal sauber machen“, Passwörter ändern und weitermachen. Alle vier zerstören Spuren, ohne den Zugang des Angreifers sicher zu schließen und danach weiß niemand, ob die Maschine noch fremd bedient wird.
Reihenfolge, ohne Diskussion#
1. Netz trennen, Maschine nicht ausschalten. Ausschalten löscht den Arbeitsspeicher und damit laufende Verbindungen, entpackte Prozesse und Schlüssel im RAM.
# Sauberste Variante: über die Konsole des Anbieters (Netz aus, VM läuft)
# Nur wenn das nicht geht, auf der Maschine selbst:
sudo nft add rule inet filter output ip daddr != 198.51.100.7 drop # 198.51.100.7 = eigene Admin-IP2. Zweiten Zugangsweg sichern. Konsole des Anbieters öffnen, bevor an SSH etwas geändert wird. Wer sich hier aussperrt, verliert Stunden.
3. Zeitstempel festhalten. Alles Weitere wird auf diesen Punkt bezogen.
date -u +%FT%TZ | tee /root/vorfall-start.txt4. Flüchtiges einsammeln, lesend, nicht ändernd.
{
date -u; uptime; w; last -20
ps auxf
ss -tunap
ls -la /proc/*/exe 2>/dev/null | grep -i deleted
crontab -l; ls -la /etc/cron.*; systemctl list-timers --all
cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null
find / -xdev -mmin -1440 -type f -printf '%T@ %p\n' 2>/dev/null | sort -rn | head -100
} > /root/vorfall-$(date +%F-%H%M).txtUnd sofort wegkopieren, denn auf dieser Maschine ist ab jetzt nichts mehr vertrauenswürdig:
scp /root/vorfall-*.txt admin@sicherer-host:/vorfaelle/5. Wenn möglich: Abbild statt Aufräumen. Bei einer VM ist der Schnappschuss die billigste Forensik, die es gibt, er kostet Plattenplatz und rettet die gesamte Beweislage. Beim eigenen Hypervisor oder beim Anbieter über die Oberfläche anlegen, bevor irgendetwas repariert wird.
6. Zugänge sperren, in dieser Reihenfolge: fremde SSH-Schlüssel entfernen, alle Sitzungen beenden, Passwörter und Tokens rotieren (Geheimnisse gehören nicht ins Repo), von einem sauberen Rechner aus, nicht von der betroffenen Maschine.
Was man in dieser Stunde nicht tut#
- Neu starten (löscht flüchtige Spuren).
- Gefundene Dateien löschen (danach ist unklar, was sie taten).
- Ein Antivirenprogramm nachinstallieren (verändert das System, findet meist nichts).
- Die Sicherung sofort zurückspielen (siehe unten).
- Auf der betroffenen Maschine Passwörter ändern, während sie noch mitlesen kann.
Eine Wiederherstellung ist erst sinnvoll, wenn feststeht, seit wann die Maschine kompromittiert ist. Sonst spielt man den Zustand zurück, in dem die Hintertür schon lag. Der Zeitpunkt ergibt sich aus den Spuren aus Schritt 4, deshalb kommt Spurensicherung vor Wiederherstellung, siehe Neu aufsetzen statt säubern.
Danach: die Uhr für Meldungen läuft#
Sobald personenbezogene Daten betroffen sein könnten, beginnt eine Frist, bei der Datenschutz-Grundverordnung 72 Stunden ab Kenntnis. Für bestimmte Betriebe kommen weitere Fristen hinzu. Was wann an wen geht, steht in Meldefristen: 24, 72, ein Monat. Meldet sich der Anbieter mit einer Missbrauchsbeschwerde, gilt zusätzlich Abuse-Meldung beantworten.
Vorher ausdrucken#
Dieser Ablauf nützt nichts, wenn er auf der Maschine liegt, um die es geht. Eine Seite reicht: Kontakt zum Anbieter (mit Kundennummer), Weg zur Konsole, wer entscheidet, wohin Spuren kopiert werden, welche Fristen laufen. Wer die Signale davor erkennen will, findet sie in Einen Einbruch erkennen.
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.
