Auditd is an extraordinarily powerful monitoring tool. As anyone who has ever looked at it can attest, usability
is the primary weakness. Setting up something like auditd requires a lot of pretty in-depth thought about exactly
what it is that needs auditing on the specific system in question. In the question you decided on a web server
as our example system, which is good since it's specific.
For sake of argument let's assume that there is a formal division between test/dev web servers and production
web servers where web developers do all of their work on the test/dev systems and changes to the production
environment are done in a controlled deployment.
So making those rather large assumptions, and focusing on the production system, we can get down to work. Looking at the auditd recommendation in the
CIS benchmark for RHEL5 we can start building out the following suggested ruleset:
-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa
-b 1024
-e 2
This will cause logs to be written out whenever the rmdir, unlink, stime, or setrlimit system calls exit. This should
let us know if anyone attempts to delete files or jigger with the times. We also set up specific file watches on the
files that define groups, users, passwords, and sudo access. Instead of looking at system calls for each of those an
audit log will be written every time one of those files is either:
- opened with the O_WRONLY or O_RDWR modes
- an attribute is changed
Since we've already made the assumption that we're talking about a production web server, I would recommend adding the line:
-w /var/www -p wa
This will recursively watch all of the files under the /var/www directory tree.
Now we can see the reason for the "controlled environment" assumption made earlier. Between monitoring all files in
the web root, as well as all unlink or rmdir events, this could be prohibitively noisy in a development environment. If
we can anticipate filesystem changes, such as during maintenance windows or deploy events, we can more reasonably filter
out this noise.
Combining all of this into a single, coherent, file we would want /etc/audit/audit.rules to look like
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.
# First rule - delete all
-D
# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024
-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /var/www -p wa
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa
# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2
