Zwischenfall und Spurensicherung

Ein Host verhält sich auffällig, und zwei vernünftige Reflexe setzen gleichzeitig ein: den Dienst zurückholen und herausfinden, was passiert ist. Sie widersprechen sich, weil fast jede Wiederherstellung Spuren zerstört — ein Neustart löscht in einer Sekunde alles, was gerade lief, wohin es verbunden war und unter welchem Konto. Dieses Modul zeigt dir, in welcher Reihenfolge Beweise verschwinden, wie du eindämmst ohne auszuschalten, was die drei Zeitstempel einer Datei wirklich sagen, warum die Protokolle des betroffenen Hosts allein nichts beweisen — und wann Aufräumen nicht mehr genügt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-03

Zwei berechtigte Ziele, die sich widersprechen

Ein Host verhält sich auffällig. Zwei Reflexe setzen sofort ein, und beide sind vernünftig: den Dienst wieder zum Laufen bringen, und herausfinden, was passiert ist. Sie widersprechen sich, weil fast jede Maßnahme zur Wiederherstellung Spuren zerstört — ein Neustart, ein Neuaufsetzen des Dienstes, ein „ich habe mal aufgeräumt“.

Der Fehler ist nicht, sich für eines der beiden zu entscheiden. Der Fehler ist, es nicht ausdrücklich zu tun. Wer neu startet, weil der Dienst wichtig ist, trifft eine legitime Abwägung. Wer neu startet, ohne die Frage gestellt zu haben, hat dieselbe Wirkung erzeugt und weiß hinterher nicht, was er verloren hat.

Deshalb steht am Anfang eine Entscheidung, die jemand trifft und die jemand aufschreibt: Sichern wir zuerst, oder stellen wir zuerst wieder her? Bei einem Ausfall ohne Anzeichen für einen Eingriff ist die zweite Antwort meist richtig. Bei Verdacht auf einen fremden Zugriff kostet eine Viertelstunde Sicherung wenig — und ihr Fehlen kann die ganze Aufklärung unmöglich machen.

Vorher festlegenDiese Entscheidung im Zwischenfall zu treffen, ist schwer und ungern getroffen. Deshalb gehört sie vorher geklärt: Ab welchen Anzeichen wird gesichert, wer darf das entscheiden, und wer wird informiert? Ein Team, das das im Ruhezustand geklärt hat, verliert im Ernstfall keine Zeit mit der Frage.

Beweise verschwinden in einer festen Reihenfolge

Nicht alle Spuren sind gleich haltbar. Manche sind nach dem nächsten Tastendruck weg, andere überstehen Wochen. Wer sichert, arbeitet die flüchtigsten zuerst ab — sonst sichert er in Ruhe das Haltbare und verliert dabei das Wichtige.

Sekunden: Inhalt des Arbeitsspeichers, laufende Prozesse und ihre offenen Dateien, bestehende Netzverbindungen, entschlüsselte Daten im Speicher
Minuten: Zwischenspeicher für Namensauflösung und Verbindungstabellen, Sitzungen und angemeldete Konten, Inhalt temporärer Verzeichnisse
Stunden bis Tage: Protokolle auf dem Host, Zeitstempel im Dateisystem, Verlaufsdateien der Shell, Zwischenstände von Diensten
Dauerhaft: Zentral gesammelte Protokolle, Aufzeichnungen aus dem Netz, Sicherungen, Abbilder

Daraus folgt der wichtigste einzelne Ratschlag zum Umgang mit einem verdächtigen Host: nicht ausschalten. Ein Ausschalten vernichtet die gesamte erste Zeile in einem Zug — und dort steht typischerweise, was gerade läuft, wohin es verbunden ist und unter welchem Konto.

Was stattdessen geht: den Host aus dem Netzverkehr nehmen, aber laufen lassen. Aus der Verteilung herausnehmen, den Zugang über eine getrennte Verwaltungsschnittstelle behalten, ausgehende Verbindungen sperren. Der Dienst ist damit entlastet, der Zustand bleibt lesbar.

