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?
- It doesn’t require any external programs or processes to run on a system making it self-reliant.
- It is highly configurable therefore enables you to view any system operation(s) you want.
- It helps in detecting or analyzing potential compromises of a system.
- It is capable of working as an independent detection system.
- It can work with Intrusion Detection Systems to enable intrusion detection.
- 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
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]
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.
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
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
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.
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.
Hi,
I am trying to pull the audit logs from a particular path but the Audit log is not capturing the entire command.
For Eg: If I give ls -l then it is capturing only ls but not
-l
.So how can I capture the complete command “ls -l”?
great starter info…thanks for your efforts
@ug
Welcome, thanks for reading, and for the feedback.
Hi Aaron,
This is very interesting topic, FYI according to security standard we need to define separate partition for audit logs under /var/log/audit/ using minimum size.
Thanks & Regards,
Babin Lonston
@Bobin
Thanks for the useful additional thoughts expressed with practical experience from a system administration and security perspective.