Red Hat Security: Linux in Physical, Virtual, and Cloud
This course is now legacy content
This course is using an outdated version of the technology and is now considered to be Legacy content. It will be removed from our catalog on June 28, 2024. Please be sure to complete your course and finish any remaining labs before that date. We recommend moving to version 9.2, which is the latest version currently available.
Objectives
After completing this section, students should be able to write their own audit rules to configure the system to collect information about particular events.
One of the powerful features of the Linux auditing 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 systems.
Adding Rules
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 at the top as well.
Important
The order of rules is important. Audit rules work on first-match-wins basis.
For example, if you 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, in that order, then any access to the /etc/sysconfig directory will not trigger the second rule.
This is 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 those two rules and access /etc/sysconfig, the rule that logs access to /etc/sysconfig will match for that event.
Operations on the /etc directory needed to access /etc/sysconfig might match the second rule as separate events (for example, to look up the inode for /etc/sysconfig in the /etc directory).
In this case, the operations on /etc itself are outside the scope of the /etc/sysconfig rule and do not match it.
There are three types of audit rules:
File system rules (or watches) audit access to files and directories.
System call rules audit execution of system calls made by processes communicating with the kernel to access system resources.
Control rules configure the audit system itself.
Setting File System Rules (Watches)
One of the easiest rules to add is a watch.
You can set watches on files and directories, and you can configure those watches to trigger on specific types of access (read, write, attribute change, and execute).
The open system call triggers watches.
Individual read or write calls do not trigger watches.
The basic syntax of a file system rule is as follows:
auditctl -w file -p permissions -k key
The -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 will 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.
Some examples of watches:
Add a watch to
/etc/passwdfor write and attribute change access. Label log messages with theuser-editkey.[root@demo ~]#auditctl -w /etc/passwd -p wa -k user-editAdd a recursive watch to the
/etc/sysconfigdirectory and all of its files and subdirectories. Watch for read, write, and attribute change access. Label log messages with thesysconfig-accesskey.[root@demo ~]#auditctl -w /etc/sysconfig -p rwa -k sysconfig-accessAudit all executions of binaries in the
/bindirectory.[root@demo ~]#auditctl -w /bin -p x
Important
Remember that a watch will not cross file system boundaries.
If you set a watch on /, and /tmp is a mount point that has a separate file system mounted on it, the rule will not apply to the contents of /tmp.
Setting System Call Rules
System call rules are more complex. The syntax of a system call rule is as follows:
[root@demo ~]#auditctl -a<list>,<action>\>[-F<filter-expression>]... \>[-C<compare-expression>]... \>[-S<system-call>]...
Rules are set on one of four lists:
exit, which evaluates all system calls when they exit and is the most commonly used
user, which evaluates events that originate in user space
task, which is rarely used and is only checked during the
fork(2)andclone(2)system callsexclude, which is sometimes used to filter events entirely from being logged (although there are other ways to do this)
If you replace -a with -A, Audit inserts the rule at the top of the list specified, instead of at the bottom.
The action is either always, to always record an event, or never, to never record that event.
Note
In most cases, the <list>,<action> you will use is 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 allows you to specify a filter based on audit record fields, such as auid, arch, and exit.
The -C option allows you to compare fields, for example the Audit UID of the calling process and the obj_uid (owner) of the file being accessed.
Finally, you can filter based on a system call with the -S option.
Note
On 64-bit systems you should write rules specifying a system call by name twice, once with the -F arch=b32 option and once with the -F arch=b64 option.
This 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 which applications may use.
Refer to the following examples:
Audit the 32-bit version of both the
renameandrenameatsystem call for all users whose original Audit user ID is equal to or greater than1000. Do not trigger the Audit rule if the process is under themysqld_tSELinux domain, and add therenamekey to the logs.[root@demo ~]#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/homedirectory to files or directories not owned by the original user that is now working asroot.[root@demo ~]#auditctl -a exit,always -F dir=/home/ -F uid=0 -C auid!=obj_uid
Note
When Audit starts, it assigns an Audit UID of 4294967295 to any existing process.
If you want to exclude those processes from your rules, you can add the -F auid!=4294967295 option to your rules.
Important
System call rules are checked for every system call issued on the system. This can reduce system performance. Therefore, you should try to keep the list of system call rules short and general.
Setting Control Rules
The final class of audit rule is the control rule.
These are used to modify the kernel configuration of Linux Audit.
These rules tend to be short and simple and are usually set at the top of the rules list, with the exception of the -e 2 rule to prevent further changes to the audit rule set.
Some examples of control rules include:
Remove all rules.
[root@demo ~]#auditctl -DRemove a file system rule monitoring
/bin. The path (/bin) must match the rule exactly.[root@demo ~]#auditctl -W /binSet the currently loaded rules to be immutable. This means that the rules cannot be changed again until the system is rebooted.
[root@demo ~]#auditctl -e 2
Removing Rules
You can remove file system watch rules with the -W option.
You need to use the -d option to remove rules added with the <list>,<action>-a or the -A options.
The -d syntax requires that the syscall name and every field and value match the rule being removed.
<list>,<action>
To remove all rules you can use the auditctl -D command.
Inspecting Rules
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 when storage cannot follow, as well as any rate limiting that is active.
Making Rules Immutable
With the auditctl -e [0|1|2] command, you can influence the current auditing mode.
Use the 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 you cannot longer add, remove or change rules, or stop the Audit subsystem.
To be able to make changes again, you need to reboot the entire system.
Important
If you set the -e 2 rule in a rules file, it must be the last rule loaded because subsequent attempts to set rules will not be allowed after it has been set.
Persistent Rules
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 would 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 the hash character (#).
When auditd 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 filanem command to read rules from a file.
References
auditctl(8), audit.rules(7), and intro(2) man pages
For more information, refer to the System Auditing chapter in the Red Hat Enterprise Linux 7 Security Guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/security_guide/#chap-system_auditing
