auditd audit.log: der Kernel-Audit-Trail unter Linux

Was es ist

Der Linux-Kernel besitzt ein Audit-Subsystem, das Datensätze zu sicherheitsrelevanten Ereignissen erzeugt: Syscalls, die auf geladene Regeln passen, Datei-Watches, Konfigurationsänderungen sowie Meldungen, die PAM, sudo, sshd, useradd und ähnliche Programme aus dem User Space senden. auditd empfängt diese Datensätze über Netlink und schreibt sie nach /var/log/audit/audit.log. Siehe den Glossareintrag zu auditd.

Was im Log landet, hängt vollständig von den Regeln ab. Ohne eigene Regeln erhalten Sie trotzdem die User-Space-Ereignisse (Anmeldungen, Authentifizierung, Sitzungsbeginn und -ende, Kontoänderungen, Start und Stopp von Diensten) sowie einige Kernel-Ereignisse. Mit execve- oder Datei-Watch-Regeln wird audit.log zum detailliertesten Ausführungsnachweis auf einem Linux-Host.

Wo es liegt

Auf Hosts ohne auditd gelangen manche Kernel-Audit-Meldungen dennoch ins Kernel-Log und ins Journal (_TRANSPORT=audit), prüfen Sie also auch das Journal.

Was es belegt

• Ablauf von Authentifizierung und Sitzung über PAM: USER_AUTH, USER_ACCT, CRED_ACQ, USER_LOGIN, USER_START, USER_END, mit acct=, addr=, terminal= und res=success|failed.
• Programmausführung (sofern eine execve-Regel existiert): Die Datensätze SYSCALL + EXECVE + CWD + PATH + PROCTITLE rekonstruieren die vollständige Befehlszeile und das Verzeichnis.
• Zuordnung über Rechtewechsel hinweg: auid ist die beim Login gesetzte Login-UID, die über sudo und su vererbt wird. Eine von deploy gestartete root-Shell trägt also weiterhin die auid von deploy.
• Kontoverwaltung (ADD_USER, DEL_USER, ADD_GROUP, USER_MGMT, USER_CHAUTHTOK) und sudo-Befehle (USER_CMD).
• Manipulation des Audit-Systems selbst (CONFIG_CHANGE, DAEMON_START, DAEMON_END) und Änderungen an Firewall-Regeln (NETFILTER_CFG).
• Es belegt nichts, was die Regeln nicht abdecken, und Shell-Builtins erzeugen nie execve-Datensätze.

Wichtige Felder

Ein typisches execve-Ereignis (die Datensätze teilen sich denselben msg=audit(...)-Stempel):

type=SYSCALL msg=audit(1789874047.512:8812): arch=c000003e syscall=59 success=yes exit=0 ppid=4190 pid=4302 auid=1001 uid=0 gid=0 euid=0 tty=pts0 ses=12 comm="curl" exe="/usr/bin/curl" key="exec"
type=EXECVE msg=audit(1789874047.512:8812): argc=3 a0="curl" a1="-o" a2="/tmp/.x"
type=CWD msg=audit(1789874047.512:8812): cwd="/root"
type=PROCTITLE msg=audit(1789874047.512:8812): proctitle=6375726C002D6F002F746D702F2E78

Mit dem Upstream-Standard log_format = ENRICHED hängt auditd übersetzte Felder nach einem 0x1D-Byte (Group Separator) in Großbuchstaben an: AUID="deploy" UID="root" SYSCALL=execve. Diese Namen wurden auf dem Ursprungssystem aufgelöst und sind daher verlässlicher als ausearch -i auf einer Analyse-Workstation. Audit 2.x nutzte standardmäßig RAW, und Distributionen können den Wert überschreiben, prüfen Sie also die Konfiguration im Image.

Zeitstempel

msg=audit(1789874047.512:8812) enthält Sekunden seit der Unix-Epoche mit Millisekundenanteil, gefolgt von der Seriennummer des Ereignisses. Der Wert ist naturgemäß UTC, eine Zeitzonenumrechnung ist nicht nötig.

