Dein Linux-Server wurde gehackt: Was du jetzt sicherst und was du besser nicht anfasst

Der typische Ablauf sieht so aus: Ein Monitoring-Alert oder eine Abuse-Mail des Providers weist auf ausgehenden Traffic hin, jemand meldet sich per SSH an, killt den verdächtigen Prozess, löscht ein paar Dateien in /tmp, dreht das Passwort und startet den Server neu, damit der Dienst wieder sauber läuft. Nach diesem Neustart ist der Arbeitsspeicher weg, und mit ihm die entpackten Payloads, die offenen Netzwerkverbindungen und die Prozessumgebung. Bei dateilosen Angriffen war der Speicher sogar der einzige Ort, an dem der Schadcode jemals lag.

Gleichzeitig arbeitest du auf einem System, dem du nicht mehr trauen darfst. Wenn ps, ls oder ss ersetzt wurden oder ein Kernel-Modul die Ausgabe filtert, siehst du genau das, was der Angreifer dich sehen lassen will. Ein Abgleich zwischen den Einträgen unter /proc und der Ausgabe der Standardwerkzeuge, ein Blick auf /etc/ld.so.preload und eine Paketverifikation mit rpm -Va oder debsums bringen hier deutlich mehr als ein schneller Durchlauf von rkhunter, der auf dem kompromittierten System ohnehin nur begrenzt aussagekräftig ist.

Der dritte Fehler ist der Umgang mit den Logs. Wer lokal nach /var/log greift, arbeitet mit Daten, die der Angreifer nach einer erfolgreichen Rechteausweitung anpassen konnte. journald-Dateien lassen sich austauschen, wtmp und btmp lassen sich mit Standardwerkzeugen bereinigen, und ein einzelner fehlender Zeitraum fällt ohne Gegenprobe kaum auf. Belastbar wird die Auswertung erst durch externe Quellen wie einen zentralen Loki- oder Syslog-Empfänger, Firewall- und Netflow-Daten oder die Logs des vorgelagerten Reverse Proxy, und durch eine Timeline aus den Dateisystem-Metadaten.