Linux - Configuration - Add Audit Rules for File Integrity Monitoring

What the Linux file integrity audit Worklet does

This Automox Worklet™ enforces a baseline of Linux audit daemon (auditd) rules that emit telemetry whenever a critical system file is written or has its attributes modified. The Worklet watches /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /etc/audit/, and /var/log/ with -p wa permissions, tagging every event with a key string so the change is searchable by ausearch.

On RHEL, CentOS, Rocky, Alma, Fedora, Debian, and Ubuntu endpoints, the Worklet writes the rules into /etc/audit/audit.rules and /etc/audit/rules.d/audit.rules so the configuration survives a reboot. After the rules are appended, it loads them into the running kernel with augenrules --load and verifies that the auditd service is active with systemctl is-active auditd.

The auditd path produces native, kernel-mediated change events without the disk and CPU footprint of a baseline-and-diff scanner like AIDE or Tripwire. Each evaluation pass uses grep -Fxq against both /etc/audit/audit.rules and /etc/audit/rules.d/audit.rules to confirm every watch rule is still present, so a single missing rule on a single host does not silently turn into an audit gap weeks later.

Why audit Linux file integrity at fleet scale

File integrity monitoring shortens the window between a privileged file change and the security team seeing it. Attackers modify /etc/passwd to add a UID 0 account, write to /etc/shadow to rotate a password hash, drop a file under /usr/bin to shim a system binary, or truncate /var/log entries to cover the trail. CIS Benchmark for Linux 6.3.x calls out auditd rules for exactly these paths, NIST 800-53 control AU-2 requires the corresponding event capture, and PCI-DSS 10.5.5 requires file integrity monitoring on logs.

The auditd ruleset is also one of the easiest controls to lose without noticing. A package post-install script can rewrite /etc/audit/rules.d/audit.rules with vendor defaults, a configuration management run can drop a -D directive that clears every rule in memory, and augenrules --load only reflects what was on disk at the last reload. The Worklet enforces the baseline continuously, so the next evaluation catches a missing rule before it becomes a CIS Benchmark 6.3.x finding, a SOC 2 CC7.2 exception, or a forensic dead end. The published audit rule set acts as the source of truth, and each policy run reconciles /etc/audit/rules.d/ and the live auditctl ruleset against it across every server, container host, and developer workstation under management.

How auditd file integrity enforcement works

1. Evaluation phase: The Worklet reads /etc/audit/audit.rules and /etc/audit/rules.d/audit.rules and confirms that watch rules exist for /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /etc/audit/, and /var/log/ with their respective key tags (passwd_changes, shadow_changes, group_changes, gshadow_changes, audit_changes, log_changes). If any rule is missing from either file, the endpoint is flagged non-compliant and remediation is scheduled.

2. Remediation phase: The Worklet appends the missing -w <path> -p wa -k <key> entries to both /etc/audit/audit.rules and /etc/audit/rules.d/audit.rules, then runs augenrules --check to validate the syntax. If the check passes, augenrules --load compiles and loads the persistent ruleset into the kernel without a reboot. The Worklet then runs systemctl is-active --quiet auditd to confirm the service is running and reports a non-zero exit with a stderr message in Automox activity logs if augenrules rejects the syntax or fails to load.

Linux file integrity audit requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Debian, or Ubuntu with the audit and audit-libs packages installed

• auditd service installed and either active or able to be started by the Automox agent

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• augenrules utility on the path (shipped with the audit package on every supported distribution)

• Sufficient disk space under /var/log/audit/ for the audit.log ring buffer; verify max_log_file and num_logs in /etc/audit/auditd.conf if you expect high write volume

• Downstream collector for the audit.log stream (Splunk Universal Forwarder, Fluent Bit, Wazuh, syslog forwarding) if you intend to centralize the FIM telemetry for SIEM correlation

Expected Linux file integrity audit state

After the Worklet runs, every write or attribute change to /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /etc/audit/, or /var/log/ produces an audit event in /var/log/audit/audit.log tagged with one of passwd_changes, shadow_changes, group_changes, gshadow_changes, audit_changes, or log_changes. Run auditctl -l to list the loaded rules, ausearch -k passwd_changes to pull every event for that key, or aureport -f to summarize file events for the last 24 hours.

The rules persist across reboots because they live in /etc/audit/rules.d/audit.rules, and they reload automatically on auditd restart. The next Automox policy evaluation reports the endpoint as compliant without applying remediation again. If an administrator or a configuration management tool removes a rule from /etc/audit/audit.rules, the following evaluation parses both files, identifies the missing -w directive, and the remediation pass re-appends the entry and runs augenrules --load before the auditor finds it first.