Linux auditd: Improving Audit Logging in Linux

If you watch any webinars on things like Threat Hunting or where SIEM / UEBA / SOAR platforms show off great detection results, remember it always matters that they start with robust information in the logs themselves. Linux is capable of generating those kinds of logs, we just have to enable them.

Last month, we showed how to use GPO to craft good, formal, audit logging thus here we will review how to create robust auditd functionality in Linux. While we use RHEL (CentOS) as an example, it works the same way in Ubuntu.

The overall goal is to improve the value of the logs sourced from the system, so your SIEM / UEBA / SOAR platform can take a better advantage in terms of detection, alarming, and reporting.

Now the meat of the story.

Below is a basic config we will use, again if you are already familiar with auditd, please edit/choose what you like as well as sharing your modification rationale with us! For example, our config does remove any existing rules, which might matter. In a default configuration this is helpful as there are none, but if you have a robust configuration, ours may overwrite yours.

The overall goal with our changes is to push the logs to syslog, then off system, thus you may choose to also write locally, but there is really no need if we are collecting elsewhere.

Please take the config below and place it in: /etc/audit/rules.d/local.rules

  • Edit /etc/audit/auditd.conf , and leave or change log_format to ‘RAW’
  • Edit /etc/audit/auditd.conf and change write_logs to ‘no’
  • Edit /etc/audispd/plugins/syslog.conf and set ‘active = yes’

# Custom auditd rules to cover best practices for system monitoring

# Created by: Castra Consulting <info@castraconsulting.com>

# Last modified: 2019-10-14

# remove existing rules

-D

# increase audit buffer size

-b 8192

# set failure mode to panic

#-f 2

# time change

-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k time-change

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change

-a always,exit -F arch=b32 -S clock_settime -F a0=0 -k time-change

-a always,exit -F arch=b64 -S clock_settime -F a0=0 -k time-change

-w /etc/localtime -p wa -k time-change

# mount/umount

-a always,exit -F arch=b64 -S mount -S umount2

-a always,exit -F arch=b32 -S mount -S umount -S umount2

# file ownership changes

-a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

# Extended attribute operations

-a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr

-a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr

# special files

-a always,exit -F arch=b32 -S mknod -S mknodat

-a always,exit -F arch=b64 -S mknod -S mknodat

# host or domain name changes

-a always,exit -F arch=b32 -S sethostname -S setdomainname

-a always,exit -F arch=b64 -S sethostname -S setdomainname

# could indicate someone trying to do something bad or just debugging

-a always,exit -F arch=b32 -S ptrace -k paranoid

-a always,exit -F arch=b64 -S ptrace -k paranoid

# could be an attempt to bypass audit or simply legacy program

-a always,exit -F arch=b32 -S personality -F a0!=4294967295 -k paranoid

-a always,exit -F arch=b64 -S personality -F a0!=4294967295 -k paranoid

# watch module insertion

-w /sbin/insmod -p x -k modules

-w /sbin/rmmod -p x -k modules

-w /sbin/modprobe -p x -k modules

-a always,exit -F arch=b32 -S init_module -S delete_module -k modules

-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

# monitor /etc for add/del/change

-w /etc/ -p wa

-w /var/ossec/etc/ -p wa

# lock config at the end of rules

-e 2 

  • Regenerate the audit rules with: augenrules
  • Restart the audit service with: service auditd restart
  • Configure auditd to start at boot time with: systemctl enable auditd

And of course, we need some basic method to get the logs we are about to generate, off the system, and into your favorite SIEM. In our examples, we are using syslog, and many of you may already be using syslogd or syslog-ng. Please contact us for those configurations.

While it is likely you may be using a simple *.* in your master rsyslog.conf file, it’s preferable to use a custom file in /etc/rsyslog.d, we created a file called audit.conf and populated it like this:

if $programname contains 'audisp' then @@SIEM_COLLECTION_IP:514 & stop

Note we are using @@ to send via TCP, and yes the default TCP port for syslog should be 601, however, most still use UDP and TCP 514 for logs currently. Please edit as your see fit for your environment and remember to restart rsyslog.

That’s it! Almost every UEBA / SIEM / SOAR platform will be able to parse this natively and you can rest better knowing you are looking for things that may define characteristics of unwanted access, changes, or installations on your Linux systems.

Please share any cool auditd functions you have put in place also, we love learning.

Please feel free to contact us with any questions, concerns, or corrections!