{"id":371,"date":"2026-10-09T05:48:51","date_gmt":"2026-10-09T12:48:51","guid":{"rendered":"https:\/\/blog.canutethegreat.com\/index.php\/2026\/10\/09\/auditd-what-to-log-for-investigations\/"},"modified":"2026-10-20T20:23:18","modified_gmt":"2026-10-21T03:23:18","slug":"auditd-what-to-log-for-investigations","status":"publish","type":"post","link":"https:\/\/blog.canutethegreat.com\/index.php\/2026\/10\/09\/auditd-what-to-log-for-investigations\/","title":{"rendered":"auditd and what to log so an investigation is possible"},"content":{"rendered":"\n

Part 3 of 4 in the Hardening a Linux server series. Earlier parts: Part 1, SSH hardening<\/a> and Part 2, systemd sandboxing<\/a>.<\/em><\/p>\n\n\n\n

The first question in almost every Linux intrusion investigation is “what did they run?”, and the honest answer on most servers is “no idea”. Shell history is a file the attacker controls; clearing it is common enough to have its own MITRE ATT&CK entry (T1070.003). The application logs show the request that got them in and then nothing. The auth log shows a sudo or two. Everything in between is gone.<\/p>\n\n\n\n

The Linux audit subsystem fixes that, and it’s been in the kernel since 2.6. The kernel emits records for the events you ask about, auditd<\/code> writes them to disk, and the records carry the one field that makes them worth having: the audit UID.<\/p>\n\n\n\n

Why auid is the whole point<\/h2>\n\n\n\n
\"Pipeline<\/figure>\n\n\n\n

When a user logs in, pam_loginuid<\/code> stamps their session with a login UID, auid<\/code> in audit records. It survives sudo<\/code>, su<\/code>, setuid binaries and daemonizing. So when someone runs sudo -i<\/code> and then deletes a log file, the event says uid=0<\/code> and also auid=1004<\/code>, which is the human who logged in. Syslog can’t give you that.<\/p>\n\n\n\n

Services started by systemd at boot have no login UID. Unset shows up as 4294967295 (newer auditctl<\/code> also accepts unset<\/code>). Filtering on auid>=1000 -F auid!=4294967295<\/code> therefore means “actions traceable to a human session”, which is how you keep the volume sane.<\/p>\n\n\n\n

A rule set that answers real questions<\/h2>\n\n\n\n

Rules live in \/etc\/audit\/rules.d\/*.rules<\/code> and are compiled by augenrules --load<\/code>. Here is a compact starting point. I’m not trying to be exhaustive; Florian Roth’s public auditd rule set on GitHub is a good, much longer reference.<\/p>\n\n\n\n

## buffer and failure behaviour\n-D\n-b 8192\n--backlog_wait_time 60000\n-f 1\n\n## identity and privilege configuration\n-w \/etc\/passwd -p wa -k identity\n-w \/etc\/shadow -p wa -k identity\n-w \/etc\/group -p wa -k identity\n-w \/etc\/sudoers -p wa -k priv_config\n-w \/etc\/sudoers.d\/ -p wa -k priv_config\n-w \/etc\/ssh\/sshd_config -p wa -k sshd_config\n-w \/etc\/ssh\/sshd_config.d\/ -p wa -k sshd_config\n\n## persistence locations\n-w \/etc\/cron.d\/ -p wa -k persistence\n-w \/etc\/crontab -p wa -k persistence\n-w \/var\/spool\/cron\/ -p wa -k persistence\n-w \/etc\/systemd\/system\/ -p wa -k persistence\n-w \/root\/.ssh\/ -p wa -k persistence\n\n## commands run by humans (both ABIs)\n-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec\n-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec\n\n## kernel modules, time, tracing\n-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k modules\n-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_change\n-a always,exit -F arch=b64 -S ptrace -k tracing\n\n## access denied to humans\n-a always,exit -F arch=b64 -S open -S openat -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access_denied\n-a always,exit -F arch=b64 -S open -S openat -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access_denied\n\n## lock the configuration until reboot\n-e 2<\/code><\/pre>\n\n\n\n
Every rule has a -k<\/code> key. That’s what you search by later, and it’s what your SIEM will alert on. Name them for the question they answer.<\/p>\n\n\n\n
The arch=b32<\/code> execve rule is there on purpose. A 64-bit kernel with 32-bit compatibility still accepts 32-bit syscalls, and a rule that only matches b64<\/code> misses a statically linked 32-bit binary entirely. Older hardening benchmarks list both for this reason.<\/p>\n\n\n\n
Choices that matter more than the rules<\/h2>\n\n\n\n
-e 2<\/code> makes the audit configuration immutable until the next reboot. Without it, an attacker who gets root runs auditctl -D<\/code> and your logging stops silently. With it, they have to reboot the machine to change the rules, and a reboot is loud.<\/p>\n\n\n\n
-f<\/code> sets what happens when the kernel can’t log: 0 is silent, 1 logs a kernel message, 2 panics the machine. Panic-on-audit-failure sounds strict and is occasionally a compliance requirement, but on most servers it hands an attacker who can flood the audit backlog a way to crash the box. I use 1 and alert on lost events instead. auditctl -s<\/code> shows the lost<\/code> counter, and it should stay at zero.<\/p>\n\n\n\n
-b<\/code> and --backlog_wait_time<\/code> size the kernel buffer and how long a process blocks when that buffer is full. Too small and you drop events during a burst, which is exactly when the attacker is busy.<\/p>\n\n\n\n
Then there’s volume. Full execve logging on a build server or a box running a lot of short-lived processes generates enormous logs. That’s why the rule above only covers human sessions. If a service account matters (the one your web app runs as, say), add a targeted rule with -F uid=<\/code> for that account rather than logging every process on the machine.<\/p>\n\n\n\n
Reading it back<\/h2>\n\n\n\n
Raw audit.log<\/code> is famously unpleasant, one event split across several records. ausearch<\/code> stitches them together and -i<\/code> translates numeric IDs to names:<\/p>\n\n\n\n
ausearch -k user_exec --start today -i\nausearch -k identity -ts 10\/09\/2026 06:00:00 -i\naureport -x --summary\naureport --login --failed<\/code><\/pre>\n\n\n\n
For anything beyond a single host, send the records somewhere else. The audisp-remote<\/code> plugin ships them over the network to a central auditd<\/code>, or you can have a log shipper tail the file. Laurel, a plugin from the threathunters.io folks, rewrites the multi-record mess into one JSON line per event with the process tree attached, which SIEMs handle much better.<\/p>\n\n\n\n
Following a session<\/h2>\n\n\n\n
Here’s why the keys and the auid<\/code> field pay off. Say the persistence<\/code> key fires because something wrote into \/etc\/cron.d\/<\/code>. The event shows the executable that did the write, the working directory, auid<\/code>, and a ses=<\/code> value, which is the kernel’s ID for that login session. That session number is the thread you pull:<\/p>\n\n\n\n
ausearch -k persistence --start recent -i\nausearch --session 412 --raw | aureport -x -i\nausearch -ua 1004 --start today -k user_exec -i<\/code><\/pre>\n\n\n\n
The second command lists every executable that login session ran, in order, including the ones run through sudo<\/code>. In practice that’s the difference between “someone added a cron job” and “this account logged in from this address, downloaded this file, ran it as root, then added a cron job”, which is the story an incident report needs.<\/p>\n\n\n\n
The things auditd doesn’t cover<\/h2>\n\n\n\n
A few more pieces round it out. Make the journal persistent (Storage=persistent<\/code> in journald.conf<\/code>), otherwise it lives in \/run<\/code> and disappears at reboot. Set LogLevel VERBOSE<\/code> in sshd so logins record the key fingerprint, as covered in part 1. Make sure every host runs chrony or another NTP client, because an investigation across five machines with clocks four minutes apart turns into an argument about ordering.<\/p>\n\n\n\n
And send everything off the host quickly. Logs that sit only on the compromised machine are evidence the attacker can edit. The immutable flag stops them changing the rules. It doesn’t stop root from truncating \/var\/log\/audit\/audit.log<\/code> after the fact. A remote copy that the server can append to and never delete from is what turns these logs into evidence.<\/p>\n\n\n\n
The final part of this series is about patching, which is how you keep most of these investigations from being needed in the first place.<\/p>\n\n\n\n
Other parts of the Hardening a Linux server series: Part 1: SSH hardening beyond “disable root login”<\/a>, Part 2: Least privilege with systemd sandboxing<\/a>, Part 4: Patching without fear<\/a>.<\/em><\/p>\n\n","protected":false},"excerpt":{"rendered":"
Part 3 of 4 in the Hardening a Linux server series. Earlier parts: Part 1, SSH hardening and Part 2, systemd sandboxing. The first question in almost every Linux intrusion investigation is “what did they run?”, and the honest answer on most servers is “no idea”. Shell history is a file the attacker controls; clearing […]<\/p>\n","protected":false},"author":1,"featured_media":373,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,21],"tags":[46,103,88,35,45],"class_list":["post-371","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-security","tag-auditd","tag-forensics","tag-hardening-a-linux-server-series","tag-incident-response","tag-logging"],"_links":{"self":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/371","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/comments?post=371"}],"version-history":[{"count":1,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/371\/revisions"}],"predecessor-version":[{"id":395,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/371\/revisions\/395"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/media\/373"}],"wp:attachment":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/media?parent=371"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/categories?post=371"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/tags?post=371"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}