Understanding System auditing with auditd

What is auditd

Auditing system is an important part of system administration. It allows us to audit minute details related to what exactly is happening within the system. auditd is a userspace component to the Linux auditing system. This means that system users will be able to run auditd to configure rules and alerts for auditing functionality with the Linux system.

One of the best things about auditd is that it is tightly integrated with the kernel, so it gives us the power to monitor almost everything we want, really. In order to allow users to see what is going on, auditd can record all the audit-related events to a disk and we can use various tools such as ausearch or aureport to go through the log files.

Installing auditd

auditd is generally installed by default on all linux systems.

# rpm -qa | grep audit

In case, it is not installed, you can install it using the package manager, for e.g.:

# yum install audit

Make sure the audit service is enabled and active:

# systemctl status auditd
● auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2018-06-10 14:10:08 UTC; 54min ago
     Docs: man:auditd(8)
  Process: 658 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
  Process: 653 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)
 Main PID: 654 (auditd)
    Tasks: 2
   CGroup: /system.slice/auditd.service
           └─654 /sbin/auditd

Configuring the audit service

Since auditd doesn’t rely on syslog or any other external services, logging needs to be configured through the audit daemon’s configuration file /etc/audit/rules.d/auditd.conf.

On CentOS/RHEL 6, the configuration file is /etc/audit/audit.rules instead of /etc/audit/rules.d/audit.rules.

By default, auditd logs to /var/log/audit/audit.log and rotates the file once it reaches 8 megabytes in size. After editing the configuration file the auditd service needs to be restarted, which can only be done through the “service” command instead of systemctl:

# service auditd restart

The reason for this limitation is that the audit daemon has to record any changes to the audit trail including starting and stopping the audit daemon itself. Systemctl uses dbus to talk to the system which hides who issued the command and looks like root did it.

Listing audit rules

By default, there are no rules configured in auditd. The command to check what rules are configured by auditd is “auditctl -l“.

# auditctl -l
No rules

Auditing files/directories for changes using auditd

The Audit system operates on a set of rules that define what is to be captured in the log files. To audit access to a particular file or directory rules need to be in the following format:

-w [path] -p [permissions] -k [key]

path – is the full path of a file or directory and cannot contain wildcards, because it gets converted to an inode in the kernel. In case of a directory this rule will place a recursive watch on the directory and its whole subtree as long there’s no mount point under it.
Permissions – can be any combination of read, write, xecute or attribute change(permission/ownership of file).
key – is an arbitrary string of 31 bytes or less which can uniquely identify the audit records (logs) produced by the rule. It makes it easier to filter the logs or to group multiple rules tagged by the same key.

Example : monitor /etc/shadow for changes with Auditd

Let’s see an example of configuring an auditd rule to monitor write and attribute changes to the file /etc/shadow.

1. Edit the /etc/audit/rules.d/audit.rules and paste the line shown below:

# vi /etc/audit/rules.d/audit.rules
-w /etc/shadow -p wa -k shadow

2. Restart the auditd deamon for the changes to take effect.

# service auditd restart

3. Verify the new rule:

# auditctl -l
-w /etc/shadow -p wa -k shadow
Note: The rules which are defined in the configuration file /etc/audit/rules.d/audit.rules are permanent.

Setting auditd rules temporarily

1. Temporary rules are useful to test new audit policies before setting them permanently for the system. These rules become effective immediately but then get wiped out at reboot. The rules from the above example can temporarily be added to the system using the auditctl command:

# auditctl -w /etc/shadow -p wa -k shadow

2. Active rules can be listed as:

# auditctl -l
-w /etc/shadow -p wa -k shadow

Reading the audit log

Once the rules are active any changes made to the files or directories being watched will be recorded to the log file configured in auditd.conf (by default: /var/log/audit/audit.log).

For example, modifying the permissions of the /etc/shadow file with chmod produces the following entries:

type=SYSCALL msg=audit(1528729002.537:190): arch=c000003e syscall=268 success=yes exit=0 a0=ffffffffffffff9c a1=21300f0 a2=1ff a3=7fff25df27e0 items=1 ppid=1807 pid=1849 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=2 comm="chmod" exe="/usr/bin/chmod" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="shadow"
type=CWD msg=audit(1528729002.537:190):  cwd="/root"
type=PATH msg=audit(1528729002.537:190): item=0 name="/etc/shadow" inode=638136 dev=ca:01 mode=0100000 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shadow_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1528729002.537:190): proctitle=63686D6F6400373737002F6574632F736861646F77