Die erste Zeile der Tabelle lässt sich mit wenigen Befehlen festhalten, und die Ausgabe gehört sofort weg vom Host — auf ein anderes System oder wenigstens in die mitgeschriebene Sitzung:

ss -tunap — bestehende Verbindungen samt Gegenstelle und zugehörigem Prozess
ps -eo pid,ppid,user,lstart,args — alle Prozesse mit Startzeit und vollständiger Befehlszeile
lsof -p <pid> — welche Dateien und Sockel dieser Prozess offen hält
ls -l /proc/<pid>/exe — welche Programmdatei tatsächlich läuft

Nützlicher SonderfallDer letzte Punkt rettet regelmäßig den wichtigsten Fund. Der Verweis unter /proc/<pid>/exe zeigt laut Dokumentation auf die ausgeführte Programmdatei und lässt sich normal öffnen — auch dann, wenn die Datei bereits gelöscht wurde. Der Pfad trägt dann den Zusatz (deleted), und über den Verweis lässt sich das laufende Programm trotzdem noch herauskopieren. Nach einem Neustart ist es endgültig fort.

Jeder Handgriff ist selbst eine Veränderung

Sobald du dich anmeldest, verändert sich der Host: eine neue Sitzung im Protokoll, ein neuer Prozess, veränderte Zeitstempel an den Dateien, die du liest, Einträge in deiner eigenen Verlaufsdatei. Das ist unvermeidbar und kein Problem — solange es nachvollziehbar ist.

Unbrauchbar wird eine Untersuchung erst, wenn sich hinterher nicht mehr trennen lässt, welche Spur vom Vorfall stammt und welche von der Untersuchung. Deshalb wird während der Arbeit mitgeschrieben, und zwar in einer Form, die man später einer Zeit zuordnen kann:

Welcher Befehl, auf welchem Host, unter welchem Konto, zu welcher Zeit
Was das Ergebnis war — vollständig, nicht zusammengefasst
Welche Datei kopiert oder verändert wurde, und wohin
Wer die Entscheidung getroffen hat, etwas zu verändern

PraktischEine Sitzungsaufzeichnung nimmt das ab: script --timing schreibt Ein- und Ausgabe der Sitzung mitsamt Zeitstempeln in eine Datei, die außerhalb des betroffenen Hosts liegen sollte. Das kostet einen Befehl am Anfang und ersetzt das nachträgliche Erinnern.

Kopieren, bevor man hineinschaut

Untersucht wird an einer Kopie, nicht am Original — auch dann, wenn man nur lesen will. Der Grund ist weniger die Angst vor dem eigenen Tippfehler als die Nachweisbarkeit: An einer Kopie, deren Prüfsumme festgehalten ist, lässt sich zeigen, dass die untersuchten Daten dieselben sind wie die gesicherten.

Der Ablauf ist kurz: Daten wegkopieren, Prüfsumme mit sha256sum bilden, Prüfsumme getrennt von den Daten notieren. Vor der Auswertung erneut prüfen. Stimmen die Werte überein, ist belegt, dass sich zwischen Sicherung und Auswertung nichts verändert hat.

Der Preis ist Platz und Zeit: Ein Abbild belegt so viel Speicher wie das Original, und das Kopieren eines großen Dateisystems dauert. Deshalb ist der übliche Kompromiss eine gezielte Auswahl — Protokolle, Konfiguration, verdächtige Dateien, eine Liste laufender Prozesse — statt eines vollständigen Abbilds. Wer sich dafür entscheidet, sollte wissen, dass er damit auf gelöschte Daten verzichtet, die nur im Abbild noch stünden.

Für Systemdateien gibt es eine zweite Vergleichsgröße, die nichts kostet: Der Paketverwalter kennt zu jeder installierten Datei ihre erwartete Prüfsumme. rpm -Va beziehungsweise debsums -c melden jede Abweichung. Das findet ausgetauschte Systemprogramme in Minuten — und übersieht alles, was nie aus einem Paket kam.

