Security & Hardening

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

Nicht neu starten und nicht aufräumen. Erst Speicher und Zustand sichern, dann das System vom Netz nehmen. Wer zuerst putzt, vernichtet genau die Spuren, die für Ursachenanalyse und Meldepflichten gebraucht werden.

6 Kapitel mit allen Befehlen
Zwei Security-Fachleute prüfen ein Dashboard im Betriebsraum
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Der erste Reflex ist fast immer der falsche

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.

Miniatur-Szene: Serverschrank in einer Schutzhülle, Vorhängeschlösser und ein Schild davor
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Erstmaßnahmen nach einer Kompromittierung

  1. 01 Isolieren, nicht abschalten
  2. 02 Speicherabbild sichern
  3. 03 Image und Hashes
  4. 04 Timeline aus Metadaten und Logs
  5. 05 Persistenz aufspüren
  6. 06 Neu aufbauen und melden
Was du mitnimmst

Die Reihenfolge, die dir die Beweise erhält

Incident Response unter Linux ist kein einzelnes Werkzeug, sondern eine Abfolge. Volatiles zuerst, Persistentes danach, Analyse immer abseits des betroffenen Systems. Die folgenden Schritte kannst du auch unter Druck abarbeiten, und sie halten dir den Weg zu einer späteren forensischen Auswertung oder einer Anzeige offen.

Isolieren statt ausschalten

Nimm das System vom Netz, indem du den Switch-Port abklemmst, die Security Group oder die Firewall vor dem Host dichtmachst oder das virtuelle Interface trennst. Der Server selbst bleibt an, denn ein Reboot oder das Ziehen der Stromversorgung kostet dich den kompletten Arbeitsspeicher. Bei virtuellen Maschinen ist ein Snapshot inklusive RAM auf Hypervisor-Ebene meist der sauberste und schnellste Weg.

Flüchtige Daten mit vertrauenswürdigen Binaries sichern

Erstelle ein Speicherabbild, bei Cloud-Instanzen zum Beispiel mit AVML, auf klassischen Servern mit LiME und dem passenden Kernel-Modul. Danach sicherst du Prozessliste, offene Dateien, Netzwerkverbindungen, geladene Kernel-Module und Mounts, und zwar mit statisch gelinkten Werkzeugen von einem read-only eingebundenen Medium, nicht mit den Binaries des Systems. Alles wandert über das Netz oder auf einen externen Datenträger, nicht auf die lokale Platte.

Datenträger-Image ziehen und Hashes festhalten

Erst wenn die flüchtigen Daten gesichert sind, erstellst du ein Image der Datenträger, idealerweise vom heruntergefahrenen System oder aus einem Snapshot heraus, mit dd, dc3dd oder ewfacquire. Notiere SHA-256-Summen von Image und Einzelartefakten, dokumentiere Zeitstempel und Verantwortliche und lege damit den Grundstein für eine nachvollziehbare Beweiskette.

Timeline bauen statt einzelne Dateien anstarren

Aus dem Image erzeugst du mit fls und mactime aus dem Sleuth Kit oder mit log2timeline und Plaso eine Zeitleiste, die Dateisystem-Metadaten, Logeinträge und Shell-History zusammenführt. So siehst du, wann der erste Zugriff stattfand, welche Datei danach angelegt wurde und welche Aktion daraus folgte. Ergänze die Zeitleiste um externe Quellen, damit manipulierte lokale Logs auffallen.

Persistenz systematisch abklopfen

Angreifer bleiben selten über einen einzigen Mechanismus. Prüfe systemd-Units und Timer in /etc/systemd und in den Benutzerverzeichnissen, cron und at, die authorized_keys aller Accounts, die PAM-Konfiguration, /etc/ld.so.preload, LD_PRELOAD-Einträge in Service-Definitionen, ungewöhnliche SUID-Dateien, geladene Kernel-Module und die initramfs. Ein Abgleich der Paketprüfsummen und eine vorhandene AIDE- oder Tripwire-Datenbank verkürzen diesen Schritt erheblich.

Neu aufbauen, Zugänge rotieren, Meldepflichten klären

