Bookmark this page

Chapter 6. Recording System Events with Audit

Abstract

Goal	Record and inspect system events relevant to security by using the Linux kernel's Audit system and supporting tools.
Sections	Configuring Audit to Record System Events (and Guided Exercise) Inspecting Audit Logs (and Guided Exercise) Writing Custom Audit Rules (and Guided Exercise) Enabling Prepackaged Audit Rule Sets (and Guided Exercise)
Lab	Recording System Events with Audit

Configuring Audit to Record System Events

Objectives

Ensure that Audit is installed and configured to record system events, and that it forwards Audit messages to a central Audit server.

The Linux Audit System

The Linux Audit system is a mechanism in the kernel that provides a way to track security-related events and information on your systems. You define a set of rules that you load into the kernel to specify which events the kernel must record in the Audit log. The auditd system daemon writes the logged events to the local disk or forwards them to remote log servers. You can then use this information to discover and investigate the cause of violations or attempted violations of the system's security policy.

You can configure Audit to include or exclude events based on user identity, security contexts, or other labels. The Audit system can collect the following information about events:

The date, time, type, and outcome of an event
Sensitivity labels of subjects and objects
The identity of the user who triggered the event
Modifications to the Audit configuration and attempts to access Audit log files
The use of authentication mechanisms, such as SSH, Kerberos, and others
Changes to any trusted database, such as the /etc/passwd file
Attempts to import or export information into or out of the system

You might need to use the Audit system to meet the compliance requirements of particular security certifications. The National Information Assurance Partnership (NIAP) and Best Security Industries (BSI) have evaluated the Audit system for security compliance.

The Audit System is designed to meet or exceed the requirements of the following certifications or compliance guides:

The Controlled Access Protection Profile (CAPP)
The Labeled Security Protection Profile (LSPP)
Rule Set Base Access Control (RSBAC)
The National Industrial Security Program Operating Manual (NISPOM)
The Federal Information Security Management Act (FISMA)
The Payment Card Industry Data Security Standard (PCI DSS)
Security Technical Implementation Guides (STIGs)

Auditing Your System

The Audit system consists of two main parts: the kernel-side system call processing, and the user-space applications and utilities.

The kernel component receives system calls from user-space applications, and then filters them through the exclude filter. If a system call passes the exclude filter, then it is filtered through one of the following filters: user, task, fstype, or exit. Then, based on the Audit rule configuration, the kernel component sends the system call to the auditd daemon for further processing.

The user-space Audit daemon collects the information from the kernel and creates entries in a log file. Other Audit user-space utilities interact with the auditd daemon, the kernel Audit component, or the Audit log files. The auditctl command interacts with the kernel Audit component to manage rules and to control many settings and parameters of the event generation process. The remaining Audit utilities take the contents of the Audit log files as input and generate output based on the user's requirements.

Without any additional configuration, only a limited number of messages pass through the Audit system (mainly authentication and authorization messages, and SELinux messages). Administrators can add Audit rules to control the Audit system, watch files, or record information about any system call with the auditctl command. This customization is discussed later in this chapter. The remainder of this section focuses on how to configure the auditd daemon to process any logged events.

Configuring the Audit System Daemon

The audit package provides the auditd daemon for configuring the Audit system and searching the Audit logs.

You can configure Audit rules and the auditd daemon with the following files:

/etc/audit/auditd.conf

This is the primary file for configuring the auditd daemon.

/etc/audit/audit.rules

The auditd daemon uses this file to load Audit rules.

Do not edit this file. This file is generated from the files in the /etc/audit/rules.d directory when the auditd daemon starts.

/etc/audit/rules.d/

This directory contains manually configured Audit rules.

All files that have the .rules extension are combined in the /etc/audit/audit.rules file and are loaded into the kernel when the auditd daemon starts.

This section focuses on the /etc/audit/auditd.conf file, which configures the behavior of the auditd daemon. Rule files are discussed in a later section.

Important

When the auditd daemon starts, its systemd unit file automatically rebuilds the Audit rule set from rule files in the /etc/audit/rules.d/ directory and attempts to load them into the kernel. When the service is reloaded, it attempts to rebuild the rules file and load the new rules by running the augenrules command.

This service might fail if a control rule is loaded that makes the current rules immutable. In this case, you must reboot the system to change the loaded rule set.

Adjusting the Audit System Daemon to Manage Storage

Depending on the Audit rules that are loaded, the Audit logs can expand quickly. To prevent other processes from competing with the Audit logs for storage space and to improve performance tuning, mount a dedicated file system to the /var/log/audit/ directory.

In addition, many security policies require that when the Audit system cannot log an event to disk due to the lack of storage space, the system must immediately halt or drop to single-user mode. This requirement ensures that no event can occur without being logged. The auditd daemon has mechanisms to warn you if this is about to happen, and to take various actions when storage gets low.

