Overview
In enterprise and government environments, systems must meet strict security baselines to be considered trustworthy. One of the most widely adopted standards is the STIG (Security Technical Implementation Guide), a set of configuration guidelines published by the Defense Information Systems Agency (DISA) to harden operating systems against known vulnerabilities.
In this lab, I configured the Linux auditd service on a Red Hat host to load the precompiled STIG rule set. The goal is to give the system visibility into whether it meets STIG compliance requirements by actively tracking the security-relevant events those rules define.
Why This Matters
The Linux audit daemon (auditd) is the kernel-level system responsible for recording security events, things like file access, privilege escalation, system calls, and user logins. Out of the box, it ships with a minimal rule set. However, Red Hat provides prebuilt rule files for compliance frameworks like STIG, PCI-DSS, and NISPOM, located at:
/usr/share/doc/audit-*/rules/
By appending these rules to the active audit configuration, we tell the kernel exactly what events to monitor according to STIG requirements. This is a foundational step before running any compliance scan or audit report.
Environment
| Detail | Value |
|---|---|
| OS | Red Hat Enterprise Linux (EC2 instance) |
| Audit version | audit-2.8.5 |
| Connection | SSH via MobaXterm |
| Privilege level | cloud_user → escalated to root |
Step 1 - Connect to the Server
I connected to the cloud instance over SSH using MobaXterm:
ssh cloud_user@52.87.246.170Output:
Warning: Permanently added '52.87.246.170' (ED25519) to the list of known hosts.
cloud_user@52.87.246.170's password:
X11 forwarding request failed on channel 0
[cloud_user@ip-10-0-1-77 ~]$
Step 2 - Back Up the Existing Audit Rules
Before making any changes to a system configuration file, it’s critical to create a backup. This lets us restore the original state if something goes wrong.
sudo cp /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules_backupWhat I learned here: My first attempt ran the command without sudo and hit a permission error, the audit rules directory is root-protected. This is expected and is itself a good sign that the system is properly restricting access to sensitive config files.
cp: failed to access '/etc/audit/rules.d/audit.rules_backup': Permission denied
Running with sudo resolved it immediately.
Step 3 - Locate the STIG Rule Files
The installed version on this server was audit-2.8.5. I discovered this by using tab-completion to explore the directory:
cd /usr/share/doc/au<TAB>audit-2.8.5/ authconfig-6.2.8/
I navigated to the correct path:
cd /usr/share/doc/audit-2.8.5/rules/Step 4 - Apply the STIG Rules
This is the core action of the lab. The 30-stig.rules file contains the STIG-specific audit rules, and 99-finalize.rules adds a locking directive that prevents further modification of the ruleset at runtime (a security measure in itself).
I needed full root access, even sudo on a redirect (>>) is blocked because the shell opens the file before sudo can elevate. The fix is to escalate to a proper root shell first:
sudo -iThen from the root shell:
cd /usr/share/doc/audit-2.8.5/rules/
cat 30-stig.rules 99-finalize.rules >> /etc/audit/rules.d/audit.rulesWhy cat with >>? We’re appending the STIG rules to the existing audit.rules file rather than replacing it. This preserves any baseline rules already configured while adding the STIG compliance layer on top.
Step 5 - Restart and Verify auditd
Configuration files are read at service startup, so we need to restart auditd to load the new rules into the kernel:
service auditd restartStopping logging: [ OK ]
Redirecting start to /bin/systemctl start auditd.service
Then I verified the service came back up and is actively running:
service auditd statusOutput:
● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2026-05-13 21:08:19 UTC; 8s ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 1341 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
Process: 1336 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)
Main PID: 1337 (auditd)
CGroup: /system.slice/auditd.service
└─1337 /sbin/auditd
May 13 21:08:19 ip-10-0-1-77.ec2.internal augenrules[1341]: enabled 1
May 13 21:08:19 ip-10-0-1-77.ec2.internal augenrules[1341]: backlog_limit 8192
May 13 21:08:19 ip-10-0-1-77.ec2.internal systemd[1]: Started Security Auditing Service.
Key things to confirm in this output:
| Field | Expected Value | Why It Matters |
|---|---|---|
Active | active (running) | Service is live |
ExecStartPost | status=0/SUCCESS | augenrules --load compiled and loaded rules without errors |
enabled | 1 | Audit enforcement is on |
failure | 1 | Audit failure mode is set (logs and continues on error) |
backlog_limit | 8192 | Buffer size for event queue, sufficient for normal workloads |
The line augenrules --load with status=0/SUCCESS is especially important, it confirms that augenrules parsed and loaded our newly appended STIG rules into the running kernel successfully.
Troubleshooting Notes
| Issue | Cause | Fix |
|---|---|---|
Permission denied on cp | Missing sudo | Prefix with sudo |
No such file or directory on cd | Lab doc referenced older package version (2.8.1) | Use tab-completion to find installed version (2.8.5) |
Permission denied on >> redirect even with sudo | Shell redirects run as current user, not sudo | Escalate to root with sudo -i first |
Key Concepts Reinforced
- auditd is the Linux Audit Daemon, it hooks into the kernel to record security-relevant system calls and file access events.
- STIG rules define what to monitor;
auditdis the engine that does the monitoring. augenrulescompiles all.rulesfiles in/etc/audit/rules.d/into a single active ruleset and loads it into the kernel, this happens automatically on service restart.99-finalize.rulessets the audit configuration to immutable mode, meaning the rules can’t be changed without a reboot. This is a deliberate STIG hardening requirement.- File redirect permissions, even with
sudo,>>redirects are handled by the shell as the invoking user. Always escalate to a root shell for operations involving privileged file writes.
Takeaway
This lab is a practical introduction to compliance-driven security configuration. Rather than manually writing audit rules from scratch, Red Hat provides precompiled, standards-aligned rule sets that can be applied in minutes. The real skill is understanding why each step exists, the backup, the escalation strategy, the service restart, and being able to adapt when the environment doesn’t match the documentation exactly.