Auditd Configuration Guide: The “Black Box” for Tracking Every Change on Linux – ITFROMZERO

Table of Contents

The 2 AM Shock and the Frustration of Empty Logs

Imagine it’s 2 AM, and your phone is alerting you non-stop because your server is facing an SSH brute-force attack at 5,000 requests per minute. You rush to log in and investigate, but the feeling is gut-wrenching: /var/log/auth.log or history has been wiped clean by the intruder. Default tools only tell you who got in, but they are completely “blind” to what they did to system files or which background processes they planted.

Default Linux logs are far too basic for forensic investigations. When a configuration file in /etc is modified, you can’t know who did it without kernel-level monitoring. This is why you need a true “black box” for your server.

Why Standard System Logs Often Fall Short

Most new admins place absolute trust in syslog or journald. In reality, these services run in user-space. If a hacker gains root access, they can easily disable the service or edit log files in a heartbeat.

The reason is that these tools ignore System Calls (syscalls) — the direct communication language between software and the operating system kernel. For example, when a file is deleted, the unlink syscall is executed. If you don’t capture this syscall, you’ll never find definitive evidence of the culprit. Furthermore, the lack of tagging makes filtering logs through millions of lines of data a nightmare.

Monitoring Options: From Surface-Level to Microscopic Detail

To trace activities effectively, I’ve tried various methods:

Using last and history commands: This is only useful for managing internal users. A hacker just needs to use unset HISTFILE, and you’ll lose their trail completely.
Using IDS (like Suricata or Lynis): Excellent for vulnerability scanning but weak at recording user behavior in real-time.
Configuring Auditd: This is the gold standard in Linux security. It hooks directly into the kernel to “snapshot” every event you request.

Auditd – The Ultimate Solution for Monitoring All Linux Activity

Auditd (Linux Audit Daemon) acts like a diligent accountant for your server. It records everything: from file permission changes to the execution of sensitive commands. Here is how I deploy it on production systems.

1. Quick Auditd Installation

Installation on popular distributions is extremely simple, taking less than 30 seconds:

# For Ubuntu/Debian
sudo apt update && sudo apt install auditd audispd-plugins -y

# For CentOS/RHEL/Fedora
sudo yum install audit -y
sudo systemctl enable auditd --now

2. Setting Up “Battle-Tested” Rules

By default, Auditd records very little. You need to define rules in the /etc/audit/rules.d/audit.rules file. I usually focus on three groups: file monitoring, admin commands, and data deletion syscalls.

Open the configuration file:

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

Add the following lines to protect the most critical areas:

# Monitor user/password modifications
-w /etc/passwd -p wa -k user-modify
-w /etc/shadow -p wa -k user-modify

# Monitor network configuration files
-w /etc/network/ -p wa -k network-config

# Record sudo command usage
-w /usr/bin/sudo -p x -k privileged-access

# Catch file deletion or renaming in the act
-a always,exit -S unlink -S unlinkat -S rename -S renameat -k delete-activity

Quick parameter explanation:

-w: Path to monitor.
-p wa: Monitor write (w) access and attribute (a) changes.
-k: Assign a label (key) to find logs instantly later.
-S: The name of the syscall to capture.

After saving, restart the service:

sudo service auditd restart

3. Blazing-Fast Log Querying When Issues Arise

Never use cat to read audit.log, or you’ll get lost in a data labyrinth. Use ausearch — a powerful log filtering tool.

For example, to find out who touched the /etc/passwd file:

sudo ausearch -k user-modify

To see a general report of failed intrusion attempts today:

sudo aureport -f -i --failed

Hard-Earned Lessons: Don’t Let Logs “Devour” Your Hard Drive

My biggest mistake was once being too greedy with configurations. Monitoring every read syscall on a busy database server can generate 50GB of logs in just two hours, crashing the server instantly.

Advice for fellow admins:

Only monitor what’s truly important: config files, admin commands, and ownership changes.
Set up log rotation in /etc/audit/auditd.conf to avoid disk overflow:

max_log_file = 100          # Rotate when the file reaches 100MB
num_logs = 10               # Keep up to 10 oldest files
max_log_file_action = ROTATE

Installing Auditd might consume an extra 1-3% of CPU, but this is a small price to pay compared to losing data without a trace. If you’re running a production system or need PCI-DSS compliance, Auditd is a must-have. If any rule is too difficult to write, just leave a comment below and I’ll help you out!