# How to Configure Auditd (Linux Audit Daemon) for Security Compliance
In enterprise environments, particularly those adhering to regulatory frameworks like PCI-DSS, HIPAA, or SOC 2, simply securing a Linux server is not enough. You must be able to prove, forensically, exactly what happened on the server, who did it, and when.
Standard system logs (like `/var/log/syslog` or `auth.log`) are insufficient for strict compliance because they rely on individual applications to self-report their actions. If an application is compromised, or if a malicious root user alters a file, standard logs may capture nothing.
The **Linux Audit Daemon (`auditd`)** solves this. Operating at the kernel level, `auditd` intercepts system calls before they are executed. It provides a deep, granular, and tamper-resistant record of system events, from file modifications to network connections and command executions.
This guide details how to install, configure, and query `auditd` on a Linux server to monitor critical security events.
## Step 1: Install and Enable Auditd
While some enterprise distributions (like RHEL) include `auditd` by default, it usually needs to be installed manually on Debian/Ubuntu systems.
1. **Install the package:**
“`bash
sudo apt update
sudo apt install auditd audispd-plugins -y
“`
*(For CentOS/RHEL/Rocky Linux: `sudo dnf install audit -y`)*
2. **Verify the service is running:**
“`bash
sudo systemctl status auditd
“`
3. **Check the current ruleset:**
By default, `auditd` installs with a minimal or empty ruleset.
“`bash
sudo auditctl -l
“`
If it returns `No rules`, the daemon is running but not actively monitoring anything.
## Step 2: Configure Audit Rules
Audit rules are defined in `/etc/audit/rules.d/audit.rules`.
There are three main types of rules:
– **Control Rules:** Dictate the behavior of the daemon itself.
– **File System Rules:** Monitor specific files or directories for access or modification.
– **System Call Rules:** Monitor specific actions taken by any program at the kernel level.
Let’s configure a robust baseline ruleset.
1. Open the rules file in your editor:
“`bash
sudo nano /etc/audit/rules.d/audit.rules
“`
2. Add the following rules to the file.
### 1. Monitor Critical System Files
To comply with most security frameworks, you must track any modifications to user authentication files and the audit configuration itself.
“`text
# Monitor the audit logs and configuration
-w /etc/audit/ -p wa -k auditconfig
-w /var/log/audit/ -p wa -k auditlog
# Monitor user, group, and password databases
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
# Monitor sudoers configuration
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
“`
*Explanation: `-w` specifies the path to watch. `-p wa` monitors for ‘write’ and ‘attribute’ changes. `-k` assigns a unique ‘key’ to the rule, making it incredibly easy to search the logs later.*
### 2. Monitor Unauthorized File Access Attempts
Tracking when a user attempts to access a file but is denied by permissions is a strong indicator of unauthorized exploration or a compromised service.
“`text
-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM -k access_denied
“`
*Explanation: This monitors 64-bit (`b64`) system calls (`-S`) related to opening files. If the system call exits with an Access Denied (`-EACCES`) or Permission Denied (`-EPERM`) error, the event is logged under the key `access_denied`.*
### 3. Monitor Command Executions by the Root User
A critical compliance requirement is tracking the actions of administrators (root).
“`text
-a always,exit -F arch=b64 -F euid=0 -S execve -k root_actions
“`
*Explanation: This logs every command execution (`execve`) where the effective user ID (`euid`) is 0 (root).*
3. Save the file and exit the editor.
## Step 3: Apply and Verify the Rules
After modifying the rules file, you must instruct the daemon to load the new configuration.
1. **Load the rules:**
“`bash
sudo augenrules –load
“`
2. **Verify the rules are active in the kernel:**
“`bash
sudo auditctl -l
“`
You should now see the list of rules you defined in the output.
## Step 4: Querying the Audit Logs using ausearch
The raw audit log file (`/var/log/audit/audit.log`) is notoriously difficult for humans to read due to its dense, machine-centric format.
To extract meaningful information, you must use the `ausearch` utility. This is where the `-k` (key) parameter we defined in our rules becomes invaluable.
### Example 1: Who modified the sudoers file?
Because we tagged changes to `/etc/sudoers` with the key `sudoers`, we can easily query for that event:
“`bash
sudo ausearch -k sudoers
“`
The output will decode the event, showing the timestamp, the exact command used (e.g., `visudo`), and the user ID (UID) of the person who executed it.
### Example 2: Find all Permission Denied events today
“`bash
sudo ausearch -k access_denied -ts today
“`
### Example 3: View events linked to a specific user
If you want to see all audited actions performed by a specific user (e.g., UID 1000):
“`bash
sudo ausearch -ua 1000
“`
## Step 5: Generating Reports with aureport
While `ausearch` is for finding specific events, `aureport` is used to generate high-level compliance summaries.
1. **Generate a summary of all file modification events:**
“`bash
sudo aureport -f -i –summary
“`
*(The `-i` flag translates numerical UIDs into readable usernames).*
2. **Generate a summary of all login attempts:**
“`bash
sudo aureport -l -i
“`
## Conclusion
By implementing `auditd`, you elevate a Linux server from basic logging to kernel-level forensics. While this baseline ruleset fulfills major compliance requirements, `auditd` can be tuned indefinitely to monitor specific application configurations, network sockets, or execution paths, providing the ultimate source of truth for Linux security.