Using auditd and audit.rules for Linux and UNIX Auditing

auditd setup and audit.rules configuration

The native audit facility is preconfigured in Linux [auditd(8)], but must be configured in Solaris [auditd(1M)]. (The Solaris setup of auditd is not rocket science, but does involve some level of complication.) Configuration of the audit facility can be done via the graphical application under X Windows, via the auditctl utility or directly via audit.rules configuration file modification.

Once installed, it is easy to use and automatically starts with each user session in Solaris 11 or Linux. Solaris 10 systems will require the machine to be rebooted to go into auditing mode, and configuration will require kernel tweaking.

Product Info

What auditd records:

The audit facility records data from the kernel, included the system calls, user ID and process ID. It captures all the low-level internals with a high level of granular detail. The information can be stored locally or sent to a central server. In Solaris 10, packets are chopped at 1024 bytes. In Solaris 11, the packets can be made larger by a plug-in so that information is not lost in chopping.

Security and Audit Implications:

Configuration allows you to determine what events or system calls should be recorded. These are recorded directly from the kernel and are highly-reliable. The events can be tagged so that they are easy to sort through, but the huge amount of data often makes it difficult to locate what you are looking for.

Unlike script and screen, auditd will capture the deep internals. However, it has the opposite problem because it does not capture screen I/O. The audit data is of a very technical nature, and does not necessarily state what the user was doing. (i.e. It will show actions spawned within a script, but does not show the script being run or the interactive command launched.)

When to use auditd:

The audit facility is best applied for monitoring of non-interactive activity such as file changes and system configuration changes.