Auditd was recommended in an answer to Linux command logging?

The default install on Ubuntu seems to barely log anything. There are several examples that come with it (capp.rules, nispom.rules, stig.rules) but it isn't clear what the performance impact of each would be, nor what sort of environment or assumptions each would be best suited for.

What would be the best starting point for deploying auditd on, lets say, a web server? This would include an audit.rules file, settings to enable sending the audit log stream to a remote machine in real time, and the simplest of tools to see what has been logged.

Next, how about a typical desktop machine?

Update: dannysauer notes that for security it is important to start with the goal, and I agree. But my main intent is to spark some more useful explanations of the usage of this tool, and see a worked example of it in action, together with performance and storage implications, etc. If that already exists and I missed it, please point to it. If not, I'm suggesting that an example be created for one of the more common scenarios (e.g. a simple web server, running your stack of choice), where the goal might be to preserve information in case of a break-in to help track back to find out where the penetration started. If there is a more suitable or attainable goal for use in e.g. a small business without a significant IT staff, that would help also.


3 Answers 3


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:

  1. opened with the O_WRONLY or O_RDWR modes
  2. 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

# 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
  • 2
    Thanks - very helpful! What do you use to analyze the output?
    – nealmcb
    Commented Jul 13, 2011 at 14:06
  • 1
    BTW the auditd package ships with some example configuration files based on a few standards. They can be found at /usr/share/doc/auditd/examples/. Of course you will still want to tailor them for your individual needs.
    – Jon-Erik
    Commented Aug 14, 2014 at 15:51
  • Is it possible to log to auditd from an application(like done with rsyslog)?
    – ransh
    Commented Aug 31, 2018 at 9:47

Update: This article is a nice explanation of auditd rules and gives examples for each event you might want to log:


Check out the bug report here:


They give a very long example file which contains many important changes that might be made to a system. Copied below for convenience (with slight modifications):

## Remove any existing rules

## Buffer Size
## Feel free to increase this if the machine panic's
-b 8192

## Failure Mode
## Possible values are 0 (silent), 1 (printk, print a failure message),
## and 2 (panic, halt the system).
-f 1

## Audit the audit logs.
## successful and unsuccessful attempts to read information from the
## audit records; all modifications to the audit trail
-w /var/log/audit/ -k auditlog

## Auditd configuration
## modifications to audit configuration that occur while the audit
## collection functions are operating.
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k audispconfig

## Monitor for use of audit management tools
-w /sbin/auditctl -p x -k audittools
-w /sbin/auditd -p x -k audittools

## special files
-a exit,always -F arch=b32 -S mknod -S mknodat -k specialfiles
-a exit,always -F arch=b64 -S mknod -S mknodat -k specialfiles

## Mount operations
-a exit,always -F arch=b32 -S mount -S umount -S umount2 -k mount
-a exit,always -F arch=b64 -S mount -S umount2 -k mount

## changes to the time
-a exit,always -F arch=b32 -S adjtimex -S settimeofday -S stime -S clock_settime -k time
-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time

## Use stunnel
-w /usr/sbin/stunnel -p x -k stunnel

## cron configuration & scheduled jobs
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/crontabs/ -k cron

## user, group, password databases
-w /etc/group -p wa -k etcgroup
-w /etc/passwd -p wa -k etcpasswd
-w /etc/gshadow -k etcgroup
-w /etc/shadow -k etcpasswd
-w /etc/security/opasswd -k opasswd

## monitor usage of passwd
-w /usr/bin/passwd -p x -k passwd_modification

#Monitor for use of tools to change group identifiers
-w /usr/sbin/groupadd -p x -k group_modification
-w /usr/sbin/groupmod -p x -k group_modification
-w /usr/sbin/addgroup -p x -k group_modification
-w /usr/sbin/useradd -p x -k user_modification
-w /usr/sbin/usermod -p x -k user_modification
-w /usr/sbin/adduser -p x -k user_modification

## login configuration and information
-w /etc/login.defs -p wa -k login
-w /etc/securetty -p wa -k login
-w /var/log/faillog -p wa -k login
-w /var/log/lastlog -p wa -k login
-w /var/log/tallylog -p wa -k login

## network configuration
-w /etc/hosts -p wa -k hosts
-w /etc/network/ -p wa -k network

## system startup scripts
-w /etc/inittab -p wa -k init
-w /etc/init.d/ -p wa -k init
-w /etc/init/ -p wa -k init

## library search paths
-w /etc/ld.so.conf -p wa -k libpath

## local time zone
-w /etc/localtime -p wa -k localtime

## kernel parameters
-w /etc/sysctl.conf -p wa -k sysctl

## modprobe configuration
-w /etc/modprobe.conf -p wa -k modprobe

## pam configuration
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/limits.conf -p wa  -k pam
-w /etc/security/pam_env.conf -p wa -k pam
-w /etc/security/namespace.conf -p wa -k pam
-w /etc/security/namespace.init -p wa -k pam

## GDS specific secrets
-w /etc/puppet/ssl -p wa -k puppet_ssl

## postfix configuration
-w /etc/aliases -p wa -k mail
-w /etc/postfix/ -p wa -k mail

## ssh configuration
-w /etc/ssh/sshd_config -k sshd

## changes to hostname
-a exit,always -F arch=b32 -S sethostname -k hostname
-a exit,always -F arch=b64 -S sethostname -k hostname

## changes to issue
-w /etc/issue -p wa -k etcissue
-w /etc/issue.net -p wa -k etcissue

## this was to noisy currently.
# log all commands executed by an effective id of 0 aka root.
-a exit,always -F arch=b64 -F euid=0 -S execve -k rootcmd
-a exit,always -F arch=b32 -F euid=0 -S execve -k rootcmd

## Capture all failures to access on critical elements
-a exit,always -F arch=b64 -S open -F dir=/etc -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/bin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/sbin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/usr/bin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/usr/sbin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/var -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/home -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/srv -F success=0 -k unauthedfileacess

## Monitor for use of process ID change (switching accounts) applications
-w /bin/su -p x -k priv_esc
-w /usr/bin/sudo -p x -k priv_esc
-w /etc/sudoers -p rw -k priv_esc

## Monitor usage of commands to change power state
-w /sbin/shutdown -p x -k power
-w /sbin/poweroff -p x -k power
-w /sbin/reboot -p x -k power
-w /sbin/halt -p x -k power

## Make the configuration immutable
-e 2

You're somewhat approaching the question the wrong way. You need to decide what you want to log, and find out how to log that. Generating a bunch of log files is cool and all, but if you never look at them or don't know what you're looking for, it just wastes time and space.

When deciding what to log, you need to identify what behavior it is that you care about, and then find out how to log that activity. A good way to start doing this would be to read about AppArmor and to peruse the auditctl man page. then learn what system calls are available by learning to program for Unix, and identify the calls which may be of interest. It's really a pretty big undertaking. I know this is a bit of a glib answer and doesn't provide "here's a shell script which will log everything you care about on your server" - but the reason those answers don't exist is that, well, every situation is different so it's not possible to give a "one size fits most" answer.

At the (admittedly large) place where I work, we have a whole team of people who are dedicated to only system logging - not to mention the various admin and security teams who contribute. This is not a small topic. :/

  • Agreed - for most platforms, and Linux is no different, you have a wealth of logging options and it comes down to your needs, not what you can turn on. What are you protecting, what do you want to measure, etc.?
    – Rory Alsop
    Commented Jun 23, 2011 at 8:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .