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.
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
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
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.
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
-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
-w /etc/hosts -p war -k hosts-file
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, you can create new processes using
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
-a option here lets you tell the rule engine that you want to add a rule to the existing rule chain. The
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.
-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
-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
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'
-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
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
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
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"
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"