The following lab is an introduction to the auditing capabilities of Red Hat Enterprise Linux. The exercises below are done on a system installed with Red Hat Enterprise Linux 7.5, and may require modification to work in other lab environments.
The Linux Audit system provides a way to track security-relevant information on your system. Based on pre-configured rules, Audit generates log entries to record as much information about the events that are happening on your system as possible. This information is crucial for mission-critical environments to determine the violator of the security policy and the actions they performed. Audit does not provide additional security to your system; rather, it can be used to discover violations of security policies used on your system. These violations can further be prevented by additional security measures such as SELinux.
All of the exercises in this lab are run on the audit.example.com host, either as the root or auditlab user. Each set of exercises instructs you about which user to use, and the username is reflected in the command prompt, as seen in the examples below:
-
The root user prompt on audit.example.com
[root@audit ~]#
-
The auditlab user prompt on audit.example.com
[auditlab@audit ~]$
The recommended way to access the audit.example.com is to open up the terminal and SSH into the audit.example.com host from the bastion workstation system as shown below. If done correctly, you should not need to enter a password.
-
SSH command to login to audit.example.com as root. Replace GUID with your lab’s GUID.
[localhost ~]$ ssh [email protected] [lab-user@workstation-GUID ~]$ ssh [email protected]
-
SSH command to login to audit.example.com as "auditlab"
[lab-user@workstation-GUID ~]$ ssh [email protected]
There are two main audit components in Red Hat Enterprise Linux, the audit daemon and the kernel itself. The exercises below demonstrate how to configure both.
When the audit daemon is started during the boot process, it reads the configuration file in /etc/audit/auditd.conf. The different configuration options are explained in the auditd.conf(5) manpage. Three of the more interesting options are the flush, freq, and log_format options:
-
flush determines the method how the audit events are flushed to disk.
-
freq controls how frequently the flush happens.
-
log_format option controls the on-disk audit log format.
For this lab, we will check to ensure that flush is set to INCREMENTAL_ASYNC (asynchronous flushing for performance), freq is set to 50 (flush the log every 50 records), and log_format is set to “ENRICHED” (resolves some information for improved archival value).
The /etc/audit/auditd.conf file
can be modified using any text editor; but in this lab we will use the sed command to edit the auditd.conf file.
-
If not already there, log into to the workstation bastion host as lab-user from your desktop system replacing GUID with your lab’s GUID. Use the password r3dh4t1!
[localhost ~]$ ssh [email protected] -
Log into the audit.example.com host as root.
[lab-user@workstation-GUID ~]$ ssh [email protected] -
While logged into the_audit.example.com_ system as root, run the following commands to edit the auditd.conf file:
[root@audit ~]# sed -e 's/^flush.*/flush = INCREMENTAL_ASYNC/' -i /etc/audit/auditd.conf [root@audit ~]# sed -e 's/^freq.*/freq = 50/' -i /etc/audit/auditd.conf [root@audit ~]# sed -e 's/^log_format.*/log_format = ENRICHED/' -i /etc/audit/auditd.conf
-
After the configuration file has been updated, we need to signal to the audit daemon to reload its configuration. While logged into the audit.example.com system as root, run the following command to force
auditdto reload its configuration:[root@audit ~]# killall -SIGHUP auditd
The Linux Kernel’s audit subsystem can be configured using the auditctl
command. Using auditctl the administrator can add audit event filtering
rules as well as tune the audit subsystem in the kernel. The different
configuration parameters are explained in the
auditctl(8) manpage.
A number of pre-configured audit filter rules are provided with Red Hat Enterprise Linux. They can be found in /usr/share/doc/audit-*. These filter rules can be enabled by copying them to the system’s audit filter rule directory, regenerating the filter configuration, and loading the resulting filter rule configuration into the kernel.
In the exercise below, we will enable some basic audit filters designed to help administrators meet the US Department of Defense Security Technical Implementation Guide (STIG) for Red Hat Enterprise Linux.
-
While logged into the audit.example.com system as root, run the following commands to enable a number of pre-defined audit filters:
[root@audit ~]# cat /usr/share/doc/audit-*/rules/README-rules [root@audit ~]# rm /etc/audit/rules.d/* [root@audit ~]# cp /usr/share/doc/audit-*/rules/10-base-config.rules /etc/audit/rules.d [root@audit ~]# cp /usr/share/doc/audit-*/rules/30-stig.rules /etc/audit/rules.d [root@audit ~]# cp /usr/share/doc/audit-*/rules/31-privileged.rules /etc/audit/rules.d [root@audit ~]# cp /usr/share/doc/audit-*/rules/99-finalize.rules /etc/audit/rules.d [root@audit ~]# augenrules --load
The
augenrulestool combines all of the *.rules files located in /etc/audit/rules.d into the /etc/audit/audit.rules file and loads them using theauditctlcommand. You can remove, or rename, any of these files and rerun theaugenrules --loadcommand to reconfigure your system.
Custom audit filters can be loaded into the kernel using the auditctl
command. The different filter options are explained in the
auditctl(8) manpage.
Custom audit filters can be made persistent by creating a new file in the /etc/audit/rules.d directory with the .rules file extension. While not required, the following naming convention is suggested:
<priority>-<name>.rules
Where the “<priority>” value falls into these categories:
10: Kernel and auditctl configuration 20: Rules that could match general rules but we want a different match 30: Main rules 40: Optional rules 50: Server Specific rules 70: System local rules 90: Finalize (immutable)
The pre-configured filter rules provide a great example for how to structure
your custom audit filter rule files, but the basic syntax is that each line is
a series of arguments passed to the auditctl command; lines starting with a
“#” are treated as comments and ignored.
In
the exercise below, we are going to create an audit filter that will capture audit
events created by the /usr/bin/ping program. We will also configure the
system to tag all of those events with the rhkey key, using the -k
option, to make search through the audit log easier. The -a always,exit is
a common way to add audit filter rules, it adds a filter rule to be executed at
syscall exit time, see the
auditctl(8) manpage for
more detail.
-
While logged into the audit.example.com system as root, run the following commands to add a custom audit filter for the
/usr/bin/pingapplication:[root@audit ~]# auditctl -a always,exit -F exe=/usr/bin/ping -k rhkey
-
We can make our custom filter rule persistent by adding a new rule file in /etc/audit/rules.d and reloading our configuration.
-
While logged into the audit.example.com system as root, run the following commands to make the custom filter rule persistent:
[root@audit ~]# echo "-a always,exit -S all -F exe=/usr/bin/ping -F key=rhkey" > /etc/audit/rules.d/70-rhkey_lab.rules [root@audit ~]# augenrules --load
-
In addition to custom filter rules, this is also the mechanism we use to tweak the base configuration of the audit subsystem in the Linux Kernel. While logged into the audit.example.com system as root, run the following command to increase the audit backlog buffer to 8192 entries:
[root@audit ~]# auditctl -b 8192
-
If we wanted to make the configuration tweak persistent, we could create a new file in /etc/audit/rules.d with the configuration and reload the audit rules. While logged into the audit.example.com system as root, run the following commands to make the backlog changes persistent:
[root@audit ~]# echo "-b 8192" > /etc/audit/rules.d/15-rhkey_kernel.rules [root@audit ~]# augenrules --load
The exercises below show how to search through the audit logs and generate summary audit reports. It is important to note that this section requires that the system is configured as described earlier in this lab.
In order to ensure we have some interesting events in the audit log, open up another terminal and from the workstation bastion host, login to the audit.example.com system as the auditlab user and run the following commands:
[lab-user@workstation-GUID ~]$ ssh [email protected]
[auditlab@audit ~]$ vi /etc/shadow (Type :q! to exit vi)
[auditlab@audit ~]$ date -s "8 Aug 2011 08:00:00 -0400" [auditlab@audit ~]$ ping -c 1 127.0.0.1
[auditlab@audit ~]$ vi ~/project_tps_report.txt (Type :q! to exit vi)
While the audit logs are plaintext files, and normal Linux text searching tools
(e.g. grep) can be used to search the audit logs, the audit userspace tools
include a tool specially designed to search and interpret the audit logs,
ausearch. The ausearch tool can take a number of command line parameters,
all of which are described in the
ausearch(8) manpage.
The -ts option specifies at what point in the audit logs to start searching, -ts today indicates that only events from today should be considered. The -m option indicates that you are interested in audit events with the given record type.
-
While logged into the audit.example.com system as root, run the following commands to see the login events on the test system:
[root@audit ~]# ausearch -ts today -m USER_LOGIN
-
Multiple record types can be specified, the results include events which contain either record type. While logged into the audit.example.com system as root, run the following command to see all of the service start and stop events:
[root@audit ~]# ausearch -ts this-month -m SERVICE_START -m SERVICE_STOP
-
The -i option instructs
ausearchto interpret the results, translating some fields into a more human readable form. The -k option searches on the key assigned to an audit rule. -
While logged into the audit.example.com system as root, run the following command to see all events from today matching the access key:
[root@audit ~]# ausearch -ts today -i -k access
-
The --uid option searches for events that match the given UID.
-
While logged into the audit.example.com system as root, run the following command to see today’s events from the auditlab user that match the time-change key:
[root@audit ~]# ausearch -ts today -i -k time-change --uid auditlab
-
The -f option searches for events that match on the given file name.
-
While logged into the audit.example.com system as root, run the following command to see all of today’s accesses of the project_tps_report.txt file:
[root@audit ~]# ausearch -ts today -i -f project_tps_report.txt
-
Finally, we can search for audit events generated by our custom filter rule.
-
While logged into the audit.example.com system as root, run the following command to see all events from today matching the rhkey key:
[root@audit ~]# ausearch -ts today -i -k rhkey
Included in the audit userspace tools are three utilities which can be used to
generate a number of reports from the audit log: aureport, aulast, and
aulastlog. The aureport tool can generate a number of different reports,
all of which are described in the
aureport(8) manpage.
-
While logged into the audit.example.com system as root, run the following command to create an audit report for today’s activity:
[root@audit ~]# aureport -ts today --summary
-
The
aulasttool generates a report similar to thelastcommand, except the information is collected from the audit log instead of the less reliable utmp logs. The aulast(8) manpage provides details on how to runaulast, without any options the output is familiar with thelastcommand. -
While logged into the audit.example.com system as root, run the following command to see an example of an
aulastreport:[root@audit ~]# aulast
-
Similar to
aulast,aulastlogis designed as a replacement for thelastlogcommand; the important difference being thataulastlogcollects data from the audit log. The aulastlog(8) manpage provides more information, but runningaulastlogwithout any options results in a useful report. -
While logged into the audit.example.com system as root, run the following command to see an example:
[root@audit ~]# aulastlog
In addition to searching through the audit logs, the ausearch tool can also
be used to transform the results into different formats. If you have already
done the rest of this lab, you are most likely familiar with the default raw
and the interpreted formats. In addition to these formats, there are also
csv and text formats which can be selected using the --format argument.
The --format option, as well as several others which can customize the output
of ausearch, can be found in the
ausearch(8) manpage.
-
While logged into the audit.example.com system as root, run the following commands to see samples of the csv and text formats:
[root@audit ~]# ausearch -ts today --format csv [root@audit ~]# ausearch -ts today --format text
-
The csv output is particularly interesting as it can be imported into LibreOffice or any other spreadsheet program that accepts files in the Comma Separated Values (CSV) format.
-
While logged into the audit.example.com system as root, run the following command to transform today’s audit log into the CSV format suitable for use within LibreOffice:
[root@audit ~]# ausearch -ts today --format csv --extra-labels --extra-obj2 > /tmp/audit.log.csv
-
Next, let’s transfer this CSV file from the audit.example.com system to the workstation bastion host system using
scp. Then, we’ll open the CSV file using LibreOffice from the workstation bastion host.
-
If not already there, log into to the workstation bastion host as lab-user from your desktop system replacing GUID with your lab’s GUID. Use the password r3dh4t1!
[localhost ~]$ ssh [email protected] -
Now, let’s transfer the CSV file from the audit.example.com system to the Desktop of the workstation bastion host system using
scp.[lab-user@workstation-GUID ~]$ scp [email protected]:/tmp/audit.log.csv /home/lab-user/Desktop
-
Now, let’s take a look at this CSV file from your workstation bastion host.
-
Go back to your Lab Information webpage and click on the console button for your workstation bastion host. Login as lab-user with r3dh4t1! as the password.
-
Notice the CSV file you just copied over from the audit.example.com system on the Desktop of your workstation bastion host.
-
Double click on the audit report to view it. Click Ok on the Text Import box.
-
Take a look at your CSV report.
If you wanted to re-do all of these audit lab exercises from scratch, you can reset your lab system. In order to reset the system used for this audit lab exercise, run the following commands as root on audit.example.com:
[root@audit ~]# rm /etc/audit/rules.d/* [root@audit ~]# cp /usr/share/doc/audit-*/rules/10-no-audit.rules /etc/audit/rules.d [root@audit ~]# augenrules --load [root@audit ~]# userdel -r auditlab