Linux-Log-Forensik: auth.log, Journal, auditd und wtmp

Kurzfassung. Ein Linux-Host zeichnet dasselbe Eindringen an bis zu vier voneinander unabhängigen Stellen auf: in den von rsyslog geschriebenen Textlogs (auth.log, secure, syslog, messages), im binären systemd-Journal, im von auditd geschriebenen Audit-Log und in den binären Login-Einträgen (wtmp, btmp, utmp, lastlog oder ihren SQLite-Nachfolgern). Jede Quelle beantwortet eine andere Frage, jede kann aus harmlosen Gründen fehlen, und ein Angreifer bereinigt selten alle vier. Die Ermittlung besteht im Vergleich.

Vier Quellen, vier Fragen

Quelle	Dateien	Beantwortet	Blinder Fleck
Textlogs	`/var/log/auth.log`, `syslog` (Debian, Ubuntu); `/var/log/secure`, `messages` (RHEL-Familie)	Wer sich von wo mit welcher Methode authentifiziert hat; sudo-Befehlszeilen; Kontoänderungen	Lokale Zeit, teils ohne Jahr; Programmname wird nicht geprüft
systemd-Journal	`/var/log/journal/<machine-id>/*.journal`	Dieselben Meldungen plus vertrauenswürdige `_PID`, `_UID`, `_EXE`, `_SYSTEMD_UNIT`, UTC-Zeiten in Mikrosekunden, Boot-IDs	Binär, größenbasierte Aufbewahrung, eventuell nur flüchtig
auditd	`/var/log/audit/audit.log`	PAM-Logins und -Sitzungen sowie jedes ausgeführte Programm, sofern eine execve-Regel existiert, verknüpft mit dem Login-Benutzer (`auid`)	Nur, was die Regeln abdecken; unter Debian und Ubuntu nicht standardmäßig installiert
Login-Einträge	`/var/log/wtmp`, `btmp`, `lastlog`, `/run/utmp`, `wtmp.db`, `lastlog2.db`	Interaktive Sitzungen mit Beginn und Ende, fehlgeschlagene Logins, letzter Login pro Konto, Neustarts	Nicht interaktives SSH fehlt oft; als root trivial zu bearbeiten

Das systemd-Journal und rsyslog enthalten meist sich überschneidende Kopien derselben Zeile, unabhängig voneinander geschrieben und rotiert. auditd wird vom Kernel gespeist, nicht von syslog. Die Dateien wtmp und btmp schreiben login, sshd und PAM direkt. Diese Unabhängigkeit macht eine zusammengeführte Zeitleiste zu mehr als einer Bequemlichkeit: Erst durch sie werden Löschungen und Bearbeitungen sichtbar.

Nehmen wir einen einzelnen Passwort-Login von svc_backup aus 203.0.113.45:

auth.log: sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2, dann pam_unix(sshd:session): session opened, dann systemd-logind[845]: New session 7 of user svc_backup.
Journal: dieselben drei Meldungen, jeweils mit _PID, _UID, _SYSTEMD_UNIT=ssh.service und einem UTC-Zeitstempel in Mikrosekunden.
audit.log: USER_AUTH, USER_ACCT, LOGIN (setzt auid=1001 ses=114), USER_START und USER_LOGIN mit addr=203.0.113.45 res=success.
wtmp: ein USER_PROCESS-Eintrag auf pts/1 mit Host 203.0.113.45; beim Logout ein DEAD_PROCESS-Eintrag auf derselben Leitung.
lastlog: Der Slot für UID 1001 wird mit Zeit, pts/1 und 203.0.113.45 überschrieben.

Es tauchen drei Sitzungskennungen auf: die sshd-PID (3071), die Sitzungsnummer von systemd-logind (7) und die Audit-Sitzung (ses=114). Es sind unterschiedliche Nummern für denselben Login. Eine Sitzung zu rekonstruieren heißt, sie zu verknüpfen: Die PAM-Zeilen session opened und session closed tragen die sshd-PID, die logind-Sitzung wird Millisekunden danach angekündigt, und jeder Audit-Eintrag dazwischen trägt ses=114, auch Befehle, die später in einer Root-Shell laufen.

Wo sich die Quellen widersprechen und warum

Widersprüche sind normal. Bevor Sie von Manipulation sprechen, schließen Sie die harmlosen Erklärungen aus:

Überhaupt keine auth.log. Neuinstallationen von Debian 12 und aktuellem Fedora betreiben unter Umständen kein rsyslog. Das Journal ist dann das einzige Systemlog.
Das Journal beginnt später als auth.log. Das Journal ist größenbegrenzt (standardmäßig 10 % des Dateisystems, höchstens 4G) und kann flüchtig sein (/run/log/journal), wenn keine persistente Speicherung aktiviert ist.
SSH-Befehl ohne wtmp-Eintrag. ssh host command, scp und sftp belegen kein Terminal und hinterlassen oft keinen wtmp-Eintrag.
Keine execve-Einträge. Es war keine Audit-Regel für execve geladen. Lesen Sie zuerst /etc/audit/rules.d/.
Abweichende Zeiten. Traditionelle Syslog-Zeilen stehen in lokaler Zeit ohne Jahr; Journal und Audit-Log verwenden UTC. Eine Abweichung von einer Stunde ist meist eine Zeitzone, kein Angreifer.

