Red Hat Security: Linux in Physical, Virtual, and Cloud
Write your own Audit rules to configure the system to collect information about particular events.
One of the powerful features of the Linux Audit system is the ability to add your own Auditing rules. You can create rules to monitor system call usage and file access, or to configure Auditing rules for compliance with industry standard security certifications. You can also gain a better insight into how users and processes are using your system.
You can use the auditctl command to add Auditing rules from the command line.
By default, this command adds Auditing rules to the bottom of the current list, but you can insert rules to the start of the list as well.
Important
The order of rules is important. The first Audit rule that matches is the one that Audit applies. Audit does not apply any subsequent matching rules.
For example, you can configure two rules with separate keys, one to log all access to the /etc/ directory, and another to log all access to the /etc/sysconfig/ directory.
Then, any access to the /etc/sysconfig/ directory does not trigger the second rule.
The second rule is not triggered because the first rule matches as an event for every operation in the /etc/ directory and its subdirectories; the second rule is never reached.
If you reverse the order of these two rules and then access the /etc/sysconfig/ directory, the rule that logs access to the /etc/sysconfig/ directory matches the event.
Operations on the /etc/ directory that are needed to access the /etc/sysconfig/ directory might match the second rule as separate events (for example, to look up the /etc/sysconfig inode in the /etc/ directory).
In this case, the operations on the /etc/ directory itself are outside the scope of the /etc/sysconfig/ rule and do not match it.
The Audit system uses three types of rules:
File system (or watch) rules monitor access to files and directories.
System call rules monitor the execution of system calls that are made by processes that communicate with the kernel to access system resources.
Control rules configure the Audit system itself.
One type of rule that you can add is a watch rule.
You can set watch rules on files and directories, and you can configure watch rules to trigger on specific types of access (read, write, attribute change, and execute).
The open system call on a file that is monitored by a watch rule triggers the system to generate an Audit event based on the rule and the type of access that is requested.
However, individual read and write calls on a watched file that is already open do not trigger the watch rule.
The basic syntax of a file-system rule is as follows:
[root@host ~]# auditctl -w file -p permissions -k keyThe -w option takes the name of a file or directory to watch.
If the path is a directory, then the rule matches recursively all contents and subdirectories in that directory excluding subdirectories that are mount points.
The rule does not cross file systems.
The -p option takes a list of accesses to monitor by permission type.
rfor read accesswfor write accessxfor execute accessafor changes to attributes
The -k option takes a key to set on the Audit record to make it easier to find with a specific ausearch query.
The following examples demonstrate some custom watch rules:
Watch the
/etc/passwdfile for write and attribute change access. Label log messages with theuser-editkey.[root@host ~]#
auditctl -w /etc/passwd -p wa -k user-editAdd a recursive watch rule for the
/etc/sysconfig/directory and all its files and subdirectories. Watch for read, write, and attribute change access. Label log messages with thesysconfig-accesskey.[root@host ~]#
auditctl -w /etc/sysconfig/ -p rwa -k sysconfig-accessAudit all executions of binaries in the
/bin/directory.[root@host ~]#
auditctl -w /bin/ -p x
Important
Remember that a watch rule does not cross file-system boundaries.
If you set a watch on the / directory, and the /tmp directory is a mount point that has a separate file system mounted on it, then the rule does not apply to the contents of the /tmp directory.
System call rules are more complex. The syntax of a system call rule is as follows:
[root@host ~]# auditctl -a <list>,<action> \
[-F <filter-expression>]... \
[-C <compare-expression>]... \
[-S <system-call>]...Rules are set on one of four lists:
The exit list evaluates all system calls when they exit, and is the most commonly used.
The user list evaluates events that originate in user space.
The exclude list is sometimes used to filter events entirely from being logged (although there are other ways to do this).
The task list is rarely used and is only checked during the
fork(2)andclone(2)system calls.
If you replace the -a option with the -A option, then Audit inserts the rule at the start of the specified list, instead of at the end.
The action is either always (to always record an event), or never (to never record that event).
Note
Usually, use the <list>,<action> syntax (for example, exit,always), to always record the event when the system call exits.
You can filter events with the -F, -C, and -S options.
The -F option enables you to specify a filter based on Audit record fields, such as the auid, arch, and exit fields.
By using the -C option, you can compare fields, for example the Audit UID of the calling process and the obj_uid (owner) field of the file that is accessed.
Finally, you can filter based on a system call with the -S option.
Note
On 64-bit systems, write rules to specify a system call by name two times; first, with the -F arch=b32 option, and second, with the -F arch=b64 option.
This approach is necessary because every system call does not translate into the same number for the same name on 32- and 64-bit architectures, and 64-bit systems do provide the 32-bit system calls that applications might use.
The following examples show custom rules for specific circumstances:
Audit the 32-bit version of both the
renameandrenameatsystem call for all users whose original Audit user ID is equal to or greater than the1000ID. Do not trigger the Audit rule if the process is under themysqld_tSELinux domain, and add therenamekey to the logs.[root@host ~]#
auditctl -a exit,always -F arch=b32 -F auid>=1000 -S rename \ -S renameat -F subj_type!=mysqld_t -k renameRecursively audit every file-system access by the
rootuser under the/home/directory to files or directories that are not owned by the original user, and who is now working as therootuser.[root@host ~]#
auditctl -a exit,always -F dir=/home/ -F uid=0 -C auid!=obj_uidDisable auditing of failed
USER_LOGINevents for theexampleuser.[root@host ~]#
auditctl -a exclude,never -F auid=example \ -F msgtype=USER_LOGIN -F success=0
When Audit starts, it assigns the 4294967295 Audit UID to any existing process.
If you want to exclude those processes from your rules, then you can add the -F auid!=4294967295 option to your rules.
Important
System call rules are checked for every system call that is issued on the system. This can reduce system performance. Therefore, try to keep the list of system call rules short and general.
The final class of Audit rule is the control rule for modifying the kernel configuration of Linux Audit.
These rules tend to be short and are usually set at the start of the rules list, except for the -e 2 rule to prevent further changes to the Audit rule set.
Common control rules include the following examples:
Remove all rules.
[root@host ~]#
auditctl -DRemove a file-system rule that monitors the
/bin/directory. The path (/bin/) must match the rule exactly.[root@host ~]#
auditctl -W /bin/Set the currently loaded rules to be immutable. This rule means that the rules cannot be changed again until the system is rebooted.
[root@host ~]#
auditctl -e 2
You can remove file system watch rules with the -W option.
You must use the -d option to remove rules added with the <list>,<action>-a or the -A options.
The -d syntax requires that the <list>,<action>syscall name and every field and value match the rule that is being removed.
To remove all rules, you can use the auditctl -D command.
You can inspect your current rule set with the auditctl -l command.
To review the current status of Audit, you can use the auditctl -s command.
This command also displays information on the internal buffer sizes to store Audit messages, as well as any rate limiting that is active.
With the auditctl -e [ command, you can influence the current auditing mode.
Use the 0|1|2]auditctl -e -0 command to disable auditing.
Use the auditctl -e 1 command to enable auditing again.
Use the auditctl -e 2 to configure your rules as immutable, so that you can no longer add, remove, or change rules, or stop the Audit subsystem.
To be able to make changes again, you must reboot the entire system.
Important
If you set the -e 2 rule in a rules file, then it must be the last rule loaded because subsequent attempts to set rules are not allowed after the -e 2 rule has been set.
To make your Audit rules persistent, you can add them to the /etc/audit/rules.d/audit.rules file, or to any other file in the /etc/audit/rules.d/ directory as a file with the suffix .rules.
Rule files contain auditctl commands as you type them on the command line, but without the auditctl command itself.
You can add empty lines and comments to this file.
To include a comment, start the line with a number sign (#).
When the auditd daemon starts, it activates all rules from the /etc/audit/rules.d/audit.rules file, and the other .rules files in the /etc/audit/rules.d directory.
You can also use the auditctl -R command to read rules from a file.filename
References
auditctl(8), audit.rules(7), and intro(2) man pages
For more information, refer to the Auditing the System chapter in the Security Hardening guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/security_hardening/index#auditing-the-system_security-hardening
