To do this, the monitoring package must be installed. In a standard/standard installation mode, this is installed by default on most distributions. Anyway, one could simply query the package using the native rpm command, as shown below: c) To verify the execution of the /sbin/modprobe command, which is responsible for adding/removing modules from the server kernel, add the following rule: – To define persistent audit rules in reboots, you must either include them directly in the /etc/audit/rules.d/audit.rules file, use the augenrules program, which reads the rules located in the /etc/audit/rules.d/ directory. If we continue to switch to the rules.d directory, there is a file with the same name audit.rules. So the question is, where exactly do we add the review rules. On RHEL 8.6 and later, copy the preconfigured rules file 44-installers.rules from the /usr/share/audit/sample-rules/ directory to the /etc/audit/rules.d/ directory: We need to grep the custom key that we usually added to make it easier to find the generated audit log file. Reload the systemd daemon to retrieve the changes to the auditd.service file: type=PROCTITLE msg=audit(15/04/2022 19:00:23.025:871): proctitle=vi /etc/fstab We will add the above rules in the audit.rules file to persist them. After auditd is configured, start the service to collect audit information and record it in log files. Use the following command as root to start auditd: If it doesn`t show any results, go ahead and install it by running the “yum install audit” command (“dnf install audit” in the case of RHEL8.x). Because Audit runs as a daemon in the background, it is important to ensure that it is started and enabled. So, let`s look at this now and enable/enable otherwise: type=PATH msg=audit(1650029423.025:871): item=0 name=”/etc/fstab” inode=17004757 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 Default: The auditing system stores log entries in the /var/log/audit/audit.log file; When log rotation is enabled, rotated watch files are .log stored in the same directory. The main audited configuration file → /etc/audit/auditd.conf For example, if the auditd daemon is running, the following command creates a new event in the audit log file: Once you have the rules in the /etc/audit/rules.d/ directory, load them by running the augenrules script with the –load directive: Find the type of message in the audit log USER_LOGIN: This specifies the timestamp of the audit event being logged. It`s in the “time_stamp:ID” format.
In this example, the unique ID is 871. The monitoring system works with a set of rules that define what is recorded in the log files. Audit rules can be set on the command line using the auditctl utility or in the /etc/audit/rules.d/ directory. This tutorial will show you how to set file system rules in RHEL/CentOS/Rocky Linux. At this point, you should understand that the monitoring system operates according to a set of rules that define what should be recorded in the log. There are three types of audit rules: control rules, file system rules, and system call rules. So far, we have seen how to define audit control rules. Now it`s time to learn more about the second type of monitoring rule, file system rules. Here we see how to define audit file system rules using detailed examples. Learn more about RHEL documentation. Pages linked to this website: audit_request_status(3), audit_set_backlog_limit(3), audit_set_backlog_wait_time(3), audit_set_enabled(3), audit_set_failure(3), audit_set_pid(3), audit_set_rate_limit(3), get_auditfail_action(3), set_aumessage_mode(3), auditd.conf(5), auditd-plugins(5), zos-remote.conf(5), audit.rules(7), audispd-zos-remote(8), auditctl(8), augenrules(8), aureport(8), ausearch(8), pam_loginuid(8), systemd-update-utmp.service(8) # systemctl is-active audited|| systemctl start auditd Note that the /etc/audit/audit.rules file is generated when the monitored service starts. The files in /etc/audit/rules.d/ use the same auditctl command-line syntax to specify rules.
Blank lines and text after a pound sign (#) are ignored. Well, the answer is, we add the rules in the audit.rules file, which is located in the rules.d directory. Once we add the rule and restart the server or restart the monitored service, the audit.rules file in the audit directory is automatically generated (if it does not already exist) and the same rules are replicated here. For beginners, it can be confusing to add the rules to the monitoring rules file. First, let`s look at the structure of the monitoring file. Preconfigured rules files stored in this directory→ /usr/share/audit/sample-rules/ You can add additional rules for other utilities that install software, such as pip and npm, using the same syntax. In RHEL 8.6 and later, you can use the preconfigured 44-installers.rules to configure Audit to monitor the following utilities that install software: Persistent auditing rules are stored in the /etc/audit/rules.d/ → directory. By default, rpm already provides SOFTWARE_UPDATE audit events when a package is installed or upgraded. You can list them by typing ausearch -m SOFTWARE_UPDATE on the command line.
Let`s further divide the output data and understand the important fields/attributes of the audit message. You can temporarily disable auditd with the # auditctl -e 0 command and re-enable it with # auditctl -e 1. Note: All these added audit rules are not persistent, to make them persistent, you need to add them to the `/etc/audit/rules.d/audit.rules` file and restart the audited daemon. The eyerules command can also be used to create this list. Follow these steps to disable the augenrules utility. This modifies Audit to use the rules defined in the /etc/audit/audit.rules file. The monitored default configuration should be appropriate for most environments. However, if your environment must adhere to strict security policies, the following settings are suggested to configure the audit daemon in the /etc/audit/auditd.conf file: The service command is the only way to properly interact with the monitored daemon.
You must use the service command for the aaudi value to be registered correctly. You can only use the systemctl command for two actions: enable and state. # auditctl -a exit,always -F arch=b64 -F euid=0 -S execve -k rootcmd type=SYSCALL msg=audit(1650029423.025:871): arch=c000003e syscall=188 success=yes exit=0 a0=561c050e5da0 a1=7fa1d71a41ef a2=561c05102f00 a3=1c items=1 ppid=9859 pid=9935 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9 comm=”vi” exe=”/usr/bin/vi” subj=unconfined_u: unconfined_r:unconfined_t:s0-s0:c0.c1023 key=”fstab_changes” Next, let`s check if our rules work by making changes to the files that have been added for monitoring. Edit the /etc/hosts file to add a dummy IP address so that it is included in the audit.log file. b) To check all files in the /etc/audit/ directory for write, read, or attribute changes, add the following rule: Example 7.4. File system and system call rules in audit.rules Auditd documentation files → /usr/share/doc/audit/ Now check the audit log. If you are not sure where to generate the audit log, check the auditd.conf file, which specifies the default path to the log. In RHEL 8.5 and earlier, you can manually add rules to monitor utilities that install software in a .rules file in the /etc/audit/rules.d/ directory. a) To verify write access or attribute changes in the /etc/hosts file, add the following rule. It is added to the audit log file when this rule runs.
We`ve also added a custom key to make it easier to search the audit .log file. Log files are stored in the /var/log/audit → directory (and rotate by the log rotation). First, let`s look at which audit reports were generated or collected with the keyword “fstab_changes” (a small snippet is added here for reference). Finally, “aureport” is another useful command that can be used during the audit. Refer to the man page of this command for details. Best wishes! If we list the files/folders in the audit directory, we will notice an audit.rules file. Most of the time, it becomes difficult to know which user triggered the system restart. Was the restart performed by a user or system thread? To understand and track these activities, we could rely on the demon of verification.
By default, the restart triggered by all non-root users is tracked by auditd when enabled. We were able to track system restart messages using ausearch utility. In addition, you can use the auditctl command to read rules from a file specified with the -R option, for example: # auditctl -a always,exit -S unlink -S unlinkat -S rename -S Comment out the line that contains augenrules and uncomment the line with the auditctl command -R: Where are the audited service configuration and log files stored? You can order monitoring rules by using a numbering scheme. For more information, see the /usr/share/audit/sample-rules/README-rules file. Copy the /usr/lib/systemd/system/auditd.service file to the /etc/systemd/system/ directory: In RHEL 8, the audit dispatch daemon (audisp) functionality is integrated with the audit daemon (auditd). By default, plug-in configuration files that allow real-time scanners to interact with audit events are located in the /etc/audit/plugins.d/ directory. All the rules we write follow the following syntax when we define them using the auditctl utility. You can also define the rules through the audit.rules file.
In this case, simply remove the auditctl syntax from the lower syntax to add the rules. This will be further clarified if we continue below. After a new rule has been added to the /etc/audit/rules.d/audit.rules file, the auditd daemon must be restarted using the service command, not the systemctl command. After the service is restarted, running the auditctl -l command displays all newly added audit rules: A number of other actions can be performed on auditd with the service`s audited action command, where the action can be one of the following: Rules are not intended to be used at the same time.