![Lead Image © alphaspirit , 123RF.com](images/123RF_19632313_Telescope-man-balloons_alphaspirit.png)
Monitoring events with the Audit daemon
Watchful Spirit
The Audit daemon is a service that logs events on a Linux system. If you are interested in security-related messages, take a closer look at the Audit daemon. The audit framework described in this article is part of the Linux kernel and can therefore control access to a computer right down to the system call level. The Audit daemon can monitor all access to files, network ports, or other events. The popular security tool SELinux works with the same audit framework used by the Audit daemon.
Configuring Logging
You can set the rules for logging using the auditctl
tool. Like all of the other tools mentioned here, it is part of the audit package that should be included in the software repository of your choice of Linux distribution. auditd
running in userspace is notified about events that occur via the netlink protocol. The Audit daemon then writes the information to /var/log/audit/audit.log
, and you can find the results via aureport
and ausearch
.
An event dispatcher is also part of the framework. This tool is a type of event multiplexer that can pass audit events on to another program (plugin) in real time. These plugins can be configured via files in the /etc/audisp/plugins.d/
directory.
For example, the /etc/audisp/plugins.d/af_unix.conf
file is responsible for simply passing audit events to a Unix domain socket. This socket is used by the Setroubleshoot daemon to create easily readable messages from the raw SELinux logs. Intrusion detection and prevention systems also can draw on this interface to respond to audit events.
You can configure the auditd
server via two files – auditd.conf
(Listing 1) and audit.rules
– in /etc/audit/
. The config file specifies general information about the service, whereas the rules file contains the rules that determine what exactly you want to monitor on the system.
Listing 1: auditd.conf
log_file = /var/log/audit/audit.log log_format = RAW log_group = root priority_boost = 3 flush = INCREMENTAL freq = 20 num_logs = 5 disp_qos = lossy dispatcher = /sbin/audispd name_format = NONE max_log_file = 6 max_log_file_action = ROTATE space_left = 75 space_left_action = SYSLOG action_mail_acct = root admin_space_left = 50 admin_space_left_action = SUSPEND disk_full_action = SUSPEND disk_error_action = SUSPEND tcp_listen_queue = 5 tcp_max_per_addr = 1 ##tcp_client_ports = 1024-65535 tcp_client_max_idle = 0 enable_krb5 = no krb5_principal = auditd
You can also spread the rules across multiple files and then store them in the /etc/audit/rules.d/
directory. This approach is useful if you want to manage rules in separate files organized by purpose. The augenrules
tool generates a global file called /etc/audit/audit.rules
from all the files in this directory. This file is then read when starting auditd
. You will find a description of the individual instructions in the very detailed auditd.conf
man page.
Enabling Monitoring
You can either use the auditctl
tool to determine the audit rules or record them in the audit.rules
file. Read the rules defined there using auditctl -R
. If, for example, you want to monitor the /etc/hosts
file, you can use the command:
auditctl -w /etc/hosts -p war -k hosts-file
Using the -w
option specifies the path to the file that you want to monitor (file watch). The -p
option lets you define the operations to be monitored, where r
stands for read, w
for write, x
for execute, and a
for attribute changes. Finally, the -k
option sets a filter key. Using au-search
lets you view the file events later.
If you want to set the same value permanently, add the following entry to the audit.rules
file:
-w /etc/hosts -p war -k hosts-file
The auditctl
tool shows all the currently active rules:
# auditctl -l w /etc/hosts -p rwa -k hosts-file
In addition to these simple file watches, complex access cases can be monitored. Four different lists are available for this: task
, exit
, user
, and exclude
. With task
, you can create new processes using fork()
or clone()
, exit
is used for each syscall, user
filters messages from userspace, and exclude
can suppress certain messages. This is useful, for example, if you want to log certain syscalls but do not want to see the SELinux log messages labeled with AVC (Access Vector Cache).
Logging System Calls
If you want to write a rule for logging syscalls, the general syntax looks like this:
-a Action, List -S Systemcall -F Field=Value -k Key
The -a
option here lets you tell the rule engine that you want to add a rule to the existing rule chain. The always
and never
parameters can be used as possible values here: always
produces a log event in each case if the match criteria are correct, and never
ignores the event that appears and thus does not produce a log entry.
Using -S
lets you specify the syscall to be monitored, and -F
determines a control field. Of these, several dozen are very well described in the man page for auditctl
. A possible rule field could be auid
, with which the syscall to be monitored can be bound to a specific account.
The following rule logs all events where a user executes an open
system call with the login UID 1000. This usually occurs when opening a file:
-a exit,always -S open -F auid=1000 -k user-actions
Essentially, all existing system calls can be logged. The man page shows an overview for syscalls.
To avoid logging some of the automatically logged event types, such as user logins, you can add rules to the exclude
list:
-a exclude,always -F msgtype=SYSTEM_BOOT
This rule tells the Audit daemon not to log the SYSTEM_BOOT
event type. Using
ausearch -m 2>&1 | tr ' ' '\n' | grep '[A-Z]$' | sort
will show a list of all available event types.
Viewing Log Files
The ausearch
command can also be used to view the log data in the /var/log/audit/audit.log
file. You can use a variety of filters to search specifically for particular events. For example, Listing 2 shows the command that searches the log for user login events and then displays them.
Listing 2: Simple Search
# ausearch -m USER_LOGIN ---- time->Sat Jun 28 20:14:10 2014 type=USER_LOGIN msg=audit(1403979250.412:116733): pid=31587 uid=0 auid=1000 ses=1445 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=localhost addr=::1 terminal=/dev/pts/9 res=success'
With the -ts
option, you can look for user logins from a certain point in time; -te
, on the other hand, limits the search up to a point in time. To see log entries that were generated on the basis of the previously presented file access rules, use the -k
option.
Listing 3 shows an example with a number of options combined. Here, ausearch
shows all access attempts on the file connected with the hosts-file
key. A similar rule was set up previously using auditctl
. The ausearch
command also is instructed to limit the output to events with today's date and to user access cases in which the login UID is 1000
.
Listing 3: Combined Search
# ausearch -k hosts-file -ts today -ul 1000 ---- time->Tue Jul 1 16:36:00 2014 type=PATH msg=audit(1404225360.791:124138): item=0 name="/etc/hosts" inode=2755966 dev=fd:02 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 nametype=NORMAL type=CWD msg=audit(1404225360.791:124138): cwd="/home/tscherf" type=SYSCALL msg=audit(1404225360.791:124138): arch=c000003e syscall=2 success=yes exit=3 a0=7fff67b1e9fc a1=0 a2=1fffffffffff0000 a3=3109e85ad0 items=1 ppid=7144 pid=11992 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts6 ses=1748 comm="cat" exe="/usr/bin/cat" subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key="hosts-file"
Conclusions
The Audit daemon is a very powerful logging framework for Linux systems, and it comes with some prebuilt rulesets, which can serve as a basis for further rules. These ready-made rulesets can be found in the /usr/share/doc/audit/
directory on a Red Hat or Fedora system. To enable a rule, simply copy the file you want to the /etc/audit/
directory. @LE"