sudo-Logs: Nachweise der Rechtenutzung unter Linux

Was es ist

Das Policy-Plugin sudoers von sudo protokolliert jede zugelassene und abgelehnte Anfrage. Standardmäßig sendet es pro Ereignis eine Zeile an syslog, sofern verfügbar über die Facility authpriv (Priorität notice für zugelassene, alert für abgelehnte Anfragen). Diese Zeilen landen im Authentifizierungs-Textlog und im Journal. Optionale Einstellungen ergänzen eine eigene Logdatei, JSON-Ausgabe, Exit-Status, das Protokollieren von Unterbefehlen sowie vollständige Mitschnitte von Tastatureingaben und Bildschirmausgabe der Sitzungen.

Auch die Richtlinie selbst (/etc/sudoers und ihre Include-Verzeichnisse) ist ein Beweismittel: Ein Angreifer, der eine NOPASSWD-Regel hinzufügt, hat Persistenz geschaffen und die Passwortabfrage beseitigt, die sonst als Authentifizierungsereignis auftauchen würde.

Wo es liegt

Was es belegt

• Das aufrufende Konto, den Zielbenutzer (USER=), Terminal, Arbeitsverzeichnis und die vollständige Befehlszeile jedes zugelassenen Befehls.
• Ablehnungen: user NOT in sudoers, user NOT authorized on host, command not allowed, N incorrect password attempts, a password is required.
• Den umgebenden PAM-Kontext: pam_unix(sudo:session): session opened for user root(uid=0) by deploy(uid=1001) und pam_unix(sudo:auth): authentication failure.
• Mit I/O-Logging: genau, was eingegeben und angezeigt wurde, abspielbar.
• Es zeigt nicht, was innerhalb von sudo -i, sudo -s oder sudo bash geschah: Das Log erfasst nur die Shell. Nutzen Sie dafür auditd (auid), die Shell-History, log_subcmds oder I/O-Logs.
• Ein Benutzer mit root-Rechten kann diese Logs bearbeiten, und jeder kann mit logger täuschend ähnliche Zeilen einschleusen.

Wichtige Felder

Zugelassener Befehl, sudo-Logformat:

Sep 20 03:15:30 web-prod-03 sudo:   deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/bash
Sep 20 03:16:02 web-prod-03 sudo:   deploy : TTY=pts/0 ; PWD=/tmp ; USER=root ; TSID=000001 ; COMMAND=/usr/bin/tar -xf /tmp/x.tar
Sep 20 03:17:44 web-prod-03 sudo:   intern : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/intern ; USER=root ; COMMAND=/usr/bin/id

Steuerzeichen werden oktal mit vorangestelltem # protokolliert (#011 für Tab), Leerzeichen im Befehlspfad erscheinen als #040. Mit log_format=json enthält das Dateilog JSON-Objekte mit den vollständigen Benutzerangaben und der Umgebung.

Audit-Datensatz zur selben Aktion (RHEL-Familie):

type=USER_CMD msg=audit(1789874130.201:8830): pid=4302 uid=1001 auid=1001 ses=12 msg='cwd="/home/deploy" cmd="/usr/bin/bash" terminal=pts/0 res=success'

cmd und cwd sind hexkodiert, wenn sie Leerzeichen enthalten; ausearch -i dekodiert sie.

Zeitstempel

Syslog-Zeilen übernehmen das Format des Syslog-Daemons: traditionelle Ortszeit ohne Jahr in der RHEL-Standardkonfiguration, RFC 3339 mit Offset unter Debian 12+ und Ubuntu 24.04 (siehe auth.log). Die Kopie im Journal hat einen UTC-Zeitstempel in Mikrosekunden und ist der einfachere Anker. sudos eigene Logdatei verwendet ein Datum im Stil Mmm dd HH:MM:SS und ergänzt das Jahr nur mit log_year. I/O-Logs speichern den Sitzungsbeginn in der Datei log/log.json und relative Verzögerungen in timing.

Aufbewahrung

