Skip to main content
RunBook Academy

LinuxXXXI · Audit and Security Loggingauditd

auditd architecture - the Linux audit framework

Intermediate⏱ ~12 minauditctlausearchaureport

What you'll learn

  • Describe auditd and the audit framework
  • Understand rules, watch points, and the audit log
  • Use ausearch and aureport
  • Recognise when audit is the right tool

Prerequisites

Verified against Ubuntu 24.04 LTS · Debian 12 (Bookworm) · RHEL 9.x · Rocky Linux 9.x · AlmaLinux 9.x · Linux kernel 6.1 LTS / 6.6 LTS · systemd 255+ · OpenSSH 8.7p1 (RHEL 9) / 9.6p1 (Ubuntu 24.04) · nftables 1.0.x · chrony 4.x · Pacemaker 2.1.x · Corosync 3.1.x · 2026-08-09

Not yet marked complete on this device.

auditd is the Linux audit framework. It records security-relevant events: file accesses, system calls, authentication, configuration changes. Unlike syslog (which records messages), auditd records structured events that can be queried.

What auditd records

  • File access (read, write, execute, attribute change).
  • System calls (execve, setuid, bind, etc.).
  • Authentication (login, sudo, ssh).
  • Configuration changes (/etc/passwd, /etc/shadow).
  • SELinux/AppArmor denials.
  • PAM events.
  • Kernel module loads.

Architecture

Kernel audit subsystem (audit.ko)
       |
       v
auditd (userspace daemon)
       |
       v
audit log (/var/log/audit/audit.log)
       |
       v
ausearch / aureport (query tools)
       |
       v
Central SIEM (optional)

The kernel records events based on rules. auditd writes them to the log. ausearch and aureport query the log.

Read the audit log

cat /var/log/audit/audit.log

Each line is a structured event:

type=SYSCALL msg=audit(1625000000.123:456): arch=x86_64 syscall=2 success=yes exit=3 a0=7ffd8e a1=0 a2=1b6 a3=7ffd8e items=1 ppid=1234 pid=1235 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="bash" exe="/usr/bin/bash" key="passwd"
type=CONFIG_CHANGE msg=audit(...): op=set uid=0 tty=pts0 auid=1000 ses=1 old_enforcing=1 new_enforcing=0

Fields:

  • type=SYSCALL: event type.
  • success=yes: the syscall succeeded.
  • arch=x86_64 syscall=2: the syscall number (2 = open).
  • auid=1000: the original login UID.
  • uid=1000, euid=1000: current UID and effective UID.
  • comm="bash" exe="/usr/bin/bash": the executable.
  • key="passwd": the rule key (used to filter).

ausearch

Query the audit log:

# Substitute your own values before running:
TARGET_USER=alice

# All events for a user
sudo ausearch -ua "$TARGET_USER"

# All events for a file
sudo ausearch -f /etc/passwd

# By syscall
sudo ausearch -sc openat
sudo ausearch -sc execve

# By time
sudo ausearch -ts today
sudo ausearch -ts 08/09/26

# By key
sudo ausearch -k passwd

# Combined
sudo ausearch -ua "$TARGET_USER" -k passwd -ts today

aureport

Summarise the audit log:

sudo aureport --summary              # overall
sudo aureport --login                # login events
sudo aureport --comm                 # commands run
sudo aureport --auth                 # authentication attempts
sudo aureport --file                 # file changes
sudo aureport --syscall              # syscall counts
sudo aureport --failed               # failed events
sudo aureport --key                  # by rule key
sudo aureport --user                 # per-user summary

There is no --sudo report. aureport reports by record type, not by command name, so sudo activity is reached a different way:

# Commands run through sudo, with UIDs and names resolved
sudo ausearch -m USER_CMD -ts today -i

# sudo authentication successes and failures
sudo aureport -au -i -ts today

# By rule key, if your rules tag privileged commands
sudo ausearch -k privileged -ts today -i

-i (--interpret) is worth making a habit: without it the output is raw numeric UIDs, syscall numbers and hex-encoded arguments. aureport --help lists the full option set; check there before scripting a report name you have seen in a blog post.

Audit rules

Audit rules define what to record. Two locations:

  • /etc/audit/rules.d/: persistent rules (preferred).
  • auditctl: runtime rules (not persistent).
# Watch a file
auditctl -w /etc/passwd -p wa -k passwd

# Watch a syscall
auditctl -w /usr/bin/passwd -p x -k password-change

# Watch a directory
auditctl -w /etc/sudoers.d/ -p wa -k sudoers

# List current rules
auditctl -l

-p: permissions to watch (r read, w write, x execute, a attribute).

Audit rules in /etc/audit/rules.d/

# /etc/audit/rules.d/10-base-config.rules

# Watch authentication files
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# Watch SSH config
-w /etc/ssh/sshd_config -p wa -k sshd

# Watch sudoers.d
-w /etc/sudoers.d/ -p wa -k sudoers

Reload:

sudo augenrules --load
sudo auditctl -l

Performance

Audit can produce a lot of events. Tune for performance:

# Use a larger buffer for busy hosts
auditctl -b 8192

# Exclude noisy processes
auditctl -a never,exclude -F exe=/usr/sbin/chronyd

A busy host with too many audit rules can drop events. Monitor /var/log/audit/audit.log rotation and size.

Knowledge check

Knowledge check · 3 questions

  1. Q1. Which command queries the audit log for events?

  2. Q2. A rule added with auditctl is gone after the next reboot unless it was also written to /etc/audit/rules.d/.

  3. Q3. Which of the following are valid audit permissions? Select all that apply.

Passing score: 75%. Answers are checked in this browser.