During our evaluations, we must confirm that a system generates and processes “audit logs” correctly. As there are no specific requirements, the number and type of records generated are primarily up to our discretion based on the control framework employed.

The auditor’s experience determines whether the generated log categories are sufficient based on the analyzed situation. However, assuming the role of an engineer tasked with configuring auditd on a Linux system, what configurations must ultimately be enabled?

In this article, we will begin with a very high-level control, develop intermediate requirements, and then transform them into an auditd configuration.

Translate Controls to Requirements

We often use the CIS CSC V8 as control framework. Chapter 8, dedicated to “Audit Log Management”, has several controls that require a system audit configuration:

8.2 – Collect Audit Logs – Collect audit logs. Ensure that logging, per the enterprise’s audit log management process, has been enabled across enterprise assets.

8.5 – Collect Detailed Audit Logs – Configure detailed audit logging for enterprise assets containing sensitive data. Include event source, date, username, timestamp, source addresses, destination addresses, and other useful elements that could assist in a forensic investigation.

We have a general idea of what information must be gathered, but the requirements must be clarified further. The CIS Controls Navigator maps controls to various frameworks, so take a look at what other frameworks require, by expanding the 8.2 mapping. We scroll down to the PCI v4.0 groups and discover finer-grained controls from which we can simply select those that apply to our use case.

We can now create our intermediate requirements:

• Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts
• Audit logs capture all invalid logical access attempts
• Audit logs capture all access to audit logs
• Audit logs capture all initialization of new audit logs, and all starting, stopping, or pausing of the existing audit logs
• Audit logs capture all changes to identification and authentication credential including, but not limited to: Creation of new accounts; Elevation of privileges; All changes, additions, or deletions to accounts with administrative access
• Audit logs capture all unauthorized access attempts to files
• Audit logs capture all MAC policy changes (SELinux)
• Audit logs capture all the usage of media (USB Keys, external Disks, etc.)
• Audit logs capture all time changes
• Audit logs capture all creation and deletion of system-level objects
• Make the auditd configuration immutable (to be changed, a reboot is required)

This article refers to CIS CSC V8 to illustrate the relationship between high-level controls and low-level configuration. You could simply implement the very detailed security controls outlined, for instance, in CIS Linux Server, but we recommend using them only after understanding the impact of the configuration on the system.

auditd Configuration

Now that we have the requirements, we can proceed with the auditd low level configuration. The auditd rules define what events should be audited. The rules are defined in the /etc/audit/rules.d/audit.rules file.

With preferred editor, add or modify rules in the file based on your auditing requirements. The syntax for the rules follows the auditctl command syntax. For example, to monitor changes to the /etc/passwd file, you can add the following rule:

## /etc/passwd monitor for write/change
-a always,exit -F path=/etc/passwd -F perm=wa -F key=passwd-changes

This rule filters write (w) and attribute (a) changes to the /etc/passwd file and associates it with the key passwd_changes. To configure the rules, refer to auditctl(8) — Linux manual page

Start with a Clean Rulebase

It is a good practice to start with a empty rulebase an tune some parameters.

## Clean all rules
-D
## Increase buffer to survive stressful situation
-b 8192
## Set failure mode to panic if the system should stop in case of auditd error
## Enable this if the system must not work without a functional audit log
# -f 2

Requirement: Audit Logs Capture All Actions Taken by Any Individual with Administrative Access, Including Any Interactive Use of Application or System Accounts

This requires the configuration of pam_tty_audit tool. From Unix PAM, Linux PAM (Pluggable Authentication Modules) provides flexible authentication services for applications and system services. Account, authentication, password, and session components govern authentication functions.

The enable option in /etc/pam.d/system-auth and /etc/pam.d/password-auth allows you to audit a user’s TTY input. Refer to pam_tty_audit(8) — Linux manual page for configuration parameters.

This also covers “Audit logs capture all invalid logical access attempts”, since both valid and invalid actions are audited.

Requirement: Audit Logs Capture All Access to Audit Logs

Monitoring auditd components offers visibility into the auditing process, assures audit trail integrity, validates configuration, and maintains system health.

This also covers “Audit logs capture all initialization of new audit logs, and all starting, stopping, or pausing of the existing audit logs”.

## Access to all audit trails.
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-to-audit-objects
-a always,exit -F path=/usr/sbin/aulast -F perm=x -F key=access-to-audit-objects
-a always,exit -F path=/usr/sbin/aulastlogin -F perm=x -F key=access-to-audit-objects
-a always,exit -F path=/usr/sbin/aureport -F perm=x -F key=access-to-audit-objects
-a always,exit -F path=/usr/sbin/ausearch -F perm=x -F key=access-to-audit-objects
-a always,exit -F path=/usr/sbin/auvirt -F perm=x -F key=access-to-audit-objects