date -u -d @1789874047.512
ausearch -if audit.log -ts 09/20/2026 03:00:00 -te 09/20/2026 04:00:00 -i   # date format follows the analysis host's locale

Die Seriennummer erzeugt der Kernel, und sie beginnt nach einem Neustart von vorn. Gruppieren Sie Datensätze daher über den vollständigen Stempel sec.msec:serial, nicht allein über die Seriennummer.

Aufbewahrung

auditd rotiert sein Log selbst, nicht logrotate. Die mitgelieferte Upstream-auditd.conf verwendet max_log_file = 8 (MiB), num_logs = 5 und max_log_file_action = ROTATE, also rund 40 MiB Historie. Mit execve-Auditing auf einem stark ausgelasteten Server können das wenige Stunden sein. num_logs = 0 oder eine keep_logs-Aktion ändern das Verhalten; space_left_action und disk_full_action legen fest, was bei voller Platte passiert (die mitgelieferte Konfiguration nutzt SYSLOG für space_left_action sowie SUSPEND, womit das Schreiben auf die Platte stoppt, für admin_space_left_action und disk_full_action).

Sicherung

# Dead box
cp -a /mnt/evidence/var/log/audit /mnt/evidence/etc/audit /cases/2026-017/

# Live, as root: also capture the loaded rules and status
auditctl -l > auditctl_rules.txt
auditctl -s > auditctl_status.txt
tar -C / -cpf /media/ir/audit.tar var/log/audit etc/audit

UAC sammelt /var/log und führt bei der Live-Response auditctl -l und auditctl -s aus. Die geladenen Regeln können von den Dateien auf der Platte abweichen, wenn jemand auditctl -D ausgeführt oder Regeln von Hand hinzugefügt hat.

Auswertung

ausearch und aureport aus dem audit-Paket sind die Referenzwerkzeuge und arbeiten mit -if auch auf kopierten Logs.

A=/cases/2026-017/audit
ausearch -if "$A" -m USER_LOGIN,USER_AUTH -i                  # logins and auth, interpreted
ausearch -if "$A" -m EXECVE -ul 1001 -i                        # everything run by login UID 1001
ausearch -if "$A" -k exec --format csv > exec.csv              # by rule key, for spreadsheets
ausearch -if "$A" -m CONFIG_CHANGE,DAEMON_END,DAEMON_START -i  # audit tampering
aureport -if "$A" --login --summary -i
aureport -if "$A" -x --summary                                 # executables

Das Plaso-Parser-Plugin text/selinux liest audit.log in eine Super-Timeline ein. Zircolite (--auditd) wendet Sigma-Regeln für Linux-auditd auf das Log an. 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

• Lesen Sie vor der Suche /etc/audit/rules.d/ im Image: Fehlende execve- oder -w-Regeln erklären fehlende Ausführungsspuren besser als eine Manipulation.
• -i übersetzt UIDs anhand der /etc/passwd des Analysesystems, sofern das Log nicht angereichert ist. Prüfen Sie Namen immer gegen die Kontodateien des Images selbst.
• auid übersteht sudo -i und su -; ein Filter auf auid zeigt also, was ein Benutzer in einer root-Shell getan hat. Vergleichen Sie mit sudo-Logs und der Shell-History.
• Suchen Sie in CONFIG_CHANGE- und SYSCALL-Datensätzen nach auditctl -e 0, auditctl -D, systemctl stop auditd und Änderungen unter /etc/audit/. Das Immutable-Flag (-e 2) verhindert Regeländerungen bis zum Neustart; ein unerwarteter Neustart kurz vor einem Vorfall kann daher Absicht sein.
• ses-Werte verknüpfen alle Datensätze einer Anmeldung; bringen Sie sie mit Sitzungen in wtmp und Accepted-Zeilen in auth.log zusammen.
• Weniger rotierte Generationen, als num_logs erlaubt, auf einem Host, der ausgelastet genug ist, um sie gefüllt zu haben, deuten auf Löschung hin. Vergleichen Sie die Dateigrößen mit max_log_file.