Tatort Server: Forensik-Basics ohne Beweise zu grillen

Ein kompromittierter Server ist kein kaputter Drucker: Nicht wild drauflos klicken, nicht „mal eben“ rebooten, nicht hektisch Updates ballern. Erst sichern, dann denken, dann handeln. Sonst hat der Angreifer nicht nur deinen Server angefasst, sondern du auch noch die Spuren verwischt. Klassiker.

Erstmal: Ruhe bewahren und Netzwerk zähmen

Wenn du einen Angriff vermutest, trenn den Server nicht blind vom Strom. RAM-Inhalte, aktive Sessions und laufende Prozesse sind sonst weg. Besser: Netzwerk kontrolliert isolieren. Zum Beispiel am Switch-Port, in der Firewall oder über Security Groups. Wenn du direkt auf der Maschine arbeiten musst, dokumentiere jeden Schritt mit Uhrzeit.

Auf Linux starten wir gerne mit einem simplen Arbeitsverzeichnis auf externem Storage oder einem gemounteten Forensik-Ziel:

# Arbeitsverzeichnis für Beweissicherung
mkdir -p /mnt/forensic/$(hostname)-$(date -u +%Y%m%dT%H%M%SZ)
cd /mnt/forensic/$(hostname)-*
script -a session.log
date -u
hostname -f
whoami

script schreibt deine Shell-Session mit. Nicht hübsch, aber ehrlich.

Flüchtige Daten sichern

Alles, was nach einem Reboot verschwindet, zuerst sichern. Dazu gehören Prozesse, Netzwerkverbindungen, eingeloggte Benutzer, offene Dateien und Routing.

# Volatile Daten sichern
date -u > timestamp.txt
ps auxwwf > ps_auxwwf.txt
pstree -ap > pstree.txt
ss -tulpen > ss_tulpen.txt
ip addr show > ip_addr.txt
ip route show > ip_route.txt
who -a > who_a.txt
w > w.txt
lsof -nP > lsof_nP.txt

Wenn lsof nicht installiert ist: nicht sofort Pakete nachinstallieren. Jede Installation verändert das System. Lieber mit vorhandenen Bordmitteln arbeiten oder ein statisch kompiliertes Tool von einem vertrauenswürdigen Medium nutzen.

Logs einsammeln, bevor sie „magisch“ verschwinden

Logfiles sind oft der Tatortbericht. Besonders spannend: SSH, sudo, Webserver, Cron, Kernel, Paketmanager und Authentifizierung.

# Log-Sammlung
mkdir -p logs
cp -a /var/log/auth.log* logs/ 2>/dev/null
cp -a /var/log/secure* logs/ 2>/dev/null
cp -a /var/log/syslog* logs/ 2>/dev/null
cp -a /var/log/messages* logs/ 2>/dev/null
cp -a /var/log/nginx* logs/ 2>/dev/null
cp -a /var/log/apache2* logs/ 2>/dev/null
cp -a /var/log/apt* logs/ 2>/dev/null
cp -a /var/log/yum.log* logs/ 2>/dev/null
journalctl --no-pager > logs/journalctl_full.txt

Danach Hashes bilden. Damit kannst du später nachweisen, dass deine Kopien unverändert sind.

# Integrität festhalten
find . -type f -print0 | sort -z | xargs -0 sha256sum > SHA256SUMS.txt

Erste Analyse: Wo riecht es nach verbranntem Silizium?

Typische Indikatoren für Kompromittierung sind neue Benutzer, ungewöhnliche SSH-Keys, Cronjobs, verdächtige Prozesse, seltsame SUID-Dateien und ausgehende Verbindungen zu IPs, die niemand eingeladen hat.

# Benutzer und Privilegien prüfen
cat /etc/passwd > etc_passwd.txt
cat /etc/shadow > etc_shadow.txt 2>/dev/null
getent group sudo > group_sudo.txt
getent group wheel > group_wheel.txt
find /home /root -name authorized_keys -type f -exec ls -la {} \; -exec cat {} \; > ssh_authorized_keys.txt

Cron und Systemd sind beliebte Verstecke. Angreifer mögen Persistenz. Sysadmins auch, aber wir nennen es „Betrieb“.

# Persistenz prüfen
crontab -l > crontab_current_user.txt 2>/dev/null
ls -la /etc/cron* > cron_listing.txt
systemctl list-units --type=service --all > systemd_services.txt
systemctl list-timers --all > systemd_timers.txt
find /etc/systemd/system -type f -maxdepth 2 -print -exec sed -n '1,160p' {} \; > systemd_unit_files.txt

Auch SUID/SGID-Dateien anschauen. Eine frisch platzierte Root-Shell mit SUID-Bit ist ungefähr so subtil wie ein blinkender Darth-Vader-Helm im Rack.

# Auffällige Rechte finden
find / -xdev -perm -4000 -type f -ls 2>/dev/null > suid_files.txt
find / -xdev -perm -2000 -type f -ls 2>/dev/null > sgid_files.txt
find / -xdev -mtime -7 -type f -ls 2>/dev/null > modified_last_7_days.txt

Nicht vergessen: Timeline und Kontext

Ein einzelner Fund ist selten die ganze Story. Baue eine Timeline: erster verdächtiger Login, ausgeführte Commands, neue Dateien, Prozessstarts, Netzwerkziele. Prüfe ~/.bash_history, aber vertraue ihr nicht blind. Profis löschen Spuren. Halbprofis löschen sie schlecht. Beides hilft.

# Shell-Historien sichern
find /home /root -name ".*history" -type f -exec ls -la {} \; -exec cat {} \; > shell_histories.txt

Danach: Eindämmen, neu bauen, nicht schönflicken

Wenn der Server wirklich kompromittiert ist: nicht „bereinigen“ und weiterlaufen lassen. Image ziehen, Beweise sichern, Zugangsdaten rotieren, Schlüssel austauschen, betroffene Systeme prüfen und sauber neu provisionieren. Ein kompromittiertes System ist wie ein Toastbrot im Toaster nach Rauchentwicklung: Du kannst kratzen, aber lecker wird es nicht mehr.

Forensik heißt nicht, sofort den Hacker im Hoodie zu finden. Es heißt: Spuren sichern, Zustand verstehen, Schaden begrenzen und sauber wieder online kommen. Ohne Beweise zu grillen.