Requirement: Audit Logs Capture All Changes to Identification and Authentication Credentials

Audit logs must record changes to identification and authentication credentials for security incident investigation, accountability, compliance, suspicious activity detection, forensic analysis, and incident response.

## Elevation of privileges
-a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=elevation-of-privileges
-a always,exit -F arch=b32 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=elevation-of-privileges
-a always,exit -F arch=b64 -S setresuid -F a0=0 -F exe=/usr/bin/sudo -F key=elevation-of-privileges
-a always,exit -F arch=b32 -S setresuid -F a0=0 -F exe=/usr/bin/sudo -F key=elevation-of-privileges
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=elevation-of-privileges
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=elevation-of-privileges
## All changes, additions, or deletions to accounts
-a always,exit -F path=/etc/group -F perm=wa -F key=account-change
-a always,exit -F path=/etc/passwd -F perm=wa -F key=account-change
-a always,exit -F path=/etc/gshadow -F perm=wa -F key=account-change
-a always,exit -F path=/etc/shadow -F perm=wa -F key=account-change
-a always,exit -F path=/etc/security/opasswd -F perm=wa -F key=account-change

Requirement: Audit Logs Capture All Unauthorized Access Attempts to Files

Audit logs should capture unauthorized file access to identify and mitigate potential security breaches or unauthorized access to sensitive data.

##- Unauthorized access attempts to files (unsuccessful)
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Requirement: Audit Logs Capture All the Usage of Media

Audit logs should capture data exports to detect and prevent unauthorized or suspicious exfiltration of sensitive information from the system.

##- Export to media (successful)
## You have to mount media before using it. You must disable all automounting
## so that its done manually in order to get the correct user requesting the
## export
-a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -F key=export
-a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -F key=export

Requirement: Audit Time Changes

Security, fraud detection, data integrity, compliance, forensic analysis, incident response, and system health require auditd time change monitoring.

## Time changes
-a exit,always -S adjtimex -S settimeofday -k time_change

Requirement: Audit Logs Capture All Creation and Deletion of System-Level Objects

Audit logs should capture modifications to system executables and libraries, manipulation of packages, and manipulation of kernel modules.

## For Fedora/CentOS/Red-Hat package monitor
-a always,exit -F perm=x -F path=/usr/bin/yum -F key=system-objects
## boot objects
-a always,exit -S all -F dir=/boot -F perm=aw -k system-objects
## System binaries
-a always,exit -S all -F dir=/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/sbin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/local/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/local/sbin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/sbin -F perm=aw -k system-objects
## system libraries
-a always,exit -S all -F dir=/lib -F perm=aw -k system-objects
-a always,exit -S all -F dir=/lib64 -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/lib -F perm=aw -k system-objects
## configuration files (most common)
-a always,exit -S all -F dir=/etc -F perm=aw -k system-objects
## systemd
-a always,exit -S all -F dir=/usr/lib/systemd/ -F perm=aw -k system-objects
## Kernel modules insert/remove
-w /sbin/insmod -p x -k system-objects
-w /sbin/rmmod -p x -k system-objects
-w /sbin/modprobe -p x -k system-objects
-a always,exit -F arch=b32 -S init_module -S delete_module -k system-objects
-a always,exit -F arch=b64 -S init_module -S delete_module -k system-objects

Requirement: Make Configuration Immutable

Auditd should have an immutable configuration to prevent unauthorized modifications that could compromise the integrity and reliability of the auditing system.

##Make the configuration immutable, a reboot is required to change the configuration settings or rulesets.
-e 2 

Summary

We have shown how, by beginning with a high-level security framework, a simple word within a control can become a complicated configuration file, which has the potential to have a substantial effect on the system.

In reference to the framework, it is necessary to develop intermediate requirements that are capable of being independently turned into low-level configurations. As the performance of the system is impacted by each filter, each intermediate requirement should be reviewed and configured only if it is necessary or if it contributes to an increased level of system security.

About the Author

Rocco Gagliardi has been working in IT since the 1980s and specialized in IT security in the 1990s. His main focus lies in security frameworks, network routing, firewalling and log management.

Links

• https://man7.org/linux/man-pages/man8/auditctl.8.html
• https://www.cisecurity.org/controls/cis-controls-navigator/
• https://www.man7.org/linux/man-pages/man8/pam_tty_audit.8.html