It clearly shows the type of access, the file name, audit (auid) and actual (uid) user IDs, the command (chmod) and the key identifying the audit rule that triggered the entry.

Using ausearch to read the logs

Even though reading the log file directly provides all the information we need, it’s not particularly user friendly or human readable. The audit package comes with the ausearch tool which produces a more human readable output:

# ausearch -i

The output from above command can be really long. But the results can also be filtered by different parameters such as key. For example, we can use the “shadow” key to filter out the logs.

type=PROCTITLE msg=audit(06/11/2018 14:56:42.537:190) : proctitle=chmod 777 /etc/shadow
type=PATH msg=audit(06/11/2018 14:56:42.537:190) : item=0 name=/etc/shadow inode=638136 dev=ca:01 mode=file,000 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shadow_t:s0 objtype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(06/11/2018 14:56:42.537:190) :  cwd=/root
type=SYSCALL msg=audit(06/11/2018 14:56:42.537:190) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=0xffffffffffffff9c a1=0x21300f0 a2=0777 a3=0x7fff25df27e0 items=1 ppid=1807 pid=1849 auid=user uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=2 comm=chmod exe=/usr/bin/chmod subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=shadow

One of the advantages of reading the log file directly is to monitor it for changes using tail (tail -f /var/log/audit/audit.log). To achieve the same with ausearch use:

# watch -n2 'ausearch -i -k shadow | tail -20'

Using aureport

As an alternative to ausearch, you can use aureport to produce a series of audits in the following way:

1. To monitor unusual behavior, you can use:

# aureport --key --summary

Key Summary Report
total  key
11  shadow

2. To build a report on user logins, you can use:

# aureport -l -i -ts yesterday -te today

Login Report
# date time auid host term exe success event
1. 06/10/2018 07:03:13 (unknown) ssh /usr/sbin/sshd no 278
2. 06/10/2018 07:03:50 (unknown) ssh /usr/sbin/sshd no 286
3. 06/10/2018 07:05:41 (unknown) ssh /usr/sbin/sshd no 298

3. To review access violations, you can try:

# ausearch --key access --raw | aureport --file --summary

File Summary Report
total  file
[no events of interest were found]

4. Finally, to review anomalies, you can use:

# aureport --anomaly

Anomaly Report
# date time type exe term host auid event
1. 01/07/2015 16:40:33 ANOM_ABEND systemd-tty-ask ? ? 1001 1010
2. 01/07/2015 17:47:12 ANOM_ABEND systemd-tty-ask ? ? 1001 74
3. 12/19/2015 23:04:44 ANOM_ABEND systemd-journal ? ? -1 98
4. 12/19/2015 23:04:44 ANOM_ABEND systemd-localed ? ? -1 99

Excluding messages from audit log

Instead of filtering unwanted messages when reading the logs, it’s also possible to completely exclude them from the log file. The following rule excludes any Cron related messages by dropping entries with the subject type of ‘crond_t’:

# vi /etc/audit/rules.d/audit.rules
-A exclude,always -F subj_type=crond_t

Exclude service start and stop messages:

# vi /etc/audit/rules.d/audit.rules
-A exclude,always -F msgtype=SERVICE_START
-A exclude,always -F msgtype=SERVICE_STOP
5 (1)
Article Rating (1 Votes)
Rate this article
There are no attachments for this article.
There are no comments for this article. Be the first to post a comment.
Full Name
Email Address
Security Code Security Code
Related Articles RSS Feed
List of 10 Must Know Oracle Database Parameters for Database Administrator
Viewed 115732 times since Thu, Jun 21, 2018
Linux Audit The Linux security blog about Auditing, Hardening, and Compliance lynis
Viewed 1806 times since Thu, Jan 16, 2020
HowTo: Kill TCP Connections in CLOSE_WAIT State
Viewed 14934 times since Thu, Feb 14, 2019
How to use yum-cron to automatically update RHEL/CentOS Linux 6.x / 7.x
Viewed 4736 times since Tue, Dec 4, 2018
RHCS6: Clustered LVM
Viewed 1963 times since Sun, Jun 3, 2018
Deskshare TLS over Stunnel
Viewed 2562 times since Fri, Sep 28, 2018
Using Official Redhat DVD as repository
Viewed 10893 times since Mon, Oct 29, 2018
Lsyncd: live file syncronization across multiple Linux servers
Viewed 6584 times since Wed, Oct 31, 2018
logrotate Log Rotate Configuration
Viewed 2977 times since Sun, Jan 12, 2020
stunnel How To Encrypt Traffic to Redis with Stunnel on Ubuntu 16.04
Viewed 1817 times since Sun, Dec 6, 2020