-
Notifications
You must be signed in to change notification settings - Fork 11
About Auditd
If your primary use case for Splunk is security, /var/log/audit/audit.log is of much greater value than /var/log/messages and /var/log/secure because they contain only a subset of what Auditd logs and of lesser precision. For example, it's possible to remotely login to a Linux machine via ssh and bypass all logging except the Auditd log. Please see below for further detail.
Auditd logs most of the following events by default:
- Authentication and Authorisation
- Runlevel changes
- Process crashes
- Anomalies detected by the kernel
- User terminal keystrokes
- Sudo
- Systemd events (e.g. service start/stop)
- System changes (e.g. when users and groups are changed)
- Filesystem access systemcalls (reads, writes, etc.)
- SELinux Access Vector Control (AVC)
- And more..
Importantly, even if a user changes their uid via su or some other means, everything they do in relation to the list above can be attributed to the original user that logged in because Auditd produces log events with the "actual/audit user id" (auid) field (which is used by the Linux Auditd app to populate the 'user' field). For this reason, disabling direct login to the root account via ssh is strongly encouraged.
With each login, a user's session is assigned a number and in just the same way as the auid field discussed above, that immutable "ses" field is logged with every Auditd log event produced during that session. This can be helpful when users have multiple sessions on a machine.
For a holistic view of how auditd (and SELinux) can be used for detection, please see: https://redhat.slides.com/dobrown/deck?token=woyFu9IW
Below are a range of Auditd configuration suggestions to maximise the value of the data you ingest.
Below is an example of an auditing rule that logs all writes and attribute changes to files in /etc:
echo "-w /etc -p wa -k etc_changes" >> /etc/audit/rules.d/audit.rules
service auditd restart
Events generated by auditing rules can be examined and automatically correlated via the Linux Auditd app's 'System Call' dashboard.
N.B. Use auditing rules with care - a rule on a very busy filesystem has the potential to produce a large volume of events. For more information and guidance, please see the auditctl man page or https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sec-Defining_Audit_Rules_and_Controls_in_the_audit.rules_file.html
TTY logging logs all keystrokes that users make (except passwords, unless explicitly configured to do so).
echo "session required pam_tty_audit.so enable=*" >> /etc/pam.d/password-auth-ac
The keystrokes are hex encoded in 'USER_TTY' and 'TTY' type events, but the TA-linux_auditd app automatically creates the human-readable and CIM-normalised 'command' field. User TTY events are easily examined via the Linux Auditd 'User TTY' dashboard.
For more information, please see: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sec-Configuring_PAM_for_Auditing.html
Even if you only enable SELinux in permissive mode (i.e. only logs denials, does not actually block anything) the Linux Auditd app for Splunk will likely detect compromise no matter how noisy and badly configured SELinux may be. As a starting point for SELinux, watch this video: https://www.youtube.com/watch?v=cNoVgDqqJmM (slides can be found here: http://people.redhat.com/tcameron/summit2010/selinux/SELinuxMereMortals.pdf)
The vendor's official documentation is also a good resource: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/index.html