Floating Octothorpe

Getting started with auditd

Since 2.6 Linux has had an audit framework available. It allows you to monitor system calls and filesystem access which can be a very useful additional layer of security.

Installation

The main components which make up the audit framework are the kernel level code and a daemon process called auditd. Under CentOS 7 all you need to do to get auditd up and running is install the audit package:

yum install -y audit

Once the audit package is installed the auditd daemon should be running:

$ systemctl status auditd
* auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2017-02-04 16:20:35 GMT; 21h ago
     Docs: man:auditd(8)
           https://people.redhat.com/sgrubb/audit/
  Process: 1159 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 1188 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
 Main PID: 1187 (auditd)
   CGroup: /system.slice/auditd.service
           +-1187 /sbin/auditd -n

Feb 04 16:20:35 localhost.localdomain systemd[1]: Starting Security Auditing Service...
Feb 04 16:20:35 localhost.localdomain auditd[1187]: Started dispatcher: /sbin/audispd pid: 1191
Feb 04 16:20:35 localhost.localdomain auditd[1187]: Init complete, auditd 2.6.5 listening for events (startup state enable)
Feb 04 16:20:35 localhost.localdomain systemd[1]: Started Security Auditing Service.

Note: by default auditd will log events to /var/log/audit/audit.log. Although the max_log_file and num_logs options in /etc/audit/auditd.conf will limit how much space can be used by logs, it's normally a good idea to make /var/log/audit a separate filesystem.

Default rules

Without any additional configuration auditd will log several standard events. The aureport and ausearch commands can be used to query the events. For example if you want to see recent authentication events you can use the --auth option:

$ aureport  --auth

Authentication Report
============================================ 
# date time acct host term exe success event 
============================================ 
1. 16/01/17 21:17:24 root ? tty1 /usr/bin/login yes 39
2. 16/01/17 21:23:01 root 10.0.2.2 ssh /usr/sbin/sshd no 56
3. 16/01/17 21:23:03 root gateway ssh /usr/sbin/sshd yes 57
4. 16/01/17 21:23:03 root 10.0.2.2 ssh /usr/sbin/sshd yes 60
5. 04/02/17 15:52:57 root 10.0.2.2 ssh /usr/sbin/sshd no 43
6. 04/02/17 15:53:01 root gateway ssh /usr/sbin/sshd yes 45
7. 04/02/17 15:53:01 root 10.0.2.2 ssh /usr/sbin/sshd yes 48
8. 05/02/17 14:30:02 root 10.0.2.2 ssh /usr/sbin/sshd no 295
9. 05/02/17 14:30:04 root gateway ssh /usr/sbin/sshd yes 296

Or if you want to find out when a tool like tcpdump was used to perform a packet capture, you can search for ANOM_PROMISCUOUS events:

$ ausearch --message ANOM_PROMISCUOUS
---- 
time->Sun Feb  5 14:45:00 2017
type=ANOM_PROMISCUOUS msg=audit(1486305900.162:474): dev=enp0s3 prom=0 old_prom=256 auid=0 uid=72 gid=72 ses=25
---- 
time->Sun Feb  5 14:44:59 2017
type=SYSCALL msg=audit(1486305899.049:473): arch=c000003e syscall=54 success=yes exit=0 a0=3 a1=107 a2=1 a3=7ffcdd1ff030 items=0 ppid=11488 pid=11491 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=25 comm="tcpdump" exe="/usr/sbin/tcpdump" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Adding rules

Auditd can also be given custom rules to record addition events. Audit rules can be controlled using the auditctl command, however to get persistent rules you need to write them to a configuration file. Rules are normally stored under /etc/audit/rules.d/, and should normally only be accessible by the root user:

$ ls -l /etc/audit/rules.d/somerules.rules
-rw-------. 1 root root 39 Feb  5 14:12 /etc/audit/rules.d/somerules.rules

auditd needs to reload its configuration before it starts using any new rules:

$ augenrules --load

Note: RefuseManualStop=yes is set in the systemd unit file so running systemctl restart auditd.service will fail.

Monitoring file access

Configuring auditd to monitor filesystem access is relatively straightforward. For example if you want to monitor files under /etc/ being changed you could use a rule similar to the following:

-w /etc/ -p wa -k system_configuration

This rule will produce an audit message if any files under /etc/ are written to (w) or have any attributes changed (a). For example updating /etc/motd will produce log entries similar to the following:

23 key="system_configuration"
type=CWD msg=audit(1486305706.792:409):  cwd="/root"
type=PATH msg=audit(1486305706.792:409): item=0 name="/etc/" inode=4194369 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=PATH msg=audit(1486305706.792:409): item=1 name="/etc/motd" inode=4195234 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=NORMAL

Monitoring system calls

auditd can also monitor arbitrary system calls. For example if you want to monitor when the hostname of a server is changed, you could audit the sethostname system call:

-a always,exit -F arch=b64 -S sethostname -k set-hostname

Note: -F arch=b64 is set to limit the rule to 64 bit system calls.

This will produce log messages similar to the following if commands like hostname are called:

$ ausearch --key set-hostname
---- 
time->Tue Feb  7 23:34:03 2017
type=CONFIG_CHANGE msg=audit(1486510443.032:59): auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op="add_rule" key="set-hostname" list=4 res=1
---- 
time->Tue Feb  7 23:34:08 2017
type=SYSCALL msg=audit(1486510448.375:60): arch=c000003e syscall=170 success=yes exit=0 a0=1196010 a1=6 a2=6 a3=7fff5d76c730 items=0 ppid=979 pid=1364 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="hostname" exe="/usr/bin/hostname" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="set-hostname"