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.

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.

# 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.

# 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"