The hardest events to audit are events originating from administrative accounts, because they have the power do muddy any trace. This post will describe a way to salvage some of them, and to make sure you can trace non malicious root activity to a specific person. If you do not need that kind of accountability, then I suggest you just log as root on the servers, it will decrease the attack surface.
The first action is pretty obvious : you should have a nominative account for all root users, and make sure they can sudo to root (or better, use a simpler tool like calife). Then you should make sure nobody can log as root. On my servers I forbid password authentication and check the content of the authorized_keys file for root. The root login is not disabled because some scripts will need it.
Add this line to /etc/pam.d/common-session :
session required pam_loginuid.so
This will ensure that the login uid is tracked and can be linked to any subsequent action, even after privileges have been elevated.
Install auditd, and configure it as follows :
- Add this rule to auditd.rules, to track all actions by root that could lead to modifications in the filesystem :
-a always,exit -F euid=0 -F perm=wxa -k PCIDSS.10.2.2
- In auditd.conf, you should make sure you log everything to syslog (you have centralized logging set up, right ?), so make sure those options look like this :
log_format = NOLOG dispatcher = /sbin/audispd
- Finally, activate the syslog plugin of audisp (set active=yes in /etc/audisp/plugins.d/syslog.conf)
There are probably a few rules you will need to add in audit.rules, such as the time modification system calls, or file modification in sensitive directories that originate from non root users.
Hopefully this should not catch too much activity, as auditd logs are pretty verbose and can fill hard drives pretty quickly.