How to Use auditd and Integrate It with Wazuh (With Practical Examples)

If you care about security, compliance, or just want to know who did what on your Linux server, you’ll eventually meet the Linux Audit Framework, better known as auditd. In this guide, we’ll walk through:

What auditd is and how it works
How to configure useful, practical audit rules
How to integrate auditd with Wazuh so you get alerts and dashboards instead of raw logs

All examples are written with a typical server in mind (Debian/Ubuntu/RHEL-like distro), but the concepts are the same across most Linux systems.

1. What Is `auditd` and Why Should You Care?

auditd is the userspace daemon for the Linux Audit Framework. Think of it as a “black box” for your server: it records security-relevant events such as:

Successful and failed logins
Changes to critical files and directories
Privilege escalations (e.g. sudo, su)
System calls made by specific processes or users

This is crucial for:

Incident investigation – “Who changed this config?”
Forensics – “What happened just before the compromise?”
Compliance – Many standards (ISO 27001, PCI-DSS, NIS2, etc.) expect this level of logging.

On its own, auditd gives you detailed logs in /var/log/audit/audit.log. Combined with Wazuh, those logs turn into alerts, dashboards, and correlations.

2. Installing and Enabling `auditd`

2.1 Check if `auditd` is already installed

sudo auditctl -s 2>/dev/null || echo "auditd not configured or not running"

2.2 Install on Debian / Ubuntu

sudo apt update sudo apt install auditd audispd-plugins

2.3 Install on RHEL / Rocky / Alma

sudo dnf install audit

2.4 Enable and start the service

sudo systemctl enable auditd sudo systemctl start auditd 
# Check status 
sudo systemctl status auditd

From this point, the kernel can send audit events to auditd. Now we need to tell it what to watch.

3. Understanding `auditd` Basics

3.1 Key files and tools

/etc/audit/auditd.conf – main daemon configuration (log rotation, max log size, etc.)
/etc/audit/rules.d/ – persistent rule files (recommended place for your rules)
auditctl – manage rules in memory (temporary, until reboot)
augenrules – load rules from /etc/audit/rules.d/ into the kernel
ausearch, aureport – analysis tools for browsing logs

3.2 Example: View current auditd settings

sudo auditctl -s 
# Example output (shortened) 
# Enabled: 1 
# PID: 1234 
# Lost: 0 
# Backlog_limit: 8192

4. Practical `auditd` Rules You Actually Want

Let’s jump straight into practical examples. We’ll use persistent rules in /etc/audit/rules.d/ so they survive reboot.

4.1 Monitor changes to SSH configuration

SSH is your lifeline to the server. You want to know if someone edits /etc/ssh/sshd_config.

Create a new rule file:

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

Add this content:

-w /etc/ssh/sshd_config -p wa -k ssh_config_change

Line explanation:

-w – watch this file or directory
/etc/ssh/sshd_config – target file
-p wa – log writes and attribute changes
-k ssh_config_change – a human-friendly key for searching later

Load the rules:

sudo augenrules --load

Now, whenever someone edits sshd_config, it will be logged in the audit log.

4.2 Monitor a web vhost directory for changes

Let’s say your virtual host lives in /var/www/vhosts/example.com and you want to detect unexpected file changes (web shells, uploaded malware, etc.).

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

# Watch all writes and attribute changes in the vhost directory -a always,exit -F dir=/var/www/vhosts/example.com -F perm=wa -k example_vhost

Line explanation:

-a always,exit – always record events when a syscall exits
-F dir=... – filter by directory
-F perm=wa – target syscalls that write or change attributes
-k example_vhost – key to group these events

Reload rules again:

sudo augenrules --load

4.3 Track all `sudo` commands

Knowing every time someone runs sudo is very useful for investigations.

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

-w /var/log/sudo.log -p wa -k sudo_activity

Make sure your sudo is configured to log to /var/log/sudo.log (this is distro dependent). Alternatively, track the execve syscall when uid=0, but that’s more advanced and can generate a lot of events.

5. How to Read `auditd` Logs

Logs are stored in /var/log/audit/audit.log and are not meant for humans. Use ausearch and aureport instead.

5.1 Search by key

For our SSH config change rule:

sudo ausearch -k ssh_config_change

To see only recent events (last 15 minutes):

sudo ausearch -k ssh_config_change -ts recent

5.2 Generate a human-friendly report

For a high-level summary of login events:

sudo aureport -au 
# authentication report 
sudo aureport -m 
# syscall summary

This is already powerful, but manually running ausearch on multiple servers doesn’t scale. That’s where Wazuh comes in.

6. How Wazuh Works with `auditd`

Wazuh is a security platform that collects, parses, and analyzes logs from many sources, including auditd. The typical flow is:

auditd writes events to /var/log/audit/audit.log.
The Wazuh agent on the same server reads this file.
Wazuh decoders parse the audit events and create structured alerts.
Alerts are sent to the Wazuh manager and stored in the indexer.
You view and filter them in the Wazuh dashboard (or Kibana / OpenSearch Dashboards).

Let’s configure this step by step.

7. Configure Wazuh Agent to Collect `auditd` Logs

This assumes you already have a Wazuh agent installed on the Linux server and that it can talk to your Wazuh manager.

7.1 Enable audit log collection in Wazuh agent

Open the agent configuration file (on the monitored server):

sudo nano /var/ossec/etc/ossec.conf

Add (or un-comment) the following block inside the root <ossec_config> element:

<localfile> 
  <log_format>audit</log_format> 
  <location>/var/log/audit/audit.log</location> 
</localfile>

Explanation:

<localfile> – tells Wazuh to read from a local log file
<log_format>audit</log_format> – use the built-in decoder for Linux Audit logs
<location>/var/log/audit/audit.log</location> – path to the audit log

Restart the Wazuh agent:

sudo systemctl restart wazuh-agent

From now on, every event generated by your auditd rules will be sent to Wazuh.

8. Practical Example: Detecting Changes in a Web Vhost with Wazuh

Let’s tie it together using our earlier rule for /var/www/vhosts/example.com.

8.1 Trigger an audit event

On the monitored server:

sudo touch /var/www/vhosts/example.com/test-file.txt sudo echo "malicious change?" | sudo tee /var/www/vhosts/example.com/index.php >/dev/null

These operations should generate auditd events with the key example_vhost.

8.2 Verify in `auditd` directly

sudo ausearch -k example_vhost -ts recent

8.3 View the events in Wazuh Dashboard

In the Wazuh web interface:

Go to the Security events / Events section.
Filter by:
- agent.name = your server hostname
- And search for example_vhost in the data field.

You should see alerts that contain:

Which file was changed
Which user performed the action
From which process (e.g. php-fpm, bash)
Timestamp and other context

Now your audit trail is visible in a central place, with the possibility to:

Create custom dashboards (e.g. “File changes in web roots”)
Set up email or Slack alerts for specific events
Correlate audit events with other logs (SSH, sudo, web server, etc.)

9. Practical Example: Monitoring SSH Configuration Changes via Wazuh

Using our SSH rule:

sudo nano /etc/ssh/sshd_config 
# Make a small change, e.g. add a comment 
sudo systemctl reload ssh

Then, check:

sudo ausearch -k ssh_config_change -ts recent

And in Wazuh:

Filter by the rule name or by the file path /etc/ssh/sshd_config.
Optionally, build a dashboard widget that shows “Recent SSH config changes by host.”

This is extremely useful for spotting unauthorized tampering with your SSH configuration.

10. Tuning and Best Practices

10.1 Avoid excessive noise

Too many audit rules will flood your logs and make analysis harder. Some tips:

Focus on security-relevant paths: config files, web roots, database configs, authentication logs.
Avoid watching high-activity directories like /tmp or entire file systems unless really needed.
Use -F uid, -F auid, or -F exe filters to narrow down events.

10.2 Watch disk space and log rotation

In /etc/audit/auditd.conf:

max_log_file – size in MB before rotation
num_logs – how many rotated logs to keep
space_left_action, admin_space_left_action – what happens when disk is nearly full

Always ensure your /var filesystem has enough space for logs, especially when forwarding them to Wazuh for long-term retention.

10.3 Test rules before deploying widely

For each new rule:

Add it in /etc/audit/rules.d/.
Reload with augenrules --load.
Trigger a test event.
Verify in auditd and Wazuh.

Only then roll it out to additional servers using your configuration management tool (e.g. Ansible).

11. Summary

The Linux Audit Framework (auditd) is a powerful way to record exactly what happens on your server. On its own, it gives you a detailed forensic trail. Combined with Wazuh, it becomes a central, searchable, and alert-driven security monitoring solution.

In this article, you learned how to:

Install and enable auditd
Create practical audit rules for SSH, sudo, and web vhost directories
Use ausearch and aureport to inspect events
Configure the Wazuh agent to collect auditd logs
Verify that events appear in Wazuh and build real-world use cases around them

From here, you can expand your ruleset to cover more critical files, privileged commands, and sensitive directories, and then use Wazuh dashboards and alerts to turn those low-level events into actionable security insights.

If you’re building a logging and security baseline for your Linux servers, starting with auditd + Wazuh is a solid, practical choice that scales from small labs to serious production environments.

1. What Is auditd and Why Should You Care?

2. Installing and Enabling auditd

2.1 Check if auditd is already installed