Ein kompromittiertes System wird nicht bereinigt, sondern aus einer sauberen Quelle neu aufgesetzt, mit rotierten Schlüsseln, Passwörtern, API-Tokens und Zertifikaten und mit der geschlossenen Lücke aus deiner Analyse. Parallel prüfst du, ob personenbezogene Daten betroffen sind und damit eine Meldung nach Artikel 33 DSGVO ansteht, und ob dein Unternehmen unter sektorspezifische Meldepflichten fällt.

Tutorial

Vom Verdacht zum belastbaren Befund

Die Reihenfolge in diesem Teil ist die Reihenfolge am Vorfall: Werkzeuge und Protokoll vorbereiten, flüchtige Daten nach Vergänglichkeit sichern, Abbild ziehen und hashen, Timeline bauen, Persistenz abklopfen und erst danach neu aufbauen. Jeder Schritt, den du vorziehst, vernichtet Material aus einem der vorherigen.

01

Bevor du dich anmeldest

Jeder Tastendruck auf dem betroffenen System verändert es. Deshalb steht die Vorbereitung vor dem ersten Login, nicht danach.

Werkzeugkasten auf dem Analyserechner vorbereiten
# Auf einem sauberen System, nicht auf dem Verdachtssystem
mkdir -p /mnt/ir/bin && cd /mnt/ir/bin

# Statisch gelinkte Werkzeuge mitbringen, den Binaries des Systems traust du nicht
ldd ./busybox     # "not a dynamic executable" ist das Ziel
ldd ./avml

# Auf dem betroffenen System als Erstes: Sitzung vollständig mitschreiben
script -q -f /mnt/ir/protokoll-$(date -u +%Y%m%dT%H%M%SZ).log
date -u; timedatectl status; uptime -s

Halte die Systemzeit gegen eine verlässliche Referenz fest. Weicht die Uhr ab, ist jeder Zeitstempel in deiner späteren Timeline um genau diesen Versatz verschoben, und du korrelierst Firewall-Logs mit den falschen Ereignissen. Notiere zusätzlich die Zeitzone, denn das Journal zeigt Lokalzeit und viele Anwendungslogs schreiben in UTC.

Beweismittelkette, die später standhält

  • Wer, wann, was, womit protokollierenVersicherung, Aufsichtsbehörde und im Streitfall ein Gericht fragen nach der lückenlosen Kette. Eine Lücke entwertet die gesamte Analyse, auch wenn der technische Befund stimmt.
  • Jede gesicherte Datei sofort hashenOhne Hash zum Zeitpunkt der Sicherung kann niemand belegen, dass an dem Abbild nichts verändert wurde. Notiere den Hash zusätzlich außerhalb des Datenträgers, auf dem er liegt.
  • Nur auf Kopien arbeiten, Originale einlagernAnalysewerkzeuge schreiben, auch wenn sie es nicht sollen. Auf einer Arbeitskopie ist das folgenlos, auf dem Original ist es ein Beweismittelverlust.
  • Kommunikation aus dem Vorfall heraushaltenWenn Angreifende noch Zugriff haben, lesen sie mit. Sprich die Koordination über einen getrennten Kanal ab, nicht über das betroffene Mailsystem oder den betroffenen Chat.
02

Flüchtige Daten in der richtigen Reihenfolge

RFC 3227 gibt die Reihenfolge vor: zuerst das, was beim Ausschalten verschwindet. Speicher und Netzzustand vor Prozessen, Prozesse vor der Platte.

Zustand einsammeln, alles nach außen schreiben
IR=/mnt/ir/$(hostname)-$(date -u +%Y%m%dT%H%M%SZ); mkdir -p "$IR"

ss -tulpanw        > "$IR/ss.txt"
ps auxwwf          > "$IR/ps.txt"
lsof -nP           > "$IR/lsof.txt"
lsmod              > "$IR/lsmod.txt"
{ ip -br a; ip route; ip neigh; }        > "$IR/net.txt"
{ w; last -F -w; lastlog; }              > "$IR/logins.txt"
{ iptables-save; nft list ruleset; }     > "$IR/firewall.txt"

# Zu jedem verdächtigen Prozess: echtes Binary, Arbeitsverzeichnis, Aufrufzeile
ls -l /proc/1234/exe /proc/1234/cwd
tr '\0' ' ' < /proc/1234/cmdline; echo
cp /proc/1234/exe "$IR/pid1234.bin"

