Linux Auditd Framework: Writing Custom Audit Rules to Detect Unauthorized File Access

Detecting stealthy tampering, unauthorized privilege escalations, and unauthenticated file access in enterprise Linux environments requires a deterministic kernel-level auditing mechanism rather than reactive userland log scrapers. When multi-tenant hosts or mission-critical servers handle sensitive data on platforms like CpanelFree, administrators must isolate and trace every file system interaction down to the syscall invocation without degrading I/O throughput. Deploying precision audit rules within the Linux Audit Daemon (auditd) provides real-time visibility into unauthorized reads, writes, and inode modifications while maintaining sub-millisecond execution overhead.

What is the Linux Auditd Framework and How Does It Detect File Access?

The Architecture of the Linux Kernel Audit Subsystem

To write performant audit rules, systems architects must understand the path a file request traverses across the Linux kernel boundary. The audit architecture consists of three operational tiers:

• Kernel Audit Subsystem (kauditd): Hooked directly into the system call dispatch table and the Virtual File System (VFS) layer. When an application invokes a syscall to access a file, kauditd evaluates the request against active in-memory filter lists (task, exit, user, and exclude). If a rule matches, the kernel packages an audit event and places it onto a high-speed netlink socket ring buffer.
• Userland Daemon (auditd): A dedicated background process that consumes raw netlink datagrams from the kernel buffer, applies formatting, writes chronologically to /var/log/audit/audit.log, and rotates log files according to disk pressure policies.
• Audit Dispatcher & Plugins (audispd / auditd-plugins): A real-time multiplexer that forwards events to external consumers, such as centralized SIEM endpoints, Syslog daemons, or anomaly detection pipelines.

The primary advantage of this architecture over file integrity monitoring tools (such as AIDE or Tripwire) is temporal immediacy: while integrity checkers only detect changes after the fact via periodic cron hashes, auditd captures both successful and denied access attempts at the exact microsecond they occur.

Comparing Audit Methods: Naive File Watches vs. Precision Syscall Filters

Many administrators configure basic file watches using the -w /path/to/file -p rwa -k key syntax. While straightforward, naive file watches generate immense log volume on busy servers because they trigger on every single access, regardless of whether the operation was authorized or failed due to permission constraints. In high-density hosting or database environments, logging millions of routine reads exhausts I/O buffers and creates severe performance bottlenecks.

By contrast, enterprise-grade audit configurations leverage exit-filtered system call rules. By instructing the kernel to log only when a system call terminates with -EACCES (Permission Denied) or -EPERM (Operation Not Permitted), administrators isolate genuine unauthorized access attempts while ignoring millions of legitimate operations.

Production Configuration: Daemon Optimization & Ruleset Deployment

Deploying audit rules requires two complementary configuration files: the daemon performance profile (/etc/audit/auditd.conf) and the rule definition set (/etc/audit/rules.d/50-unauthorized-access.rules). Modern Linux distributions utilizing auditd 3.x+ compile individual rule files in /etc/audit/rules.d/ into a single contiguous ruleset loaded into the kernel using augenrules.

1. Production Daemon Tuning (/etc/audit/auditd.conf)

Before loading rules, optimize the userland daemon to prevent disk starvation and ensure high-throughput event processing during sustained traffic spikes:

# /etc/audit/auditd.conf - Enterprise Production Profile
local_events = yes
write_logs = yes
log_file = /var/log/audit/audit.log
log_group = root
log_format = ENRICHED
flush = INCREMENTAL_FLUSH
freq = 50
max_log_file = 200
num_logs = 10
priority_boost = 4
name_format = HOSTNAME

## Space Management & Failure Resilience
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG
admin_space_left = 100
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
use_libwrap = yes
verify_email = yes
action_mail_acct = root

2. Custom Audit Ruleset (/etc/audit/rules.d/50-unauthorized-access.rules)

The following ruleset establishes a hardened security baseline. It monitors critical configuration repositories, sensitive authentication databases, and kernel-level file access syscalls, flagging every operation that fails with EACCES or EPERM across both 64-bit and 32-bit execution layers.

## /etc/audit/rules.d/50-unauthorized-access.rules
## Enterprise Unauthorized File Access & Integrity Detection Rules

# 1. Reset existing rules and set buffer size
-D
-b 8192

# 2. Failure mode: 1 = printk notice, 2 = kernel panic (for ultra-high-security)
-f 1

# 3. Rate limiting (0 = unconstrained)
-r 0

## ====================================================================
## SECTION A: Precision Syscall Monitoring for Unauthorized Access
## Logs ANY file open/truncate/delete that terminates in EACCES or EPERM
## ====================================================================

# 64-bit Architecture - File Access Denials
-a always,exit -F arch=b64 -S open,openat,openat2,creat,truncate,ftruncate -F exit=-EACCES -k unauthorized_file_access
-a always,exit -F arch=b64 -S open,openat,openat2,creat,truncate,ftruncate -F exit=-EPERM  -k unauthorized_file_access

# 32-bit Compatibility Layer - File Access Denials
-a always,exit -F arch=b32 -S open,openat,creat,truncate,ftruncate -F exit=-EACCES -k unauthorized_file_access
-a always,exit -F arch=b32 -S open,openat,creat,truncate,ftruncate -F exit=-EPERM  -k unauthorized_file_access

