Linux Auditd Setup on VPS: Monitor All System Activity

The Linux Audit Daemon (auditd) is a kernel-level activity logging system embedded in the Linux kernel since version 2.6. Unlike traditional syslog, auditd captures every syscall that matches your rules — who opened which file, who modified /etc/passwd, who used sudo and when.

For VPS environments requiring compliance with PCI-DSS, HIPAA, or ISO 27001, auditd is a mandatory component. This guide walks you through installation, writing effective audit rules, and analyzing logs with ausearch and aureport.

Prerequisites

• VPS running Ubuntu 20.04/22.04/24.04 or Debian 11/12 (or RHEL/AlmaLinux)
• Root or sudo access
• At least 2 GB of disk space for audit logs

Step 1: Install auditd

Install on Ubuntu/Debian:

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

Install on RHEL/AlmaLinux/Rocky Linux:

sudo dnf install -y audit audit-libs

Enable and start the service:

sudo systemctl enable auditd
sudo systemctl start auditd
sudo systemctl status auditd

Step 2: Understanding the auditd Architecture

auditd consists of three main components:

Step 3: Configure auditd.conf

Edit the main configuration file:

sudo nano /etc/audit/auditd.conf

Recommended settings:

# Maximum log file size (MB) before rotation
max_log_file = 50

# Number of log files to retain
num_logs = 10

# Action when disk is full: SUSPEND stops logging, ROTATE cycles files
disk_full_action = ROTATE

# Action when disk space gets low (space_left in MB)
space_left = 500
space_left_action = email
action_mail_acct = root

# Always append log entries
write_logs = yes
log_format = ENRICHED

Restart auditd after configuration changes:

sudo systemctl restart auditd

Step 4: Writing Audit Rules

Create a custom rules file:

sudo nano /etc/audit/rules.d/99-custom.rules

Essential rules for any VPS:

# Delete all existing rules
-D

# Set buffer size large enough
-b 8192

# Rate-limit to prevent log flooding
--backlog_wait_time 60000

# === Authentication ===
# Log all login/logout events
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-w /var/log/wtmp -p wa -k logins
-w /var/log/btmp -p wa -k logins

# === User/Group Management ===
-w /etc/passwd -p wa -k user_changes
-w /etc/shadow -p wa -k user_changes
-w /etc/group -p wa -k user_changes
-w /etc/gshadow -p wa -k user_changes
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# === SSH Configuration ===
-w /etc/ssh/sshd_config -p wa -k ssh_config

# === Network Configuration ===
-w /etc/hosts -p wa -k network_config
-w /etc/resolv.conf -p wa -k network_config

# === Privileged Commands ===
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k privileged
-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged

# === Kernel Module Loading ===
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules

# === Crontab Changes ===
-w /etc/cron.d/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

# === Unsuccessful File Access ===
-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat -F exit=-EACCES -k access
-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat -F exit=-EPERM -k access

# Lock rules to prevent runtime modification
-e 2

Load rules without rebooting:

sudo augenrules --load
sudo auditctl -l

Step 5: Search Logs with ausearch

ausearch provides structured searching of audit logs:

Find events related to /etc/passwd changes:

sudo ausearch -f /etc/passwd
sudo ausearch -k user_changes

Find events by a specific user:

sudo ausearch -ua 1001
# Or by username
sudo ausearch -ua john

Find events in a specific time range:

sudo ausearch -ts "09/15/2026 07:00:00" -te "09/15/2026 08:00:00"

Find failed login attempts:

sudo ausearch -m USER_LOGIN -sv no

Step 6: Generate Reports with aureport

aureport produces summary reports from audit logs:

# Overall summary
sudo aureport

# Authentication summary
sudo aureport -au --summary

# Failed logins report
sudo aureport --login --failed

# Syscall summary
sudo aureport -s --summary

# Users who ran sudo
sudo aureport -x --summary | grep sudo

Step 7: Remote Audit Log Forwarding

For maximum security, send logs to a separate remote server to prevent attackers from deleting evidence:

# Install audispd-plugins
sudo apt install -y audispd-plugins

# Edit /etc/audit/plugins.d/au-remote.conf
active = yes
direction = out
path = /sbin/audisp-remote
type = always
args = REMOTE_SERVER_IP 60
format = string

On the remote log receiver:

# In /etc/audit/auditd.conf on the remote server
tcp_listen_port = 60
tcp_listen_queue = 5
tcp_max_per_addr = 1

Verify auditd is Working Correctly

# Check service status
sudo systemctl status auditd

# List loaded rules
sudo auditctl -l

# View audit system stats
sudo auditctl -s

# Test: modify a monitored file and check the log
echo "test" | sudo tee -a /etc/hosts
sudo ausearch -k network_config -ts today

# Confirm log is being written
sudo tail -20 /var/log/audit/audit.log

Troubleshooting Common Issues

Error: "backlog limit exceeded"

Occurs when events are generated faster than the daemon can write them, causing events to be dropped.

# Increase buffer size at runtime
sudo auditctl -b 16384

# Or set permanently in rules file
echo "-b 16384" | sudo tee -a /etc/audit/rules.d/99-custom.rules
sudo augenrules --load

Error: "audit: audit_backlog=322 > audit_backlog_limit=320"

Increase the kernel backlog limit:

sudo sysctl -w kernel.audit_backlog_limit=8192
echo "kernel.audit_backlog_limit=8192" | sudo tee -a /etc/sysctl.d/99-audit.conf

auditd fails to start: "Cannot open /var/log/audit"

sudo mkdir -p /var/log/audit
sudo chmod 700 /var/log/audit
sudo chown root:root /var/log/audit
sudo systemctl start auditd

ausearch returns no results

Verify the key name is correct and logs haven't been rotated away:

# Search without a key filter
sudo ausearch -m SYSCALL -ts recent

# Confirm the log file exists and has content
ls -lh /var/log/audit/audit.log
sudo wc -l /var/log/audit/audit.log

Audit logs growing too large

# Force immediate log rotation
sudo service auditd rotate

# Find which rules generate the most events
sudo aureport -s --summary | head -20

# Consider removing low-value rules
sudo auditctl -l

Frequently Asked Questions

How is auditd different from syslog?

syslog captures events that applications voluntarily send — the application must choose to log something. auditd works at the kernel level and captures every syscall matching your rules automatically, regardless of the application. This makes audit logs far harder to bypass and suitable for forensic evidence in security incidents.

Does auditd impact server performance?

It depends on the number and type of rules. With standard monitoring rules on a typical VPS, the overhead is 1–3% CPU. To minimize overhead, avoid monitoring high-frequency syscalls like read and write on busy files; instead monitor specific critical files and configuration paths.

Can I send audit logs to a SIEM like Wazuh?

Yes — the Wazuh agent reads /var/log/audit/audit.log directly and automatically converts audit events into actionable alerts. This makes auditd the most important log source for any SIEM on Linux. If you haven't set up a SIEM yet, check out our guide on installing Wazuh SIEM on VPS.