Configuring and auditing Linux systems with Audit daemon

The Linux Audit Daemon is a framework to allow auditing events on a Linux system. Within this article we will have a look at installation, configuration and using the framework to perform Linux system and security auditing.

Auditing goals

By using a powerful audit framework, the system can track many event types to monitor and audit the system. Examples include:

Audit file access and modification See who changed a particular file Detect unauthorized changes

Monitoring of system calls and functions

Detect anomalies like crashing processes

Set tripwires for intrusion detection purposes

Record commands used by individual users

Components

The framework itself has several components:

Kernel:

audit: hooks into the kernel to capture events and deliver them to auditd

Binaries:

auditd : daemon to capture events and store them (log file)

: daemon to capture events and store them (log file) auditctl : client tool to configure auditd

: client tool to configure auditd audispd : daemon to multiplex events

: daemon to multiplex events aureport : reporting tool which reads from log file (auditd.log)

: reporting tool which reads from log file (auditd.log) ausearch : event viewer (auditd.log)

: event viewer (auditd.log) autrace : using audit component in kernel to trace binaries

: using audit component in kernel to trace binaries aulast : similar to last, but instaed using audit framework

: similar to last, but instaed using audit framework aulastlog : similar to lastlog, also using audit framework instead

: similar to lastlog, also using audit framework instead ausyscall : map syscall ID and name

: map syscall ID and name auvirt: displaying audit information regarding virtual machines

Files:

audit.rules: used by auditctl to read what rules need to be used

auditd.conf: configuration file of auditd

Installation

Debian/Ubuntu: apt-get install auditd audispd-plugins

Red Hat/CentOS/Fedora: usually already installed (package: audit and audit-libs)

Configuration

The configuration of the audit daemon is arranged by two files, one for the daemon itself (auditd.conf) and one for the rules used by the auditctl tool (audit.rules).

auditd.conf

The file auditd.conf configures the Linux audit daemon (auditd) with focus on where and how it should log events. It also defines how to deal with full disks, log rotation and the number of logs to keep. Usually the default configuration will be appropriate for most systems.

audit.rules

To configure what events should be audited, the audit framework uses a rules file named audit.rules.

As with most things, use a clean start and without any loaded rules. Active rules can be determined by running auditctl with the -l parameter.

[root@host ~]# auditctl -l

No rules

In case any rules are loaded, remove them with auditctl and the -D parameter.

Time to start with monitoring something, let’s say the /etc/passwd file. We put a ‘watch’ on the file by defining the path and permissions to look for:

auditctl -a exit,always -F path=/etc/passwd -F perm=wa

By defining the path option, we instruct the audit framework what directory or file to watch for. The permissions determine what kind of access will trigger an event. Although these look similar to file permissions, note that there is a important difference between the two. The four options are:

r = read

= read w = write

= write x = execute

= execute a = attribute change

Finding the related event or access to the file can be quickly traced by using the ausearch tool.

[root@host audit]# ausearch -f /etc/passwd time->Tue Mar 18 15:17:25 2014

type=PATH msg=audit(1395152245.230:533): item=0 name=”/etc/passwd” inode=137627 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 nametype=NORMAL

type=CWD msg=audit(1395152245.230:533): cwd=”/etc/audit”

type=SYSCALL msg=audit(1395152245.230:533): arch=c000003e syscall=188 success=yes exit=0 a0=d14410 a1=7f66eec38db7 a2=d4ea60 a3=1c items=1 ppid=1109 pid=4900 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm=”vi” exe=”/bin/vi” subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Some highlights of this output are:

The time of the event and the name of the object, the current working path (cwd), related syscall, audit user ID (auid) and the binary (exe) performing the action upon the file. Please note that the auid defines the original user during log-in. The other user ID fields might indicate a different user, depending on the effective user being used while triggering an event.

Converting system calls

Syscalls are logged by an numeric value. Since there will be an overlap in these values between different architectures, the active architecture is also logged.

By using uname -m we can determine the architecture and use ausyscall to determine what numeric call 188 represents.

[root@host audit]# ausyscall x86_64 188

setxattr

We now know it was a change in attribute, which makes sense as we defined our watch to trigger an event on an attribute change (perm=a).

Used a temporary rule and want to use the old rules again? Refresh the audit rules from a file:

auditctl -R /etc/audit/audit.rules

Auditing of processes under Linux

Similiar to using strace, the audit framework has a tool named autrace. It uses the audit framework and adds the right rules to capture information and log it. Using ausearch the gathered information can be displayed.

Perform a trace:

root@host:~# autrace /bin/ls /tmp

autrace cannot be run with rules loaded.

Please delete all rules using ‘auditctl -D’ if you really wanted to

run this command.

root@host:~# auditctl -D

No rules

root@host:~# autrace /bin/ls /tmp

Waiting to execute: /bin/ls

atop.d mc-root mongodb-27017.sock suds

Cleaning up…

Trace complete. You can locate the records with ‘ausearch -i -p 20314’

Display related files via ausearch:

root@host:~# ausearch –start recent -p 21023 –raw | aureport –file –summary File Summary Report

===========================

total file

===========================

1 /bin/ls

1 (null) inode=1975164 dev=08:02 mode=0100755 ouid=0 ogid=0 rdev=00:00

1 /etc/ld.so.cache

1 /lib/x86_64-linux-gnu/libselinux.so.1

1 /lib/x86_64-linux-gnu/librt.so.1

1 /lib/x86_64-linux-gnu/libacl.so.1

1 /lib/x86_64-linux-gnu/libc.so.6

1 /lib/x86_64-linux-gnu/libdl.so.2

1 /lib/x86_64-linux-gnu/libpthread.so.0

1 /lib/x86_64-linux-gnu/libattr.so.1

1 /proc/filesystems

1 /usr/lib/locale/locale-archive

1 /tmp

Audit file access per user

The audit framework can be used to monitor syscalls, including access to files. If you want to know what files a particular user ID accessed, use a rule like this:

auditctl -a exit,always -F arch=x86_64 -S open -F auid=80

-F arch=x86_64 Define what architecture is used (uname -m), to monitor the right syscall (some system calls are ambiguous between archtectures).

-S open Select the “open” syscall

-F auid=80 The related user ID

This kind of information is really useful for intrusion detection, but also when performing forensics on a Linux system.

Automation

Since the Linux audit daemon can provide valuable auditing data, Lynis will check for the presence of the framework. If not available, it will advice you to install. Additionally Lynis will perform several tests to determine the log file, available rules and more.

For proper intrusion detection, integration with an Intrusion Detection System (IDS) is key in discover events when they occur and take appropriate actions.

More..

The audit daemon has more possibilities. Other examples will be listed in separated articles in the future of this blog. If you are serious about auditing the Linux platform, the Linux audit framework will definitely be a good friend!