Ein bereits gelöschtes Programm hängt bei ls -l /proc/<pid>/exe mit dem Zusatz (deleted) im Pfad, lässt sich über den Proc-Eintrag aber weiter kopieren. Das ist oft die einzige Chance, überhaupt an die Schadsoftware zu kommen, weil sie sich nach dem Start selbst entfernt hat. Nach einem Neustart ist sie endgültig weg.

Arbeitsspeicher sichern
# Statisch gelinktes Werkzeug vom mitgebrachten Datenträger, kein Compiler auf dem Ziel
/mnt/ir/bin/avml "$IR/speicher.lime"
sha256sum "$IR/speicher.lime" | tee "$IR/speicher.sha256"

# Bei virtuellen Maschinen einfacher und sauberer über den Hypervisor
sudo virsh dump --memory-only --live web01 /mnt/ir/web01.dump

Schreib das Abbild niemals auf die betroffene Platte. Jedes geschriebene Gigabyte überschreibt gelöschte Bereiche, die du in der Auswertung noch brauchst. Ziel ist ein USB-Datenträger oder eine Netzfreigabe. Im Speicher stecken die Dinge, die auf der Platte fehlen: entschlüsselte Nutzlast, Zugangsdaten im Klartext, aktive Verbindungen und die Prozessliste vor deinem Eingriff.

03

Abbild ziehen und Hashes festhalten

Erst wenn die flüchtigen Daten gesichert sind, geht es an die Platte. Ab hier darf das System auch vom Netz.

Abbild und Verifikation
# Physisches System: von einem Live-Medium booten, Quelle nie schreibend einhängen
sudo dd if=/dev/sda of=/mnt/ir/sda.img bs=4M status=progress conv=noerror,sync
sha256sum /dev/sda | tee /mnt/ir/sda.quelle.sha256
sha256sum /mnt/ir/sda.img | tee /mnt/ir/sda.img.sha256

# Auswertung immer auf einer Kopie, schreibgeschützt eingehängt
mmls /mnt/ir/sda.img                       # Offset der Partition ermitteln
sudo mount -o ro,noload,noexec,nodev,loop,offset=$((2048*512)) \
     /mnt/ir/sda.img /mnt/analyse

Beide Hashes müssen identisch sein, sonst hat die Kopie einen Lesefehler verschluckt. Bei laufenden virtuellen Maschinen ist ein Snapshot inklusive Arbeitsspeicher der sauberere Weg, weil das Dateisystem dabei konsistent bleibt.

04

Timeline bauen statt Dateien anstarren

Einzelne verdächtige Dateien erklären nichts. Erst die zeitliche Abfolge zeigt Einstiegspunkt, Ausbreitung und Zeitraum.

Schnelle Vorabsicht und vollständige Timeline
# Schnell: was wurde seit dem Verdachtszeitpunkt geändert?
find / -xdev -newerct '2026-07-20 00:00:00' \
     -printf '%TY-%Tm-%Td %TH:%TM  %p\n' 2>/dev/null | sort

# Vollständig: aus dem Abbild, nicht vom laufenden System
mmls /mnt/ir/sda.img
fls -r -m / -o 2048 /mnt/ir/sda.img > /mnt/ir/bodyfile
mactime -b /mnt/ir/bodyfile -d -z Europe/Berlin > /mnt/ir/timeline.csv

-newerct vergleicht die Inode-Änderungszeit. Die kann ein Angreifer nicht frei setzen: touch -d ändert Zugriffs- und Änderungszeit, die ctime springt trotzdem auf den Zeitpunkt der Manipulation. Dateien mit alter mtime und frischer ctime sind deshalb der beste Startpunkt für die ganze Untersuchung.

Logs korrelieren, Lücken erkennen
# Journal aus dem Abbild lesen, ohne das Live-System zu befragen
journalctl -D /mnt/analyse/var/log/journal -o short-iso-precise

# Erfolgreiche Anmeldungen: Pfad je nach Distribution
grep -aE 'Accepted (password|publickey)' /mnt/analyse/var/log/auth.log*   # Debian/Ubuntu
grep -a 'Accepted' /mnt/analyse/var/log/secure*                          # RHEL/Rocky/Alma

# Gelöschte Sitzungen hinterlassen Sprünge in der Reihenfolge
utmpdump /mnt/analyse/var/log/wtmp | head -40

