Forensik von auth.log und secure: SSH, sudo und su

Kurzfassung. In auth.log (Debian, Ubuntu) und secure (RHEL-Familie) schreibt rsyslog die Facilities auth und authpriv: sshd, sudo, su, PAM, passwd, useradd, cron-Sitzungen. Gruppieren Sie sshd-Zeilen nach PID, um jede Verbindung zu rekonstruieren, zählen Sie Fehlschläge pro Quelladresse, suchen Sie den ersten Erfolg danach und verfolgen Sie die Sitzung dann bis zu sudo. Bestimmen Sie das Zeitstempelformat, bevor Sie irgendetwas umrechnen.

Welche Datei, welches Format

Distribution	Authentifizierung	Alles andere	Zeitstempel
Ubuntu 24.04, Debian 12+	`/var/log/auth.log`	`/var/log/syslog`	RFC 3339, Mikrosekunden, Offset
Ältere Debian- und Ubuntu-Versionen	`/var/log/auth.log`	`/var/log/syslog`	Traditionell, lokale Zeit, ohne Jahr
RHEL, Rocky, Alma, Fedora	`/var/log/secure`	`/var/log/messages`	Traditionell, lokale Zeit, ohne Jahr

Die beiden Formate im Vergleich:

Sep 14 10:02:11 fin-jump-01 sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2
2026-09-14T10:02:11.482113+00:00 fin-jump-01 sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2

Für die erste Form (im Stil von RFC 3164) lesen Sie die Zone aus /etc/localtime und erschließen das Jahr aus der Änderungszeit der Datei und der Rotationsreihenfolge. Eine Datei, die über den Jahreswechsel reicht, enthält Dezember-Zeilen gefolgt von Januar-Zeilen; die Januar-Zeilen gehören zum Folgejahr. Rund um die Zeitumstellung können sich lokale Zeiten wiederholen oder eine Stunde überspringen.

Debian 12 und manche Fedora-Installationen haben überhaupt kein rsyslog. Eine fehlende auth.log ist kein Beweis für eine Löschung; prüfen Sie das systemd-Journal.

SSH: jede Verbindung über die PID rekonstruieren

Jede Verbindung erhält ihren eigenen sshd-Prozess (ab OpenSSH 9.8 heißt der Prozess pro Verbindung sshd-session, suchen Sie also nach beiden Namen). Alle Zeilen einer Verbindung teilen sich diese PID:

sshd[2381]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=198.51.100.23  user=svc_backup
sshd[2381]: Failed password for svc_backup from 198.51.100.23 port 40135 ssh2
sshd[2381]: Connection closed by authenticating user svc_backup 198.51.100.23 port 40135 [preauth]

Wichtige Meldungen:

Meldung	Bedeutung
`Invalid user admin from IP`	Konto existiert auf dem Host nicht
`Failed password for [invalid user] X from IP`	Falsches Passwort (oder nicht existierender Benutzer)
`Accepted password for X from IP`	Passwort-Login erfolgreich
`Accepted publickey for X from IP ... ED25519 SHA256:...`	Schlüssel-Login; der Fingerprint identifiziert den Schlüssel
`pam_unix(sshd:session): session opened for user X`	Sitzungsbeginn, gleiche PID wie die `Accepted`-Zeile
`pam_unix(sshd:session): session closed for user X`	Sitzungsende, gleiche PID
`Connection closed by ... [preauth]`	Verbindung vor der Authentifizierung getrennt

Die pam_unix-Zeilen stammen vom Modul pam_unix; systemd-logind: New session 7 of user X folgt innerhalb von Millisekunden und gibt der Sitzung eine Nummer, die im Journal auch als session-7.scope erscheint.

Passwortraten, dann ein Erfolg

Entscheidend ist nicht das Muster „viele Fehlschläge“ (die hat jeder aus dem Internet erreichbare SSH-Server), sondern Fehlschläge, gefolgt von einem Erfolg:

Zählen Sie Failed password- und Invalid user-Zeilen pro Quelladresse und listen Sie die ausprobierten Kontonamen auf.
Suchen Sie nach dem letzten Fehlschlag eine Accepted-Zeile für eines dieser Konten, von derselben oder von einer anderen Adresse. Eine andere Adresse wenige Minuten später ist häufig: Das Raten lief von einem Rechner, der Login von einem anderen.
Prüfen Sie, ob die erfolgreiche Methode password ist, bei einem Konto, das sich normalerweise mit publickey anmeldet. Ein Dienstkonto, das immer einen Schlüssel genutzt hat und plötzlich ein Passwort verwendet, ist eine starke Spur.
Vergleichen Sie die Quelladresse mit der Historie des Kontos. Ein Login von einer Adresse, die für dieses Konto nie zuvor aufgetaucht ist, rechtfertigt eine Rückfrage beim Kontoinhaber.

zgrep -hE 'sshd(-session)?\[[0-9]+\]: (Failed password|Invalid user)' auth.log* | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn
zgrep -hE 'sshd(-session)?\[[0-9]+\]: Accepted' auth.log*

Denken Sie daran, dass auf einem Host mit rsyslog und journald jede Zeile doppelt existiert; wer Journal und auth.log zusammen zählt, verdoppelt die Zahlen. btmp enthält eine dritte Kopie der fehlgeschlagenen Versuche.

sudo und su

sudo schreibt eine Zeile pro Befehl:

sudo:   svc_backup : TTY=pts/1 ; PWD=/home/svc_backup ; USER=root ; COMMAND=list
sudo:   svc_backup : TTY=pts/1 ; PWD=/home/svc_backup ; USER=root ; COMMAND=/bin/bash
sudo:   pam_unix(sudo-i:session): session opened for user root(uid=0) by svc_backup(uid=1001)

COMMAND=list ist sudo -l: Der Benutzer prüft, welche Rechte er hat. Oft das Erste, was ein Eindringling ausführt.
COMMAND=/bin/bash mit dem PAM-Dienst sudo-i ist sudo -i, eine interaktive Root-Shell. Ab diesem Punkt sieht auth.log keine einzelnen Befehle mehr; protokolliert werden nur Befehle, die erneut über sudo laufen. Verfolgen Sie die Sitzung über auditd weiter, wo auid den ursprünglichen Benutzer behält.
Fehlschläge: user NOT in sudoers, command not allowed, N incorrect password attempts und pam_unix(sudo:auth): authentication failure.
su protokolliert pam_unix(su:session): session opened for user root by X (bzw. su-l für su -) und bei Fehlschlag, je nach Distribution, Meldungen im Stil von FAILED SU.

Leerzeichen in sudo-Argumenten werden unverändert protokolliert, wodurch manche Befehlszeilen mehrdeutig werden (ist /srv/finance/Q3 close ein Argument oder zwei?). Der Audit-Eintrag USER_CMD kodiert solche Werte hexadezimal und klärt die Frage.

Konten und Passwörter

useradd[PID]: new user: name=..., groupadd-, usermod- und gpasswd-Zeilen bei Kontoänderungen.
passwd[PID]: pam_unix(passwd:chauthtok): password changed for X, wenn ein Passwort geändert wird. Ändert ein Eindringling das Passwort des Kontos, über das er gekommen ist, sperrt er den Inhaber aus und behält den Zugang.
chpasswd und chage für Massen- und Ablaufänderungen.

Cron

CRON[PID]: pam_unix(cron:session): session opened for user X erscheint in auth.log bei jeder Ausführung eines Jobs; der Befehl selbst steht in syslog (CRON[PID]: (X) CMD (...)), und eine Crontab-Bearbeitung zeigt sich als crontab[PID]: (root) REPLACE (X). Eine neue Benutzer-Crontab, die während einer interaktiven Sitzung installiert wurde, ist eine Spur zu Persistenz.

Schneller ans Ziel

Linux Log Parser liest auth.log, secure, syslog und messages in allen drei Formaten, einschließlich rotierter und .gz-Dateien, rekonstruiert Sitzungen aus den sshd-PID-Paaren und logind, markiert Zeilen, die auch im Journal stehen, und meldet Passwortraten mit anschließendem Erfolg, Logins von einer neuen Adresse, Root-Logins per SSH, Root-Shells über sudo und su, fehlgeschlagenes sudo sowie Kontoänderungen. Die Beispielermittlung zeigt diese Befunde an einem Beispiel.

Referenztabellen: auth.log und syslog, sudo-Logs und SSH-Artefakte auf linuxforensics.app.