# 64-bit Architecture - Unauthorized File Deletion & Renaming Attempts
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat,renameat2 -F exit=-EACCES -k unauthorized_file_deletion
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat,renameat2 -F exit=-EPERM  -k unauthorized_file_deletion

# 64-bit Architecture - Unauthorized Permission & Ownership Modification
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,chown,fchown,fchownat,lchown -F exit=-EACCES -k unauthorized_attr_change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,chown,fchown,fchownat,lchown -F exit=-EPERM  -k unauthorized_attr_change

## ====================================================================
## SECTION B: Targeted Watches on High-Value System Assets
## ====================================================================

# Authentication & Identity Repositories
-w /etc/passwd -p wa -k identity_tampering
-w /etc/shadow -p rwa -k credentials_access
-w /etc/gshadow -p rwa -k credentials_access
-w /etc/security/opasswd -p rwa -k credentials_access
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/sudoers.d/ -p wa -k privilege_escalation

# SSH Infrastructure
-w /etc/ssh/sshd_config -p wa -k sshd_config_modification
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config_modification
-w /root/.ssh/ -p rwa -k root_ssh_keys

# System Configuration & Service Control
-w /etc/systemd/ -p wa -k systemd_unit_modification
-w /etc/ld.so.conf -p wa -k dynamic_linker_tampering
-w /etc/ld.so.conf.d/ -p wa -k dynamic_linker_tampering
-w /etc/pam.d/ -p wa -k pam_tampering

# Storage & Mount Configurations
-w /etc/fstab -p wa -k filesystem_mount_tampering

## ====================================================================
## SECTION C: Audit Configuration Immutability (Self-Defense)
## ====================================================================
-w /etc/audit/ -p wa -k audit_config_tampering
-w /var/log/audit/ -p wa -k audit_log_tampering

# Make configuration immutable until system reboot (uncomment in production)
# -e 2

Testing, Verification, and Forensic Log Analysis

After creating the ruleset, load it into the active kernel and verify that the rules are operational without syntax errors:

# Compile rules from /etc/audit/rules.d/ into /etc/audit/audit.rules and load
augencules --load

# Verify active rules in the running kernel
auditctl -l

Simulating an Unauthorized Access Attempt

To confirm that our syscall rules trigger accurately on permission denial, create a test file restricted to root permissions, switch to an unprivileged account, and attempt to read it:

# Create restricted test file
touch /opt/restricted_payroll_data.db
chmod 600 /opt/restricted_payroll_data.db

# Attempt unauthorized access as an unprivileged user
su - testuser -c "cat /opt/restricted_payroll_data.db"
# Expected output: cat: /opt/restricted_payroll_data.db: Permission denied

Parsing the Generated Audit Log with ausearch and aureport

Query the audit log specifically for events tagged with our custom key unauthorized_file_access:

# Query events with enriched, human-readable translation (-i)
ausearch -k unauthorized_file_access -ts recent -i

The resulting log output reveals the full anatomical context of the intercepted system call:

type=PROCTITLE msg=audit(09/21/2026 02:45:12.894:1042) : proctitle=cat /opt/restricted_payroll_data.db
type=PATH msg=audit(09/21/2026 02:45:12.894:1042) : item=0 name=/opt/restricted_payroll_data.db inode=524312 dev=fd:00 mode=file,600 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(09/21/2026 02:45:12.894:1042) : cwd=/home/testuser
type=SYSCALL msg=audit(09/21/2026 02:45:12.894:1042) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x7ffe42b91870 a2=O_RDONLY a3=0x0 items=1 ppid=14201 pid=14202 auid=admin_alice uid=testuser gid=testuser euid=testuser suid=testuser fsuid=testuser egid=testuser sgid=testuser fsgid=testuser tty=pts1 ses=12 comm=cat exe=/usr/bin/cat subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=unauthorized_file_access

Deconstructing the Audit Record for Incident Response

Notice how thoroughly the record exposes the incident details:

• syscall=openat success=no exit=EACCES: Confirms the exact kernel call failed due to permission denial.
• name=/opt/restricted_payroll_data.db: Identifies the exact file path and inode targeted.
• exe=/usr/bin/cat & comm=cat: Identifies the executable binary invoked by the actor.
• uid=testuser: Identifies the effective user account executing the command.
• auid=admin_alice: Exposes that the user who originally authenticated via SSH was admin_alice, establishing non-repudiation even if account hopping occurred.
• key=unauthorized_file_access: Links the event directly to our custom monitoring rule for streamlined aggregation.

Automating Forensic Reporting & Anomaly Detection

In high-throughput enterprise setups, reading raw audit logs is impractical. Use built-in tools like aureport to generate executive anomaly summaries, or integrate with automated parsing scripts:

# Summarize failed system calls across the entire fleet
aureport --syscall --failed --summary

# Generate a summary of file access events
aureport --file --summary

# Report all events associated with a specific audit key
ausearch --key unauthorized_file_access --format text

By scheduling periodic summaries or streaming audit netlink events directly to your security information and event management (SIEM) solution, you can automatically generate alerts when an unusual spike in EACCES events originates from a single auid or process tree.

Frequently Asked Questions