Achte weniger auf einzelne Einträge als auf Lücken und Sprünge. Ein sauber geleertes Log ist verdächtiger als ein volles. Zeigt utmpdump Zeitstempel, die nicht monoton laufen, wurde in wtmp gelöscht. Prüf parallel, ob die Logrotation dazu passt: ein auth.log.1 ohne den zugehörigen Rotationseintrag ist ein Befund.

05

Persistenz systematisch abklopfen

Wer einmal drin war, kommt wieder rein. Diese Orte gehst du der Reihe nach durch, statt zu raten.

Die üblichen Startpunkte
systemctl list-unit-files --state=enabled
systemctl list-timers --all
ls -la /etc/systemd/system /run/systemd/system /home/*/.config/systemd/user
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron /var/spool/cron/crontabs
atq

cat /etc/ld.so.preload 2>/dev/null       # existiert im Normalfall gar nicht
awk -F: '$3==0 {print $1}' /etc/passwd   # mehr als root ist ein Befund
grep -rn '' /etc/sudoers.d/
ls -la /root/.ssh /home/*/.ssh; cat /home/*/.ssh/authorized_keys
ls -la /etc/update-motd.d /etc/profile.d

Vergiss die Benutzerebene nicht: ein systemd-Timer unter ~/.config/systemd/user mit aktiviertem Lingering läuft auch ohne angemeldete Sitzung und taucht in der systemweiten Übersicht nicht auf. Prüf das mit loginctl show-user <name> -p Linger.

Veränderte Systemdateien über die Paketverwaltung finden
# RHEL/Rocky/Alma: Prüfsummen gegen die Paketdatenbank
rpm -Va | grep -E '^..5' | grep -E '/(bin|sbin|lib)'

# Debian/Ubuntu
sudo debsums -c 2>/dev/null || sudo dpkg --verify

# Besser: gegen das Abbild von einem sauberen System aus prüfen
sudo rpm --root=/mnt/analyse -Va | grep -E '^..5'

Beide Prüfungen befragen eine Datenbank, die auf demselben System liegt. Wer Root-Rechte hatte, konnte sie mit verändern. Aussagekräftig wird der Abgleich erst gegen das eingehängte Abbild von außen, im Zweifel gegen frisch heruntergeladene Pakete aus der Distributionsquelle. Und: Dateien, die zu keinem Paket gehören, tauchen hier gar nicht auf.

06

Neu aufbauen, Zugänge rotieren, Fristen einhalten

Der Wiederaufbau läuft parallel zur Analyse, nicht danach. Die Meldefristen laufen ab dem Zeitpunkt der Kenntnis, nicht ab dem Abschlussbericht.

Reihenfolge beim Wiederaufbau

  • Alles rotieren, was das System kannteSSH-Hostschlüssel und Benutzerschlüssel, Dienstkonten, API-Token, Datenbankpasswörter, Backup-Zugangsdaten und jedes Zertifikat mit privatem Schlüssel auf dem System. Ein Passwortwechsel allein ist wertlos, solange ein hinterlegter öffentlicher Schlüssel in authorized_keys weiter gilt.
  • Backups vor dem Einspielen datierenLag der Erstzugriff vor der letzten Vollsicherung, spielst du die Hintertür zurück. Die Timeline liefert dir das Datum, ab dem du Sicherungen nicht mehr blind vertrauen darfst.
  • Das Ersatzsystem zuerst in ein getrenntes Netzsegment stellenSolange der Einstiegsweg unbekannt ist, holt dich derselbe Weg im neuen System innerhalb von Tagen wieder ein. Erst prüfen, dann freigeben.
  • Meldefristen am ersten Tag klärenBei betroffenen personenbezogenen Daten laufen nach Artikel 33 DSGVO 72 Stunden ab Kenntnis für die Meldung an die Aufsichtsbehörde. Für Einrichtungen im Anwendungsbereich von NIS2 kommt eine Erstmeldung innerhalb von 24 Stunden dazu, danach eine ausführlichere Meldung nach 72 Stunden und ein Abschlussbericht. Diese Uhren laufen, während du noch analysierst.
  • Erkennung nachrüsten, bevor das System freigegeben wirdauditd-Regeln, Dateiintegritätsprüfung und vor allem eine Logablage außerhalb des Systems. Ohne diesen Schritt findest du den nächsten Vorfall genauso spät wie diesen, nämlich wenn er von außen gemeldet wird.
Logs sofort außer Haus schreiben
sudo tee /etc/rsyslog.d/90-remote.conf >/dev/null <<'EOF'
*.* action(type="omfwd" target="logserver.intern" port="6514"
           protocol="tcp" queue.type="linkedlist" queue.saveOnShutdown="on"
           action.resumeRetryCount="-1")
EOF
sudo systemctl restart rsyslog

# Systemd-Journal zusätzlich dauerhaft ablegen
sudo mkdir -p /var/log/journal && sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Die Warteschlange mit saveOnShutdown und unbegrenzten Wiederholungen sorgt dafür, dass Meldungen bei einem Ausfall des Logservers nicht verloren gehen. Der entscheidende Punkt ist aber die Richtung: Logs, die nur lokal liegen, kann jeder löschen, der Root-Rechte erlangt. Auf dem zentralen Server ist die Kopie bereits geschrieben, bevor der Angriff sie erreicht.

Gut zu wissen

Häufige Fragen zu Incident Response unter Linux

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Darf ich den gehackten Server neu starten?
Nur wenn du bewusst auf die flüchtigen Daten verzichten willst. Mit dem Reboot verlierst du den Arbeitsspeicher, laufende Prozesse, offene Verbindungen und alle Payloads, die nie auf die Platte geschrieben wurden. Trenne den Server stattdessen auf Netzwerkebene, sichere den RAM und fahre ihn erst danach kontrolliert herunter.
Wie erkenne ich ein Rootkit auf einem Linux-System?
Auf dem laufenden und möglicherweise manipulierten System sind Werkzeuge wie chkrootkit oder rkhunter nur ein erster Hinweis, weil ein Kernel-Rootkit ihre Sicht auf das System verfälschen kann. Belastbar wird die Analyse durch den Abgleich gegen die Paketdatenbank, den Vergleich der Prozessliste mit den Einträgen unter /proc, die Prüfung geladener Kernel-Module und vor allem durch die Offline-Untersuchung von Datenträger-Image und Speicherabbild, etwa mit Volatility.
Woran sehe ich, dass Logfiles manipuliert wurden?
Typische Indikatoren sind Lücken in fortlaufenden Zeitreihen, Einträge mit unpassenden Zeitstempeln, unerwartet zurückgesetzte Dateigrößen sowie wtmp- oder btmp-Dateien, deren Inhalt nicht zu den journald-Daten passt. Sicher belegen lässt sich eine Manipulation aber erst im Abgleich mit Quellen außerhalb des Systems, etwa einem zentralen Log-Empfänger, Firewall-Logs oder den Zugriffsdaten des vorgelagerten Proxy.
Muss ich einen Sicherheitsvorfall melden?
Sind personenbezogene Daten betroffen, gilt in der Regel die Meldepflicht nach Artikel 33 DSGVO mit einer Frist von 72 Stunden gegenüber der zuständigen Aufsichtsbehörde. Zusätzlich können sektorspezifische Pflichten greifen, etwa für Einrichtungen im Anwendungsbereich der NIS2-Umsetzung, wo eine erste Meldung deutlich früher fällig wird. Kläre die Einstufung deines Unternehmens am besten vor dem Ernstfall und halte die Meldewege schriftlich fest.
Lohnt es sich, einen kompromittierten Server zu bereinigen?
In der Praxis nur selten. Sobald ein Angreifer Root-Rechte hatte, kannst du mit vertretbarem Aufwand nicht mehr belegen, dass du jeden Persistenzmechanismus gefunden hast. Der übliche Weg ist ein Neuaufbau aus einer vertrauenswürdigen Quelle, während das Image des alten Systems für die Analyse erhalten bleibt.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Forensik einmal durchspielen, bevor der Ernstfall kommt

Im Seminar Digitale Forensik für Linux und Unix Systeme arbeitest du genau diese Kette komplett durch, von der Sicherung flüchtiger Daten über Images und Timelines bis zur Auswertung von Persistenzmechanismen. Wenn du lieber vorher an der Abwehr ansetzen willst, passen der Linux Security Intensivkurs für Härtung und Zugriffskontrolle sowie das Linux Troubleshooting Training für die schnelle Analyse auffälliger Systeme. Alle Kurse gibt es als Präsenztermin und Live-Online, und wenn du unsicher bist, welcher Einstieg für dein Team der richtige ist, sprich uns einfach an.