Manipulation von Linux-Logs erkennen: Lücken, Nullen, Stopps

Kurzfassung. Root kann auf einem Linux-Host jedes einzelne Log bearbeiten. Was einem Eindringling selten gelingt, ist, alle konsistent zu bearbeiten. Manipulation zeigt sich als Widerspruch zwischen Quellen (eine Zeile im Journal, aber nicht in auth.log, eine Sitzung in audit.log, aber nicht in wtmp, eine lastlog-Zeit ohne wtmp-Eintrag) und als strukturelle Schäden (Sequenznummernlücken, genullte Einträge, abgeschnittene Dateien, gestoppte Daemons). Schließen Sie die harmlosen Ursachen aus und berichten Sie dann, was jede Quelle aussagt.

1. Lücken in den Journal-Sequenznummern

Jeder Journal-Eintrag trägt eine Sequenznummer aus einem Zähler, den alle Journal-Dateien des Systems teilen. Wird eine ganze Journal-Datei gelöscht oder eine Datei ohne bestimmte Einträge neu geschrieben, bleibt ein Nummernbereich übrig, den kein gesicherter Eintrag belegt.

Zuerst auszuschließende harmlose Erklärungen:

user-<UID>.journal-Dateien, die nicht gesichert wurden (ihre Einträge nutzen denselben Zähler).
Archivierte Dateien, die durch die Aufbewahrungsregeln per Vacuum entfernt wurden (die Lücke liegt am Anfang des Bereichs).
Eine Sicherung, die erstellt wurde, während journald schrieb (die Lücke liegt ganz am Ende).

Eine Lücke mitten im Vorfallszeitraum bei vorhandenen Benutzer-Journalen oder eine, die mit einem rm einer Journal-Datei in audit.log oder in einer sudo-Zeile zusammenfällt, ist ein Befund. Auch der Journal-Header hilft: head_entry_seqnum und tail_entry_seqnum geben an, welchen Bereich eine Datei enthalten sollte. Siehe Journal-Forensik.

2. Auth-Zeilen im Journal, die in auth.log fehlen

Auf den meisten systemd-Hosts erhält rsyslog seine Zeilen von journald. Dieselbe sshd-, sudo- oder PAM-Meldung existiert daher an beiden Stellen. Enthält das Journal Accepted password for X from IP und auth.log, das diesen Zeitraum abdeckt, nicht, wurde die Textdatei bearbeitet (typischerweise mit sed -i oder einem Log-Cleaner, der nur Textdateien kennt).

Prüfen Sie zuerst die Abdeckung: Die Zeile muss zwischen der ersten und letzten Zeile der vorhandenen auth.log-Generationen liegen, und rsyslog muss gelaufen sein (Start und Stopp stehen im Journal). Der umgekehrte Fall, eine Zeile in auth.log, aber nicht im Journal, bedeutet meist, dass das Journal diesen Zeitraum nicht aufbewahrt hat.

wtmp-Cleaner überschreiben einen Eintrag mit Nullen, damit die Dateigröße ausgerichtet bleibt. Anzeichen:

Einträge, die vollständig aus Nullen bestehen (Typ 0, kein Benutzer, Datum 1970 in utmpdump),
eine Dateigröße, die kein Vielfaches der Eintragsgröße ist (384 Bytes auf x86_64, 400 auf aarch64),
Zeitstempel, die zwischen aufeinanderfolgenden Einträgen rückwärts laufen,
eine wtmp oder btmp mit null Bytes und alter Änderungszeit auf einem Server in Betrieb.

Gleichen Sie dann ab: eine interaktive SSH-Sitzung, die auth.log, Journal und audit.log alle zeigen, wtmp aber nicht, obwohl wtmp diese Zeit abdeckt; oder ein lastlog-Eintrag (der letzte Login einer UID), der neuer ist als jede wtmp-Sitzung dieses Benutzers. Denken Sie daran, dass nicht interaktives SSH (Befehle, scp, sftp) oft überhaupt keinen wtmp-Eintrag hat. Details im wtmp-Leitfaden.

4. Protokollierung gestoppt oder umkonfiguriert

Achten Sie auf:

rsyslog.service, systemd-journald.service oder auditd.service, die außerhalb eines Neustarts oder Paket-Upgrades stoppen,
interaktiv ausgeführte journalctl --vacuum-time, --vacuum-size, --rotate,
Audit-Einträge CONFIG_CHANGE, auditctl -D (alle Regeln löschen) oder auditctl -e 0 (deaktivieren),
Änderungen an /etc/rsyslog.conf, /etc/rsyslog.d/, journald.conf (Storage=none, volatile) oder /etc/audit/rules.d/,
ein Textlog, das mitten am Tag endet, während das Journal weiterläuft: Dann liegt das Problem beim Syslog-Daemon.

Auch Neustarts und Upgrades stoppen Dienste; lesen Sie, was jedes Ereignis umgibt.

5. Befehle, die Logs und Verlauf löschen

audit.log (mit einer execve-Regel), sudo-Zeilen und das Journal können das Löschen selbst erfassen:

rm, shred, truncate oder > file gegen /var/log/*, Journal-Dateien oder /var/log/wtmp,
Skripte, die mit einem Log-Pfad als Argument laufen, etwa ein Python-Skript, dem /var/log/wtmp und ein Benutzername übergeben werden,
ln -sf /dev/null ~/.bash_history, unset HISTFILE, export HISTSIZE=0, history -c (Builtins und Variablenänderungen hinterlassen keinen execve-Eintrag; das ln schon),
journalctl --vacuum-*, utmpdump -r, um wtmp aus bearbeitetem Text neu zu schreiben.

logrotate löscht alte Dateien planmäßig als root aus cron; ein interaktiver Befehl aus einer Benutzersitzung ist etwas anderes.

6. Manipulation der Uhrzeit

Eine zurückgestellte Uhr lässt Ereignisse älter aussehen. Im Journal verrät es sich dadurch, dass Realtime sinkt, während die Sequenznummern steigen; Meldungen von systemd-timesyncd oder NTP und Einträge zu Uhrzeitänderungen helfen. In wtmp sind rückwärts laufende Einträge das Gegenstück.

Der Bericht

Geben Sie für jeden Indikator an, was die Beweislage zeigt und was ihn sonst erklären könnte. „Zwischen 10:02 und 10:50 fehlen Journal-Sequenznummern; es wurde keine user-1001.journal gefunden; eine sudo-Zeile um 10:44:10 zeigt rm -f auf diese Datei“ ist ein Befund. „Logs wurden gelöscht“ ist eine Schlussfolgerung, zu der der Leser daraus selbst gelangen können sollte.

Im Browser

Linux Log Parser prüft diese Punkte automatisch: Journal-Sequenzlücken (mit einer Warnung, wenn kein Benutzer-Journal geladen wurde), Auth-Zeilen im Journal, die in auth.log fehlen, geleerte, unvollständige und rückwärts laufende wtmp-Einträge, gestoppte Logging-Daemons, Journal-Vacuums und Änderungen an Audit-Regeln, Befehle zum Löschen von Logs sowie interaktive Logins ohne wtmp-Eintrag. Jeder Befund listet die Ereignisse auf, auf denen er beruht. Die Beispielermittlung zeigt drei davon an einem Eindringen, und der auth.log-Spickzettel listet weitere Manipulationsanzeichen pro Quelle auf.