Die syslog-Kopie lebt so lange wie auth.log/secure (standardmäßig etwa vier wöchentliche Generationen), die Journal-Kopie so lange, wie die Größenlimits des Journals es zulassen. I/O-Logs werden von sudo nie rotiert; die sechsstellige Sitzungs-ID zur Basis 36 (00/00/01) läuft bei maxseq über, danach werden alte Sitzungen überschrieben. Die Lecture-Dateien und ~/.sudo_as_admin_successful bleiben bis zur Löschung erhalten.

Sicherung

E=/mnt/evidence
tar -C "$E" -cpf /cases/2026-017/sudo.tar \
  etc/sudoers etc/sudoers.d var/log/sudo-io var/lib/sudo var/db/sudo 2>/dev/null
journalctl -D "$E/var/log/journal" SYSLOG_IDENTIFIER=sudo -o json --utc > sudo-journal.json
zgrep -h 'sudo:' "$E"/var/log/auth.log* "$E"/var/log/secure* 2>/dev/null > sudo-lines.txt

UAC sammelt /var/log, /etc und die Lecture-Zeitstempel von sudo (Artefakt sudo_lectured). Auf einem laufenden System zeigt sudo -l -U <user> die effektiven Rechte eines Kontos, ohne etwas zu verändern.

Auswertung

# Allowed commands per invoking user
zgrep -h 'COMMAND=' auth.log* | sed -E 's/.*sudo: +([^ ]+) : .*USER=([^ ]+) ; .*COMMAND=(.*)/\1 -> \2 : \3/' | sort | uniq -c
# Failures
zgrep -hE 'sudo:.*(NOT in sudoers|not allowed|incorrect password)' auth.log*
# Replay a recorded session (read-only)
sudoreplay -d /cases/2026-017/var/log/sudo-io -l
sudoreplay -d /cases/2026-017/var/log/sudo-io 000001
# Audit copy
ausearch -if audit.log -m USER_CMD -i

Jedes I/O-Sitzungsverzeichnis enthält log, log.json, timing, ttyin, ttyout, stdin, stdout und stderr. Plaso erfasst sudo-Zeilen über seine Syslog-Parser. Linux Log Parser liest auth.log / secure, syslog, Journal-Dateien, audit.log und wtmp / btmp / lastlog im Browser und führt sie in einer Zeitleiste mit rekonstruierten Login-Sitzungen zusammen; es wird nichts hochgeladen.

Tipps für die Untersuchung

• Prüfen Sie jede Datei in /etc/sudoers.d/ samt mtime/ctime. Neue NOPASSWD: ALL-Einträge, Defaults !syslog, !log_allowed oder syslog_goodpri=none schalten die Protokollierung stumm und sind starke Indikatoren.
• COMMAND=/usr/bin/bash, /bin/su, Editoren, find, less, vi oder Interpreter bedeuten, dass die eigentliche Aktivität in einem Kindprozess stattfand; verfolgen Sie auid in audit.log und die Shell-History des Kontos.
• Ein erfolgreiches sudo ohne vorangehende pam_unix(sudo:auth)-Abfrage ist innerhalb von timestamp_timeout (standardmäßig 5 Minuten) oder mit NOPASSWD normal; die Dateien in /run/sudo/ts/ existieren nur auf einem laufenden System.
• Die Lecture-Datei wird angelegt, wenn sudo seine Belehrung zum ersten Mal mit einer Passwortabfrage anzeigt (Standard lecture=once). Ihre Zeitstempel und Ubuntus ~/.sudo_as_admin_successful liefern pro Konto ein Datum der ersten sudo-Nutzung, nützlich bei neu angelegten Angreiferkonten (siehe Konten).
• Zeilen mit TTY=unknown stammen von Skripten, cron oder nicht interaktivem SSH; korrelieren Sie mit cron und sshd-Zeilen.
• Vergleichen Sie Textlog, Journal und Audit-Kopie: Ein sudo-Ereignis, das im Journal steht, aber nicht in auth.log, deutet auf eine Bearbeitung der Textdatei hin.