Linux Audit Log Commands: the Six That Answer Real Questions

Linux has two separate logging systems, and most confusion about audit commands comes from not knowing which one you are talking to.

The journal is systemd’s log: services, the kernel, anything writing to syslog. The audit subsystem is a kernel facility that records syscalls and file access against rules you define. The journal tells you what the system reported. auditd tells you what actually happened, at a level nothing has to volunteer.

Here are the six commands that cover the real questions, and what each one can and cannot answer.

journalctl, for what the system said about itself

journalctl -u sshd --since "2 days ago"
journalctl -p err -b
journalctl _UID=1001 --since today

The first reads one service over a window. The second reads errors and above from the current boot, which is the fastest way to see what is broken right now. The third filters by user ID, which works because the journal indexes structured fields rather than plain text.

Two flags earn their place: -b -1 reads the previous boot, which matters when a machine rebooted unexpectedly, and -f follows in real time.

Limit worth knowing: if the journal is volatile, which is the default on some distributions, it lives in /run/log/journal and does not survive a reboot. Check with journalctl --disk-usage. A zero there is not an absence of events, it is an absence of storage.

ausearch, for what the kernel recorded

ausearch queries the audit log, and it is the one command in this list that answers questions the rest cannot.

ausearch -m USER_LOGIN -ts today
ausearch -f /etc/shadow
ausearch -ua 1001 -ts recent
ausearch -m avc -ts today

By message type, by file, by the audit user ID that survives su and sudo, and by SELinux denial. The -ua form is the interesting one: it tracks the original login identity through privilege changes, so a user who becomes root is still attributable.

ausearch -i interprets numeric values into names, and you almost always want it.

aureport, for the shape of it

aureport --summary
aureport -au --summary
aureport -f -i --start this-week

aureport aggregates instead of listing. Authentication attempts by result, file events by path, executables run. It is the command to reach for when you do not yet know what you are looking for and need to see which numbers are wrong before you go read individual events.

auditctl, for deciding what gets recorded at all

Nothing appears in ausearch unless a rule put it there. auditctl is where rules live.

auditctl -l
auditctl -w /etc/passwd -p wa -k passwd_changes
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config

-w watches a path, -p wa records writes and attribute changes, and -k tags events with a key so you can retrieve them later with ausearch -k passwd_changes. Always set a key. Rules without one are findable only by path, which becomes painful as the rule set grows.

Rules added with auditctl disappear on reboot. Persistent rules belong in /etc/audit/rules.d/audit.rules.

The trade off is real: watching a busy directory generates a large volume of events, and audit logs fill disks. Watch specific files that matter rather than trees that are convenient.

last and lastb, for logins

last -F -a
lastb -F
last -x | head

last reads /var/run/utmp and /var/log/wtmp for successful sessions, lastb reads /var/log/btmp for failed ones, and last -x adds runlevel changes and shutdowns, which is how you see reboots in the same timeline as logins.

These read binary files that can be edited. A tampered wtmp still parses cleanly. A gap in last output, or a btmp that is suspiciously empty on an internet facing host, is a finding rather than a reassurance.

The thing all six have in common

Every command here reads a file on the machine being investigated. On a healthy system that is fine, and it is most of what you will ever need.

On a machine you suspect, it is the weakest form of evidence there is, because an attacker with root had both the motive and the ability to change what these commands read. This is why remote logging exists, and why the copy on a separate host is worth more than everything local. The broader method is in how to check if a Linux server is compromised, and the rules worth setting before you need them are part of Linux hardening.