Learn Linux System Auditing with Auditd Tool on CentOS/RHEL

System auditing simply refers to in-depth analysis of a specific targeted system: an audit is made up of an examination of the various parts which comprise that system, with critical assessment (and testing if required) in different areas of interest.

Read Also: Lynis – Security Auditing and Scanning Tool for Linux Systems

One of the critical subsystems on RHEL/CentOS the Linux audit system commonly known as auditd. It implements a means to track security-relevant information on a system: it uses pre-configured rules to collect vast amounts of information about events that are happening on the system, and records them in a log file, thus creating an audit trial.

It can record information such as date and time, type, and result of an event; users who caused the event, any modifications made to files/databases; uses of system authentication mechanisms, such as PAM, LDAP, SSH, and others.

Auditd also registers any changes made to the audit configuration files or any attempts to access audit log files, and any efforts to import or export information into or from the system plus a lot of other security-related information.

Why is the Linux Audit System Important?

  1. It doesn’t require any external programs or processes to run on a system making it self-reliant.
  2. It is highly configurable therefore enables you to view any system operation(s) you want.
  3. It helps in detecting or analyzing potential compromises of a system.
  4. It is capable of working as an independent detection system.
  5. It can work with Intrusion Detection Systems to enable intrusion detection.
  6. It is a vital tool for auditing forensics investigations.

The Linux Audit System Components

The audit system has two core components, namely:

  • user-space applications and utilities/tools, and
  • kernel-side system call processing – this accepts system calls from user-space applications and passes them through three types of filters, namely: user, task, exit, or exclude.

The most important part is the user-space audit daemon (auditd) which gathers information based on pre-configured rules, from the kernel and generates entries in a log file: the default log is /var/log/audit/audit.log.

Additionally, the audispd (audit dispatcher daemon) is an event multiplexor that interacts with auditd and sends events to other programs that want to perform real time event processing.

There are a number of user-space tools for managing and retrieving information from the audit system:

  • auditctl – a utility for controlling the kernel’s audit system.
  • ausearch – a utility for searching audit log files for specific events.
  • aureport – a utility for creating reports of recorded events.

How to Install and Configure Audit Tool in RHEL/CentOS/Fedora

First make sure to verify that the audit tool is installed on your system using the rpm command and grep utility as follows:

# rpm -qa | grep audit
Check Auditd Tool

Check Auditd Tool

If you do not have the above packages installed, run this command as the root user to install them.

# yum install audit

Next, check if auditd is enabled and running, issue the systemctl commands below on the terminal.

--------------- On CentOS/RHEL 7 --------------- 
# systemctl is-enabled auditd
# systemctl status auditd
# systemctl start auditd   [Start]
# systemctl enable auditd  [Enable]

--------------- On CentOS/RHEL 6 --------------- 
# service auditd status
# service auditd start     [Start]
# chkconfig auditd on      [Enable]
Check Status of Auditd Tool

Check Status of Auditd Tool

Now we will see how to configure auditd using the main configuration file /etc/audit/auditd.conf. The parameters here allow you to control how the service runs, such as defining the location of the log file, maximum number of log files, log format, how to deal with full disks, log rotation and many more options.

# vi /etc/audit/auditd.conf

From the sample output below, the parameters are self-explanatory.

Auditd Configuration File

Auditd Configuration File

Understanding Audit Rules

As we mentioned earlier on, auditd uses rules to gather specific information from the kernel. These rules are basically auditctl options (see man page) that you can pre-configure rules in the /etc/audit/rules.d/audit.rules file (On CentOS 6, use the /etc/audit/audit.rules file), so that they are loaded at startup.

There are three kinds of audit rules you can define:

  • Control rules – these enable modification of the audit system’s behavior and a few of its configurations.
  • File system rules (also referred to as file watches) – enable auditing of access to a certain file or a directory.
  • System call rules – permits logging of system calls made by any program.

Now open the main configuration file for editing:

# vi /etc/audit/rules.d/audit.rules

Note that the first section of this file must contain control rules. Then add your audit rules (file watches and system call rules) in the middle section, and finally the last section contains immutability settings which are also control rules.

Examples of Auditd Control Rules

-D		#removes all previous rules
-b  3074	#define buffer size
-f 4		#panic on failure 
-r 120		#create at most 120 audit messages per second

Examples of Auditd File System Rules

You can define file watches using this syntax:

-w /path/to/file/or/directory -p permissions -k key_name

Where the option:

  • w – is used to specify a file or directory to watch over.
  • p – permissions to be logged, r – for read access, w – for write access, x – for execute access and a – for change of file or director attribute.
  • -k – allows you to set an optional string for identifying which rule (or a set of rules) created a specific log entry.

These rules allow auditing to watch events making changes to these critical system files.

-w /etc/passwd -p wa -k passwd_changes
-w /etc/group -p wa -k group_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes

Examples of Auditd System Call Rules

You can set a system call rule using the form below:

-a action,filter -S system_call -F field=value -k key_name

where:

  • action – has two possible values: always or never.
  • filter – specifies kernel rule-matching filter (task, exit, user and exclude) is applied to the event.
  • system call – system call name.
  • field – specifies additional options such as architecture, PID, GID etc to modify rule.

Here are some rules you can define.

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
-a always,exit -S sethostname -S setdomainname -k system_locale

Then lastly add the immutability settings at the end of the file, for example:

-e 1	#enable auditing
-e 2	#make the configuration immutable -- reboot is required to change audit rules
Sample Auditd Rules Configuration File
Auditd Rules Configuration File

Auditd Rules Configuration File

How to Set Auditd Rules Using auditctl Utility

Alternatively, send the options to auditd while it’s running, using the auditctl as in the following examples. These commands can override rules in the configuration file.

To list all currently loaded audit rules, pass the -l flag:

# auditctl -l

Next, try to add a few rules:

# auditctl -w /etc/passwd -p wa -k passwd_changes
# auditctl -w /etc/group -p wa -k group_changes
# auditctl -w /etc/sudoers -p wa -k sudoers_changes
# auditctl -l
Add Auditd Rules Using Auditctl

Add Auditd Rules Using Auditctl

Understanding Auditd Log Files

All audit messages are recorded in /var/log/audit/audit.log file by default. To understand the log entry format, we’ll load a rule and check the log entry generated after an event matching the rule.

Assuming we have a secret backups directory, this audit rule will log any attempts to access or modify this directory:

# auditctl -w /backups/secret_files/ -p rwa -k secret_backup

Now, using another system account, try to move into the directory above and run the ls command:

$ cd /backups/secret_files/
$ ls

The log entry will look like so.

Check Audit Logs for Changes

Check Audit Logs for Changes

The above event is made up of three types of audit records. The first is type=SYSCALL:

type=SYSCALL msg=audit(1505784331.849:444): arch=c000003e syscall=257 success=yes exit=3 a0=ffffffffffffff9c a1=8ad5c0 a2=90800 a3=0 items=1 ppid=2191 pid=2680 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="secret_backup"

The second is type=CWD.

type=CWD msg=audit(1505784331.849:444):  cwd="/backups/secret_files"

And the last one is type=PATH:

type=PATH msg=audit(1505784331.849:444): item=0 name="." inode=261635 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 objtype=NORMAL

You can find a complete list of all the event fields (such as msg, arch, ses etc..) and their meanings in the Audit System Reference.

That’s all for now. In the next article, we will look at how to use ausearch to query audit log files: we will explain how to search for specific information from the audit logs. If you have any questions, please reach us via the comment section below.

5 (1)
Article Rating (1 Votes)
Rate this article
Attachments
There are no attachments for this article.
Comments
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
RHCS: Configure an active/backup pacemaker cluster
Viewed 8871 times since Sun, Jun 3, 2018
LVM: Reduce root PV/VG
Viewed 5102 times since Sat, Jun 2, 2018
stunnel basics and pki standards
Viewed 9374 times since Fri, Sep 28, 2018
RHEL: Building a custom kernel on RHEL 6
Viewed 3999 times since Sat, Jun 2, 2018
SYS: Configure a local repository. local repo
Viewed 10854 times since Mon, Oct 29, 2018
systemctl Use systemd to Start a Linux Service at Boot
Viewed 5659 times since Mon, Dec 7, 2020
Using etckeeper with git
Viewed 6755 times since Sun, Jun 3, 2018
ZPOOL: Create a new zpool for zfs filesystems
Viewed 2141 times since Sun, Jun 3, 2018
ZPOOL: Verify/change properties of a zpool
Viewed 2023 times since Sun, Jun 3, 2018
LVM: Extend an existing Logical Volume / Filesystem
Viewed 2370 times since Sat, Jun 2, 2018