How to Use Ubuntu Server auditd for Detailed Security Logging

In a standard Ubuntu Server deployment, security logs are handled by rsyslog and written to /var/log/auth.log or /var/log/syslog. These logs are great for telling you when someone logged in via SSH or if a service crashed. However, if a malicious insider logs in, opens a sensitive database configuration file, changes a password, and deletes the file, standard syslog will only record the login event. It will not tell you what files they touched. To achieve forensic-level visibility into exactly what is happening on a Linux server, you must use the Linux Auditing System, commonly known as auditd.

What is auditd?

Unlike syslog, which relies on applications (like SSH or Apache) to voluntarily write log messages, auditd hooks directly into the Linux kernel itself. It can monitor every single system call (syscall). If a user attempts to open a file, edit a file, change permissions, or execute a binary, auditd intercepts the request at the kernel level and records it, regardless of whether the application wanted to log it or not.

Step 1: Install auditd

The audit daemon is not installed by default on Ubuntu.

sudo apt update
sudo apt install auditd audispd-plugins -y

Once installed, the service starts automatically. The main configuration file is located at /etc/audit/auditd.conf, and the rules defining what to monitor are stored in /etc/audit/rules.d/audit.rules.

Step 2: Create a File Watch Rule

The most common use case for auditd is File Integrity Monitoring (FIM). Suppose you want to know if anyone touches the /etc/shadow file (which contains all the hashed passwords on the system).

You can add a temporary rule to the running kernel using the auditctl command:

sudo auditctl -w /etc/shadow -p wa -k shadow_monitor

Let’s break down the syntax:

• -w /etc/shadow: Watch this specific file.
• -p wa: Monitor for write and attribute change operations (we don’t care if someone just reads it).
• -k shadow_monitor: Assign a custom key (tag) to this rule so we can easily search for it later.

Step 3: Trigger the Rule and Search the Logs

To test it, try modifying the file (e.g., changing a user’s password using the passwd command).

The audit logs are stored in binary format in /var/log/audit/audit.log. You should never read this file with cat or grep. Instead, use the built-in search tool, ausearch, and filter by the key we created.

sudo ausearch -k shadow_monitor

The output will be incredibly detailed. It will show you the exact timestamp, the System Call (SYSCALL), the User ID (uid) of the person who executed the command, the exact command they typed (exe="/usr/bin/passwd"), and whether the operation was successful (res=success).

Step 4: Generate a Human-Readable Report

If you don’t want to parse raw audit logs, you can pipe them into the aureport utility to generate a clean summary.

To see a summary of all file modifications today:

sudo aureport -f -i --ts today

(The -i flag translates numerical UIDs into actual usernames).

Step 5: Make the Rules Permanent

Rules applied with auditctl are wiped when the server reboots. To make them permanent, you must write them to the rules file.

sudo nano /etc/audit/rules.d/audit.rules

Add your watch rules at the bottom of the file (without the auditctl command):

-w /etc/shadow -p wa -k shadow_monitor
-w /etc/passwd -p wa -k passwd_monitor
-w /etc/ssh/sshd_config -p wa -k sshd_config

Then, restart the daemon (Note: You must use the service command, not systemctl, for auditd):

sudo service auditd restart

By configuring auditd, you ensure that no action on your server goes unrecorded, providing an ironclad audit trail for compliance and incident response.