Grenze derselben PrüfungDie Datenbank des Paketverwalters liegt auf demselben Host. Wer dort schreiben durfte, konnte auch sie anpassen. Ein unauffälliger Befund ist deshalb ein Hinweis und kein Freispruch; belastbar wird der Vergleich erst gegen eine Quelle außerhalb — die Paketdateien aus dem Spiegel oder ein identisch installiertes System.

Drei Zeitstempel, drei verschiedene Aussagen

Jede Datei trägt drei Zeitangaben, und sie werden regelmäßig verwechselt. stat zeigt alle drei nebeneinander.

mtime: Letzte Änderung des Inhalts. Ändert sich laut Dokumentation nicht bei Änderungen an Eigentümer, Gruppe, Rechten oder Verweiszahl.
ctime: Letzte Änderung der Verwaltungsdaten: also beim Schreiben und ebenso beim Setzen von Eigentümer, Gruppe, Verweiszahl oder Rechten.
atime: Letzter Zugriff. Wird laut Dokumentation je nach Einhängeoption gar nicht oder nur eingeschränkt fortgeschrieben.

Aus dem Zusammenspiel der ersten beiden ergibt sich ein nützlicher Hinweis. Die Inhaltszeit einer Datei lässt sich mit Bordmitteln auf einen beliebigen Wert setzen — auch in die Vergangenheit. Das Setzen selbst ist aber eine Änderung der Verwaltungsdaten und schreibt deren Zeitstempel auf jetzt fort.

Die Datei, deren zwei Zeiten nicht zusammenpassen

Szenario

In /usr/local/bin liegt ein Programm, das dort niemand erwartet. stat zeigt für den Inhalt einen Zeitpunkt vor zwei Jahren.

Anforderungen

Verwaltungszeit laut stat: vorgestern, 02:14 Uhr
Die übrigen Dateien im Verzeichnis stammen aus der Paketinstallation

Schritte

Zwei Jahre alter Inhalt bei vorgestern geänderten Verwaltungsdaten ist erklärungsbedürftig.
Harmlose Erklärungen gibt es: eine Rechteänderung, ein Verschieben, ein Wiederherstellen aus einer Sicherung.
Alle drei hinterlassen aber weitere Spuren — im Protokoll, im Paketverwalter, im Auftrag der Wiederherstellung.
Findet sich keine davon, bleibt die Erklärung, dass jemand die Inhaltszeit nachträglich zurückgesetzt hat.

Merksatz: Die Verwaltungszeit ist der Zeitstempel, den man nicht nebenbei mitsetzt. Der Widerspruch zwischen beiden ist deshalb ein Anfangsverdacht — er ist kein Beweis und verdient eine Frage.

GrenzeDie Zugriffszeit ist als Nachweis dafür, wann eine Datei zuletzt gelesen wurde, auf den meisten Systemen unbrauchbar: Verbreitete Einhängeoptionen schreiben sie nur eingeschränkt oder gar nicht fort, um Schreibzugriffe zu sparen. Wer daraus schließt, eine Datei sei „seit Monaten nicht gelesen worden“, schließt aus einer nicht geführten Aufzeichnung.

Eine Zeitachse aus mehreren Quellen

Der Kern fast jeder Aufklärung ist eine Zeitachse: Was ist wann passiert, und in welcher Reihenfolge? Sie entsteht aus Quellen, die getrennt voneinander geführt werden — Protokolle des Hosts, Aufzeichnungen aus dem Netz, Anmeldungen, Änderungen an der Konfiguration, Einträge aus dem Ticketsystem.

Damit sie sich überhaupt zusammenführen lassen, brauchen sie eine gemeinsame Zeitbasis. Deshalb ist die erste Prüfung an jeder Quelle, in welcher Zeitzone ihre Zeitstempel stehen und ob die Uhr des Hosts synchronisiert war. Eine Abweichung von einer Stunde erzeugt sonst eine Reihenfolge, die es nie gegeben hat — und aus dieser falschen Reihenfolge folgt eine falsche Ursache.

