Creating Custom Audit Rules in CentOS 7

As we work our way through this tutorial you will learn ho to list existing audit rules and moving onto creating custom audit rules in the CentOS 7 Linux audit system. This makes up part of your study material for LPIC-3 303 Linux Security along with my other tutorials on the series.

Creating Custom Audit Rules

The audit system in CentOS 7 is already configured to log certain security events; however, we may need to extend this with our own log entries and we now look in more detail at listing existing audit log rules and creating custom audit rules on our CentOS 7 system.

To list existing rules we can use the command auditctl:

$ sudo auditctl -l
No rules

We can see that,as yet, we have not created any rules. We, of course, do have some configuration options that have been set for our CentOS 7 distribution. We can use the status options, -s, to auditctl:

$ sudo auditctl -s

enabled 1
failure 1
pid 2253
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
loginuid_immutable 0 unlocked

The backlog_limit is currently set to 8192 buffers. this controls the queue area for logging to the audit system. If many events occur at the same time and disk subsystem is already busy, then it is possible  that events will be lost if the buffers become full. We can see that we currently have not lost any log entries and the system is working well. We may well find that during busy periods that this value needs to be increased, if the lost value was often showing log entries were being dropped . To increase it to 10000 we would use:

$ sudo auditctl -b 10000

The output will show the status of auditd again, along with the newly set value. Now, I knew that the option was -b to set the backlog_limit. If you are unsure or you need to research other settings then review the man page.

$ man auditctl

Having made the change it will remain in place until a reboot or the service is restarted. To persist the setting we would need to add the setting to the audit.rules file. Even though this is a configuration option, it is set within the rules file:

$ sudo cat /etc/audit/rules.d/audit.rules

## First rule - delete all
-D

## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192

## Set failure mode to syslog
-f 1

These setting are read in the order they appear in the file. First we ensure that all current configuration and rules are deleted with -D. We then set the backlog limit with the same -b option. To persist any change to the value we wold write the new value here. We will leave it at the original value. The option -f is used, in this case, to ensure logging continues via the syslog mechanism in the vent of a failure with auditd.

We can read this file in directly, so an option is to make the change in the file. This will allow for persistance. With the value set in the file we can then read the file into the running configuration with -R. We will use this to set to the original value:

$ sudo auditctl -R /etc/audit/rules.d/audit.rules

We read the file settings into the system, these settings are dislayed. Then they are dislayed a 2nd time as the settings are implemented.

We can add our own custom rules to this file and read them in with the option -R in the same way. For completeness, we will add a rule at the command line. We will watch for activity on the /etc/shadow file . As this file should be kept private we will look for changes to the permissions. We can watch for:

r Reads to the file

w Writes to the file

x File execution

a Attribute changes including the permissions and file ownership

We will use look at changes to the attributes to monitor permissions:

$ sudo auditctl -w /etc/shadow -p a -k shadow_perms

Setting the key, -k, we can search for this key in the audit log when the watch is triggered. If we implement a change to the file permissions we will be able to see the alert in the log.

$ sudo ausearch -k shadow_perms --start recent

The output will be quite verbose but we will see two log entries. The first showing the watch has been created. The second will be the alert. The alert will show the orginal mode of the file and who has changed the permssions and the command used.

Using alerts like this created with watch rules in the audit system we are able to monitor exactly what we need to on our system.

We can list the rules we have created on the system:

$ sudo auditctl -l

-w /etc/shadow -p a -k shadow_perms

It is this rule that would need to add the the audit.rules file to ensure persistence. If the setting is not persisted and we want to delete it from the running configuration we use -W

$ sudo auditctl -W /etc/shadow -p a -k shadow_perms

The video show the demonstration