Was nach diesen Prüfungen übrig bleibt, ist interessant: Auth-Zeilen, die im Journal stehen, aber in auth.log fehlen, Lücken in den Journal-Sequenznummern, ein wtmp-Eintrag, der nur aus Nullen besteht, eine lastlog-Zeit ohne passende wtmp-Sitzung. Der Leitfaden zur Manipulationserkennung geht jeden dieser Punkte durch.

Zuerst die Zeit normalisieren

Eine zusammengeführte Zeitleiste ist nur so gut wie ihr Umgang mit Zeitangaben:

RFC-3164-Syslog (Sep 14 10:02:11) hat weder Jahr noch Zeitzone. Die Zone ergibt sich aus /etc/localtime oder /etc/timezone im Abbild; das Jahr wird ausgehend von der Änderungszeit der Datei zurückgerechnet, wobei auf einen Jahreswechsel innerhalb der Datei zu achten ist. Siehe RFC-3164-Syslog.
Hochpräzise RFC-3339-Zeilen (2026-09-14T10:02:11.482113+00:00), der Standard unter Ubuntu 24.04 und Debian 12+, enthalten ihren Offset und Mikrosekunden.
RFC-5424-Zeilen von Forwardern tragen ebenfalls einen vollständigen Zeitstempel.
Journal-Zeiten sind Mikrosekunden seit der Epoche, in UTC. journalctl zeigt _SOURCE_REALTIME_TIMESTAMP (Zeitpunkt, zu dem die Meldung erzeugt wurde), sofern der Eintrag eines hat.
audit.log-Stempel lauten msg=audit(1789380131.486:181296): Epochensekunden, Millisekunden, dann eine Seriennummer.
wtmp/btmp/lastlog enthalten Epochensekunden (in utmp-Einträgen zusätzlich Mikrosekunden).

Rechnen Sie alles in UTC um und notieren Sie, wie jede Zeit ermittelt wurde (expliziter Offset, Zonendatei oder erschlossenes Jahr).

Erst deduplizieren, dann korrelieren

Auf einem Host, auf dem sowohl rsyslog als auch journald laufen, existiert jede sshd-Zeile zweimal. Wer beide zählt, bläht Brute-Force-Zahlen auf und überfrachtet die Zeitleiste. Behalten Sie die Journal-Kopie (sie hat vertrauenswürdige Felder und Mikrosekunden) und markieren Sie die Textzeile als Duplikat, halten Sie die Textzeile aber verfügbar: Fehlt die Journal-Kopie, ist genau dieser Unterschied ein Befund.

Korrelieren Sie dann nach Sitzung: sshd-PID-Paare für PAM-Öffnen und -Schließen, logind-Sitzungsnummern, Audit-ses sowie wtmp-Login- und -Logout-Einträge. Eine Sitzung, die in drei Quellen erscheint, aber nicht in wtmp, ist genau das, was ein Log-Cleaner hinterlässt.

Im Browser erledigen

Linux Log Parser führt diese Schritte mit den Dateien aus, die Sie hineinziehen: Er liest Textlogs (RFC 3164 mit Jahreserschließung und Zonenumrechnung, RFC 3339, RFC 5424, rotierte und .gz-Generationen), binäre Journal-Dateien einschließlich Compact-Modus und komprimierter Felder, journalctl -o export und -o json, audit.log im Format RAW oder ENRICHED, wtmp/btmp/utmp in den Layouts für x86_64 und aarch64, lastlog, wtmp.db und lastlog2.db. Er baut eine einzige UTC-Zeitleiste, markiert auth.log-Zeilen, die auch im Journal stehen, rekonstruiert Sitzungen und listet Befunde wie Passwortraten mit anschließendem Erfolg, Root-Shells, Persistenz über cron und systemd, Journal-Lücken und geleerte wtmp-Einträge. Alles läuft lokal in WebAssembly; nichts wird hochgeladen.

Wie es weitergeht

Logs sichern von einem laufenden Host, mit einem Triage-Tool oder aus einem Datenträgerabbild.
auth.log und secure lesen für SSH, sudo und Kontoänderungen.
Journal-Forensik: Dateiformat, Sequenznummern und .journal~-Dateien.
auditd-EXECVE-Forensik: auid, ses und hex-kodierte Argumente.
wtmp, btmp und lastlog, einschließlich wtmpdb und lastlog2.
Eine vollständige Beispielermittlung mit dem synthetischen Beispiel des Tools.

Für Referenztabellen pro Artefakt decken die Spickzettel auf linuxforensics.app das systemd-Journal, auth.log und syslog, auditd, wtmp, btmp und lastlog, sudo-Logs und SSH-Artefakte ab.