Wo sich Ereignisse zeitlich nahekommen, ist die Reihenfolge wichtiger als der genaue Zeitpunkt. Startete der auffällige Prozess vor oder nach der Anmeldung? Kam die ausgehende Verbindung vor oder nach dem Schreiben der Datei? Diese Fragen entscheiden über die Erzählung, und sie lassen sich nur beantworten, wenn die Uhren gestimmt haben.

Für den Aufbau selbst genügen zwei Werkzeuge. journalctl --since und --until grenzen den Protokollbestand auf das Fenster ein. Und find / -newerct '2 days ago' listet alle Dateien, deren Verwaltungsdaten sich seit einem Zeitpunkt geändert haben — das ist die Sicht auf das Dateisystem, die zur Zeitachse passt, weil dieser Zeitstempel sich nicht nebenbei setzen lässt.

Die Protokolle des betroffenen Hosts allein beweisen nichts

Ein Protokoll auf dem Host ist eine Datei, und wer auf dem Host ausreichende Rechte hat, kann Dateien ändern. Bei einem Ausfall ist das ohne Belang — niemand fälscht Protokolle, um einen vollen Datenträger zu verbergen. Bei einem Verdacht auf fremden Zugriff kehrt sich die Beweislage um: Genau die Quelle, die man befragen möchte, steht unter der Kontrolle dessen, den man untersucht.

Deshalb ist die entscheidende Vorbereitung nicht mehr Protokollierung, sondern eine zweite Kopie außerhalb. Werden Einträge fortlaufend an ein zentrales Ziel übertragen, ist ein nachträgliches Löschen auf dem Host nur noch teilweise wirksam — und die Lücke zwischen beiden Beständen wird selbst zum Befund.

Kurzcheck

Auf einem Host mit Verdacht auf fremden Zugriff fehlen die Protokolleinträge für einen Zeitraum von drei Stunden vollständig. Was folgt daraus?

Die Lücke ist selbst ein Befund und muss gegen eine unabhängige Quelle geprüft werden
In diesem Zeitraum ist nichts protokollwürdiges geschehen, sonst stünde etwas darin
Die Protokolle wurden manipuliert, denn eine vollständige Lücke von drei Stunden hat keine harmlose Erklärung

Treffer. Richtig. Sie kann von einem gelöschten Bereich stammen, von einem angehaltenen Dienst oder von einem vollen Datenträger. Welche Erklärung zutrifft, entscheidet nur eine Quelle außerhalb des Hosts — die zentrale Sammlung oder Aufzeichnungen aus dem Netz.

Eindämmen, ohne zu vernichten

Eindämmung soll den Schaden begrenzen, nicht das System beseitigen. Zwischen „nichts tun“ und „ausschalten“ liegen mehrere Stufen, und sie unterscheiden sich stark darin, was sie an Spuren übrig lassen.

Aus der Verteilung nehmen: Kein Nutzerverkehr mehr, Zustand bleibt vollständig erhalten. Fast immer der erste Schritt.
Ausgehende Verbindungen sperren: Unterbindet Nachladen und Abfluss von Daten, ohne den Host anzuhalten. Sichtbar für den Gegenüber.
Konto sperren, Sitzung beenden: Wirkt gezielt und beendet dabei Prozesse, deren Zustand man vielleicht noch gebraucht hätte.
Ausschalten: Beendet alles sofort und vernichtet den gesamten flüchtigen Zustand. Letzte Stufe, nicht erste.

Jede dieser Stufen ist auch eine Nachricht an den Gegenüber, falls tatsächlich jemand aktiv ist: Wer bemerkt, dass er entdeckt wurde, verwischt Spuren oder beschleunigt seinen Abfluss. Das ist ein Argument für Zurückhaltung und keines fürs Zuwarten — der Schaden durch verzögerte Eindämmung wächst schneller als der Erkenntnisgewinn.

Wann Aufräumen nicht mehr genügt

Nach einem Zwischenfall mit fremdem Zugriff steht die unangenehmste Frage an: Reicht es, das Gefundene zu entfernen? Die ehrliche Antwort lautet fast immer nein, und zwar aus einem grundsätzlichen Grund. Man kann die Anwesenheit einer Hintertür belegen, aber ihre Abwesenheit nicht — hat jemand mit weitreichenden Rechten auf dem System gearbeitet, prüft man mit Werkzeugen, die ebenfalls unter seiner Kontrolle standen.

