Complete guide to installing and configuring auditd on a Linux system to monitor security events and generate detailed logs.
This advanced tutorial is reserved for premium members.
.rules files placed in /etc/audit/rules.d/ are not picked up on the fly: they must be compiled and loaded with sudo augenrules --load. Then confirm that the daemon is actually running with sudo systemctl status auditd, and that it is enabled at boot via sudo systemctl enable auditd. Without those two steps, your rule is just a text file with no effect.-w declares the path to watch. -p filters the kinds of access: w for writes and a for attribute changes, hence the classic wa on a sensitive file such as /etc/shadow. -k attaches an arbitrary key to the generated events, here shadow_changes, which lets you extract them later in a single command with sudo ausearch -k shadow_changes.-k key on every rule, then query it with sudo ausearch -k <key>. Without a key you are reduced to grepping a very dense /var/log/audit/audit.log. Other useful filters round out the search: sudo ausearch -sc execve -sv yes for successful execve calls, or sudo ausearch -ua 1001 for every event tied to a given user.ausearch extracts individual events matching precise criteria: key, syscall, user, success or failure. aureport does not return raw events but aggregated summaries: aureport -l for login attempts, aureport -s for an overall summary of events, aureport -au -i --failed for authentication failures. In practice you start from aureport to spot an anomaly, then drill down into the detail with ausearch.execve rule. Then set the file size, the rotation and the disk-space policy in /etc/audit/auditd.conf, before the partition hosting /var/log/audit/ fills up.Did you enjoy this article?
Comments