To configure the auditd daemon behavior to comply with your security policy, you can adjust a number of variables in the /etc/audit/auditd.conf file:

log_file: This option specifies the location of the file that is used for storing logs; the default setting is: /var/log/audit/audit.log.
max_log_file: This option specifies the maximum log file size in MB to use the available space on the partition by triggering the max_log_file_action parameter.
max_log_file_action: This option decides what action is taken when the limit set in the max_log_file parameter is reached. Set this parameter to the keep_logs value to prevent Audit log files from being overwritten.
space_left: This option specifies the amount of free space left on the disk to trigger the action set in the space_left_action parameter. This parameter must be set to a number that gives the administrator enough time to respond and free up disk space.
space_left_action: Red Hat recommends that you set the space_left_action parameter to the email or exec value with an appropriate notification method.
admin_space_left: This option specifies the absolute minimum amount of free space to trigger the action set in the admin_space_left_action parameter. The parameter must be set to a value that leaves enough space to log actions performed by the administrator. This parameter usually suspends the auditd daemon or halts the entire system, leaving a small amount of free space so that you can fix the issue.
admin_space_left_action: Set this parameter to the single value to put the system into single-user mode, which allows the administrator to free up some disk space.
disk_full_action: This parameter specifies an action that is triggered when no free space is available on the partition that holds the Audit log files. Set this parameter to the halt or single values. This parameter ensures that the system is either shut down or operating in single-user mode when Audit can no longer log events.
disk_error_action: This parameter specifies an action that is triggered in case an error is detected on the partition that holds the Audit log files. Set this parameter to the syslog, single, or halt value, depending on your local security policies regarding the handling of hardware malfunctions.

Adjusting Audit System Settings to Improve Performance

You can improve the performance of the auditd service by adjusting the following settings in the /etc/audit/auditd.conf configuration file:

Set the flush parameter to the incremental_async value. The incremental_async parameter flushes the log file asynchronously for higher performance. The flush parameter works in combination with the freq parameter, which determines how many records can be sent to the disk before forcing a hard synchronization with the hard drive.
Set the freq parameter to the 100 value. These parameters ensure that Audit event data is synchronized with the log files on the disk by maintaining good performance during bursts of activity.

Remote Logging

You can send Audit messages to a remote system in two ways. You can either send messages to the rsyslog service and configure rsyslog to forward them to a remote server, or you can configure your system to send messages to the remote auditd service.

When configuring your system to use either method to send messages to a remote server, you should make two changes on the server in the /etc/audit/auditd.conf file:

Set the log_format = ENRICHED parameter to resolve the UID, GID, system call number, architecture, and socket address information before transmitting each event. This parameter ensures that the log information makes sense on a remote system that might have different values for these mappings.
Set the name_format = HOSTNAME parameter to include the machine's hostname in each message. This parameter makes it clear to which machine an Audit event belongs.

Rsyslog Remote Logging

If you are sending messages to the rsyslog service, then edit the /etc/audisp/plugins.d/syslog.conf file to include the active = yes line.

Configure the rsyslog service to collect remote Audit messages by editing the /etc/rsyslog.conf file. Open the 514/UDP firewall port for standard syslog logging. Other ports for other protocols are also supported by the rsyslog service.

Audit Remote Logging

If you are sending messages to a remote auditd daemon, then you must install the audispd-plugins package on your client. On the Audit client, edit the /etc/audit/plugins.d/audisp-remote.conf file to include the active = yes line. Edit the /etc/audit/audisp-remote.conf file to include a remote_server directive set to the IP address or hostname of the remote auditd server. Then, update the port directive if your remote server is not listening on the default 60/TCP port.

Ensure that the server's firewall allows connections to that port. Restart the auditd daemon to put this change into effect. You can perform a reboot to ensure that all services are restarted.

Warning

Both methods of sending Audit messages to a remote server use clear text protocols without encryption by default. This lack of encryption makes the content of the messages subject to interception and tampering.

The rsyslog service must be configured to use TLS authentication and encryption to protect your Audit log traffic.

You must configure the auditd daemon to use Kerberos authentication and encryption in the /etc/audisp/audisp-remote.conf file on the client and the /etc/audit/auditd.conf file on the server. See the audisp-remote.conf(5) and auditd.conf(5) man pages for details.

References

auditd(8), auditd.conf(5), audispd.conf(5), audisp-remote.conf(5), and audit.rules(7) 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/security_hardening/auditing-the-system_security-hardening

The upstream project documentation for Linux Audit is available at https://github.com/linux-audit/audit-documentation

Discuss Red Hat Security: Linux in Physical, Virtual, and Cloud

Go to community

Welcome to the Red Hat Security: Linux in Physical, Virtual, and Cloud (RH415) group!

Deanna

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Security: Linux in Physical, Virtual, and Cloud! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH415.Read more about Red Hat Security: Linux in Physical, Virtual, and Cloud here.

415

Revision: rh415-9.2-a821299