Der tragfähige Weg ist deshalb der Neuaufbau aus einer Quelle, die nicht betroffen war: frisch installiertes System, Konfiguration aus der Versionsverwaltung, Daten aus einer Sicherung von vor dem frühesten belegten Zeitpunkt des Zugriffs, alle Zugangsdaten des Hosts erneuert.

Das ist teuer, und die Versuchung, stattdessen zu bereinigen, ist entsprechend groß. Der Preis des Neuaufbaus ist Zeit und Ausfall; der Preis des Bereinigens ist ein System, dem man nicht mehr begründet vertrauen kann — und ein zweiter Zwischenfall, dessen Zusammenhang mit dem ersten dann niemand mehr nachweisen kann.

Die Frage davorDer früheste belegte Zeitpunkt entscheidet, welche Sicherung noch verwendbar ist. Deshalb ist die Zeitachse nicht nur Aufklärung, sondern eine Voraussetzung der Wiederherstellung: Ohne sie weiß niemand, ab wann die Sicherungen ebenfalls verdächtig sind.

Wiederanlauf mit Bedingungen

Ein Dienst kommt zurück, wenn benannte Bedingungen erfüllt sind — nicht, wenn er wieder startet. Der Unterschied entscheidet darüber, ob derselbe Zwischenfall in der nächsten Woche wiederkommt.

Der Weg hinein ist geschlossen, und es ist benannt, welcher Weg das war
Alle Zugangsdaten, die auf dem Host lagen, sind erneuert — auch die, die nicht benutzt aussahen
Es gibt eine Beobachtung, die anschlagen würde, wenn dasselbe noch einmal passiert
Der Zeitpunkt des frühesten Zugriffs ist belegt, und die verwendete Sicherung liegt davor

Der zweite Punkt wird am häufigsten abgekürzt, weil er Arbeit an anderen Systemen erzeugt. Er ist trotzdem nicht verhandelbar: Ein Zugangsdatum, das auf einem betroffenen Host lag, muss als bekannt gelten, unabhängig davon, ob man seine Verwendung nachweisen kann.

Was nach dem Zwischenfall bleibt

Die Nachbetrachtung hat einen Zweck, und der ist nicht die Feststellung, wer den Fehler gemacht hat. Sie fragt, welche Eigenschaft des Systems den Vorfall möglich oder seine Erkennung schwer gemacht hat — und was daran sich ändern lässt.

Brauchbare Ergebnisse sind konkret und überprüfbar: eine Protokollquelle, die es künftig zentral gibt; eine Berechtigung, die enger wird; eine Beobachtung, die vorher gefehlt hat; eine Entscheidung, die vorab festgelegt wird statt im Zwischenfall. Unbrauchbar sind Ergebnisse der Form „künftig sorgfältiger arbeiten“ — sie beschreiben keine Änderung, die jemand umsetzen kann.

Die Reihenfolge im Ernstfall

Entscheiden und festhalten: erst sichern oder erst wiederherstellen→Eindämmen ohne auszuschalten — aus der Verteilung nehmen, Abfluss sperren→Flüchtiges zuerst sichern: Prozesse, Verbindungen, offene Dateien→Kopieren, Prüfsumme bilden, an der Kopie arbeiten→Zeitachse aus mehreren Quellen bauen — Uhren zuerst prüfen→Über Neuaufbau entscheiden, Zugangsdaten erneuern, Wiederanlauf an Bedingungen knüpfen

Diese Reihenfolge ist im Ernstfall schwer einzuhalten, weil der Druck in die Gegenrichtung wirkt: Alle wollen den Dienst zurück. Genau deshalb steht sie geschrieben, bevor sie gebraucht wird — im Zwischenfall wird sie befolgt, nicht erfunden.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität12 Primärquellen · zuletzt geprüft: 2026-09-03