Linux - Software Lifecycle - Install Audit

What the auditd installer Worklet does

This Automox Worklet™ installs the Linux audit package on endpoints where the audit daemon is missing. The Worklet checks for /usr/sbin/auditctl, the command-line tool that ships with the audit package. If auditctl is missing, the Worklet detects whether yum or apt-get is available on PATH, then runs the matching package install command without prompting for input.

On Debian and Ubuntu endpoints the remediation runs apt install auditd -y, which pulls the auditd binary, the audispd plugin daemon, and the default configuration files into /etc/audit/. On RHEL, CentOS, Rocky, Alma, and Fedora endpoints, the remediation runs yum install audit -y, which lays down the same components under the audit RPM. Both package managers honor the distribution defaults, so post-install the auditd unit is registered with systemd and starts on the next boot on systems where the package's post-install scriptlets enable it.

Once auditd is running, the kernel writes audit records to /var/log/audit/audit.log through the kernel audit subsystem. Rule files dropped into /etc/audit/rules.d/ are loaded on service start, so you can ship a baseline rule set with a companion Worklet and have it active everywhere auditd is present. The remediation exits 0 when the package install command succeeds and exits non-zero with stderr output when the install fails, so failures surface in the Automox activity log rather than going silent.

Why install auditd on every Linux endpoint

A Linux endpoint without auditd has no answer to the auditor's first question: who ran what, when, and from where. Without the audit subsystem there is no record of sudo invocations, no record of /etc/passwd or /etc/shadow modifications, and no record of execve() calls outside the shell history that a careful intruder will already have cleared. PCI-DSS 10.2, HIPAA 164.312(b), NIST 800-53 AU-2, and CIS Benchmark section 4.1 all require an audit subsystem that captures privileged actions and authentication events; auditd is the canonical answer on Linux.

A base image may be cloned without auditd, a developer may rebuild a server from upstream packages, or a container host may inherit a minimal Debian rootfs; each scenario leaves the host without the audit daemon and without the log stream the SOC expects to ingest. The /usr/sbin/auditctl check fires on the next evaluation, the apt or yum install runs in remediation, and the package lands on disk before CIS 4.1.1 turns up missing on the next compliance scan.

How the auditd installer works

1. Evaluation phase: The Worklet tests whether /usr/sbin/auditctl exists on the endpoint. If the file is present, auditd is already installed and the evaluation exits 0 with no further action. If the file is missing, the evaluation script writes a message to stderr and exits 1, which flags the endpoint for remediation in the Automox console.

2. Remediation phase: The remediation script uses command -v to determine the package manager, preferring yum if available and falling back to apt-get. On Red Hat-family endpoints it runs yum install audit -y. On Debian-family endpoints it runs apt install auditd -y. The script exits 0 on a successful install and exits 1 with stderr output if the install command returns non-zero, so the result appears in the Automox activity log.

auditd installation requirements

• Linux endpoint running a Debian-family distribution (Ubuntu, Debian) or a Red Hat-family distribution (RHEL, CentOS, Rocky, Alma, Fedora) with yum or apt-get on PATH

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

• Network reachability to configured package repositories (Ubuntu archive, Debian security, RHEL BaseOS, EPEL, or your internal mirror)

• Automox agent version 1.42.22 or later

• FixNow compatible, so you can install auditd on a single endpoint on demand from the Automox console without waiting for the next policy cycle

Expected state after auditd installation

After remediation, /usr/sbin/auditctl is present on the endpoint and the audit package is installed (dpkg -l auditd or rpm -q audit returns the package version). On distributions where the audit package's post-install scriptlets enable the service, run systemctl status auditd to confirm the service shows active (running); if the service is not running yet, start it with systemctl enable --now auditd. Run auditctl -s to print the daemon state, including the current backlog limit and the loaded rule count. Subsequent Worklet evaluations report the endpoint as compliant because /usr/sbin/auditctl exists, so remediation does not run again.

To validate that the daemon is recording events, run auditctl -l to list active rules and ausearch -m USER_LOGIN to confirm authentication events are flowing into /var/log/audit/audit.log. The default install ships with a minimal rule set, so to capture the events required by CIS Benchmark section 4.1 drop one or more .rules files into /etc/audit/rules.d/ – the CIS Benchmark Linux rule pack is a good starting point – then run augenrules --load or systemctl restart auditd to load them. From this point the endpoint produces the audit telemetry required for PCI-DSS 10.2, HIPAA 164.312(b), NIST 800-53 AU-2 and AU-12, and CIS Benchmark Linux section 4.1 controls, and the next Automox policy evaluation continues to enforce the auditd baseline.