The Linux audit system provides a way to track security-relevant information on your system. It does not provide additional security itself, but it is useful for tracking this issues and helps you to take additional security measures, like SELinux.
Based on pre-configured rules, Audit generates log entries to record as much information about the events that are happening on your system as possible. This information is crucial for mission-critical environments to determine the violator of the security policy and the actions they performed.
What Audit is capable to do
- Date and time, type, and outcome of an event
- Sensitivity labels of subjects and objects
- Association of an event with the identity of the user who triggered the event
- All modifications to audit configuration and attempts to access audit log files
- All uses of authentication mechanisms, such as SSH, Kerberos, …
- Changes to any trusted database, such as /etc/passwd
- Attempts to import or export information into or from the system
- Include or exclude events based on user identity, subject and object labels,…
Use of audit systen is requirement for a number of security-related certifications, like:
- Controlled Access Protection Profile (CAPP)
- Rule Set Base Access Control (RSBAC)
- National Industrial Security Program Operating Manual (NISPOM)
- Federal Information Security Management Act (FISMA)
- Payment Card Industry - Data Security Standard (PCI_DSS)
- Security Technical Implementation Guides (STIG)
Use case
Watching file access
Audit can track whether a file or a directory has been accessed, modified, executed, or the file’s attributes have been changed.
Monitoring system calls
Audit can be configured to generate a log entry every time a particular system call is used.
Recording commands run by user
Audit can track whether a file has been executed, so rules can be defined to record every execution of a particular command.
Recording execution of system pathnames
Audit can watch the execution of a path even if it does not exist at rule invocation, or if the file is replaced after rule invocation.
Recording security events
Audit can be set up to record failed login attempts as well, and provides additional information about the user who attempted to log in.
Searching for events
Audit provides the ausearch utility, which can be used to filter the log entries and provide a complete audit trail based on a number of conditions.
Running summary reports
The aureport utility can be used to generate, among other things, daily reports of recorded events. A system administrator can then analyze these reports and investigate suspicious activity further.
Monitoring network access
The iptables and ebtables utilities can be configured to trigger Audit events, allowing system administrators to monitor network access.
System performance may be affected depending of the amount of information tha is collected by audit.
Linux audit capabilities
We can filter logged events for:
- User
- Group
- Audit ID (auid)
- Remote hostname
- Remote host address
- System call
- System call arguments
- File
- File operations
- Session
- Success or failure
It means that you can filter events of interest and tune to record only selected events.
Create your own set of rules (only of interest you)
Audit System Architecture
Linux Audit Architecture
The Audit system consists of two main parts:
- user-space applications
- kernel-side system call processing
The kernel component receives system calls from user-space applications and filters them through one of the following filters: user, task, fstype, or exit.
Once a system call passes the exclude filter, it is sent through one of the aforementioned filters, which, based on the Audit rule configuration, sends it to the Audit 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 Audit daemon, the kernel Audit component, or the Audit log files:
- audisp - the Audit dispatcher daemon interacts with the Audit daemon and sends events to other applications for further processing. The purpose of this daemon is to provide a plug-in mechanism so that real-time analytical programs can interact with Audit events.
- auditctl - the Audit control utility interacts with the kernel Audit component to manage rules and to control a number of settings and parameters of the event generation process.
- aureport or ausearch - take the contents of the audit log as input and generate output based on user’s requirements
Configuring audit daemon
The Audit daemon can be configured in the /etc/audit/auditd.conf file.
The default auditd configuration file should be suitable for most environment
Common configuring options are:
- log_file
- max_log_file
- max_log_file_action
- space_left
- space_left_action
- admin_space_left
- admin_space_left_action
- disk_full_action
- disk_error_action
- flush
Starting the audit service
The only way to interact (correctly) with theauditd daemon is command service.
To start auditd daemon:
gotanbl~:>service auditd start
To configure auditd to start at boot time:
gotanbl~:>systemctl enable auditd
Defining audit rules
The audit system operates on a set of rules that define what is to be captured in the log files. The following types of Audit rules can be specified:
- Control rules - Allow the audit system’s behavior and some of its configuration to be modified.
- File system rules - Also known as file watches, allow the auditing of access to a particular file or a directory.
- System call rules - Allow logging of system calls that any specified program makes.
Audit rules can be set:
- auditctl utility - not persistent after reboot
- /etc/audit/rules.d/audit.rules file - persistent after reboot
Remember: First match wins!
Defining rules with auditctl
The auditctl program is used to control the behavior, get status, and add or delete rules.
All commands which interact with the audit service and audit log files require root privileges
Defining control rules
These commands typically include deleting all rules, setting the size of the kernel’s backlog queue, setting the failure mode, setting the event rate limit, or to tell auditctl to ignore syntax errors in the rules and continue loading. Generally, these rules are at the top of the rules file.
-b -> sets the maximum amount of existing audit buffers
gotanbl~:>auditctl -b 8192
-f -> sets the action that is performed when a critical error is detected (0 - silent, 1 - printk[default], 2 - panic)
gotanbl~:>auditctl -f 2
-e -> enables and disables the audit system or locks its configuration (0 - disable auditing, 1 - enable auditing[default], 2 - lock auditing, config can’t be changed)
gotanbl~:>auditctl -e 2
-r -> sets the rate of generated messages per second (0 - none[default], non-zero - exceeded, failure flag in log)
-s -> reports the status of the audit system
gotanbl~:>auditctl -s
AUDIT_STATUS: enabled=1 flag=2 pid=0 rate_limit=0 backlog_limit=8192 lost=259 backlog=0
-l -> list all currently loaded rules
gotanbl~:>auditctl -l
-w /etc/passwd -p wa -k passwd_changes
-w /etc/selinux -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion
-D - deletes all currently loaded rules
Defining File system rules
To define a file system rule, use the following syntax:
auditctl -w path_to_file -p permissions -k key_name
- path_to_file - is the file or directory that is audited
- permissions - are the permissions that are logged
- r - read access to file or directory
- w - write access to file or directory
- x - execute access to file or directory
- a - change in the file’s or directory’s attribute
- key_name - is an optional string that helps you to identify which rule or set of rules generated a particular log entry
[Examples]
To define a rule that logs all write access to, and every attribute change of, all the files in the /etc/selinux/ directory
gotanbl~:>auditctl -w /etc/selinux/ -p wa -k selinux_changes
To define a rule that logs all write access to, and every attribute change of, the /etc/passwd file
gotanbl~:>auditctl -w /etc/passwd -p wa -k passwd_changes
To define a rule that logs the execution of the /sbin/insmod command
gotanbl~:>auditctl -w /sbin/insmod -p x -k module_insertion
Defining System call rules
To define a system call rule, use the following syntax:
auditctl -a action,filter -S system_call -F field=value -k key_name
- action and filter - specify when a certain event is logged. action can be either always or never. filter specifies which kernel rule-matching filter is applied to the event - can be one of the following: task, exit, user or exclude.
- system_call - specifies the system call by its name. List can be find with command ausyscall –dump, and meaning at link https://man7.org/linux/man-pages/man2/syscalls.2.html. Several system calls can be grouped into one rule, each specified after its own -S option.
- field=value - specifies additional options that further modify the rule to match events based on a specified architecture, groupID, userID, processID, …Full listing of options on https://linux.die.net/man/8/auditctl.
- key_name - is an optional string that helps you to identify which rule or set of rules generated a particular log entry
[Examples]
To define a rule that creates a log entry every time a file is deleted or renamed by a system user whose ID is 1000 or larger
gotanbl~:>auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
-F auid!=4294967295 exclude users whose login UID is not set
To define a rule that creates a log entry every time the adjtimex or settimeofday system calls are used by a program, and the system uses the 64-bit architecture
auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
Defining persistent audit rules in the /etc/audit/rules.d/audit.rules file
The audit.rules file uses the same auditctl command line syntax to specify the rules. Empty lines and text following a hash sign (#) are ignored.
To re-read audit.rules withoout restart daemon and after add some new rules run auditctl with -R option:
gotanbl~:>auditctl -R /etc/audit/rules.d/audit.rules
Defining Control rules
A file can contain only the following control rules that modify the behavior of the Audit system: -b, -D, -e, -f, -r, –loginuid-immutable and –backlog_wait_time.
# Delete all previous rules
-D
# Set buffer size
-b 8192
# Make the configuration immutable -- reboot is required to change audit rules
-e 2
# Panic when a failure occurs
-f 2
# Generate at most 100 audit messages per second
-r 100
# Make login UID immutable once it is set (may break containers)
--loginuid-immutable 1
Defining File system and System call rules
File system and system call rules are defined using the auditctl syntax.
-w /etc/passwd -p wa -k passwd_changes
-w /etc/selinux/ -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
-a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
Preconfigured rules files
In the /usr/share/doc/audit/rules/ directory, the audit package provides a set of pre-configured rules files according to various certification standards:
- 30-nispom.rules - Audit rule configuration that meets the requirements specified in the Information System Security chapter of the National Industrial Security Program Operating Manual.
- 30-pci-dss-v31.rules - Audit rule configuration that meets the requirements set by Payment Card Industry Data Security Standard (PCI DSS) v3.1.
- 30-stig.rules - Audit rule configuration that meets the requirements set by Security Technical Implementation Guides (STIG).
- 30-ospp-v42.rules - The purpose of these rules is to meet the requirements for Operating System Protection Profile (OSPP)v4.2.
To use this file, create a backup of your original rules and copy the configuration file of your choice in audit.rules file.
Using augenrules to define persistent rules
The augenrules script reads rules located at /etc/audit/rules.d/ directory and compiles them into an audit.rules file. The script processes all files that ends in .rules in a specifi order based on their natural sort order. The files in this directory are organized into groups with following meanings:
- 10 - Kernel and auditctl configuration
- 20 - rules that could match general rules but you want a different match
- 30 - Main rules
- 40 - Optional rules
- 50 - Server-specific rules
- 70 - System local rules
- 90 - Finalize (immutable)
Once you have the rules in the /etc/audit/rules.d/ directory, load them by running the augenrules script with the –load directive:
gotanbl:>augenrules --load
enabled 1
failure 1
pid 634
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
enabled 1
failure 1
pid 634
rate_limit 0
backlog_limit 8192
lost 0
backlog 1
Understanding audit log files
By default, the audit system stores log entries in the /var/log/audit/audit.log file.
[Example]
The following Audit rule logs every attempt to read or modify the /etc/ssh/sshd_config file:
-w /etc/ssh/sshd_config -p warx -k sshd_config
If we run command:
gotanbl~:>cat /etc/ssh/sshd_config
We got the following event in audit.log file:
type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287): cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967
Event consists of four records, which share the same timestamp and serial number. Records always start with the type= keyword. A detailed analysis looks as follows:
First record
type=SYSCALL - type of the record
All possible type values at link https://access.redhat.com/articles/4409591#audit-record-types-2
msg=audit(1364481363.243:24287): The msg field records:
- a timestamp and unique ID of the record in the form audit(timestamp:ID)
- various event-specific name=value pairs provided by the kernel or user space applications
arch=c00003e - information about the CPU architecture of the system (when searching with ausearch -i options - got x86_64 value)
syscall=2 - system call that was sent to the kernel (use ausyscall 2 to see name of the call)
success=no - whether the system call succeeded or failed
exit=-13 - specifies exit code returned by system call. Varies for different system call.
Interpret exit code with command ausearch –interpret –exit -13
a0=7fffd19c5592, a1=0, a2=7fffd19c5592, a3=a - arguments in hexadecimal notation, also could be interpreted with ausearch utility
items=1 - number of PATH auxiliary records that follow syscall record
ppid=2686 - Parent Process ID (PPID)
pid=3538 - Process ID (PID)
auid=1000 - Audit user ID - loginuid. This ID is the same for every process even the user’s identity changes.
uid=1000 - user ID of the user who started the process
user ID can be interpreted to user name with ausearch -i –uid UID
gid=1000 - group ID
euid=1000 - effective User ID
fsuid=1000 - file system user ID
egid=1000 - effective group ID
sgid=1000 - set group ID
fsgid=1000 - file system group ID
tty=pts0 - terminal from which the analyzed process was invoked
ses=1 - session ID
comm=“cat” - command-line name of the command that was used to invoke the analyzed process
exe="/bin/cat" - path of the executable
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 - SELinux context with which the analyzed process was labeled at the time of execution
key=“sshd_config” - administrator-defined string associated with the rule that generated this event
Second record
type=CWD - current work directory from which first record was executed
msg=audit(1364481363.243:24287) - holds the same timestamp and ID value as the value in the first record
cwd="/home/user_name" - path to the directory in which the system call was invoked
Third record
type=PATH - every path that is passed to the system call as an argument. In this example, one path (/etc/sshd/ssh_config) was used as argument.
msg=audit(1364481363.243:24287): - same timestamp and ID value as the value in the first and second record
item=0 - indicates which item of the total number of items references in the SYSCALL type record, the current record is - value 0 means it is the first item
name="/etc/ssh/sshd_config" - path of the file directory that was passed to the system call as argument
inode=409248 - inode number associated with the file or directory
To find file run find / -inum INODE -print
dev=fd:00 - specifies the minor and major ID of the device that contains the file or directory recorded in this event (/dev/fd/0)
mode=0100600 - file or directory permissions, encoded in numerical notation as returned by stat command. In this case, 0100600 -> -rw——- -> only root user has read and write permissions to the /etc/ssh/sshd_config
ouid=0 - owner’s user ID
ogid=0 - object’s group ID
rdev=00:00 - device identifier for special files only (not used, regular file)
obj=system_u:object_r:etc_t:s0 - SELinux context
objtype=NORMAL - intent of each path record’s operation in the context of a given syscall
cap_fp=none - data related to the setting of a permitted file system-based capability of the file or directory object
cap_fi=none - data related to the setting of an inherited file system-based capability of the file or directory object
cap_fe=0 - setting of the effective bit of the file system-based capability of the file or directory object
cap_fver=0 - version of the file system-based capability of the file or directory object
Forth record
type=PROCTITLE - specifies that this record gives the full command-line that triggered
proctitle=636174002F6574632F7373682F737368645F636F6E666967 - full command-line of the command that was used to invoke the analyzed process. Hexadecimal notation, ausearch -i to interpret value
Searching the audit log file
The ausearch utility is used to search audit log file for specific events. Supplying multiple options in one ausearch command is equivalent to using the AND operator between field types and the OR operator between multiple instances of the same field type.
[Examples]
To search the /var/log/audit/audit.log file for failed login attempts
gotanbl~:>ausearch --message USER_LOGIN --success no --interpret
To search for all account, group, and role changes
gotanbl~:>ausearch -m ADD_USER -m DEL_USER -m ADD_GROUP -m USER_CHAUTHTOK -m DEL_GROUP -m CHGRP_ID -m ROLE_ASSIGN -m ROLE_REMOVE -i
To search for all logged actions performed by a certain user, using the user’s login ID (auid)
gotanbl~:>ausearch -ua 1000 -i
To search for all failed system calls from yesterday up until now
gotanbl~:>ausearch --start yesterday --end now -m SYSCALL -sv no -i
Creating audit reports
The aureport utility allows you to generate summary and columnar reports on the events recorded in audit log files.
[Examples]
To generate a report for logged events in the past three days excluding the current
gotanbl~:>aureport --start 01/30/2021 00:00:00 --end 02/01/2021 00:00:00
To generate a report of all executable file events
gotanbl~:>aureport -x
gotanbl~:>aureport -x --summary
To generate a summary report of failed events for all users
gotanbl~:>aureport -u --failed --summary -i
To generate a summary report of all failed login attempts per each system user
gotanbl~:>aureport --login --summary -i
To generate a report from an ausearch query that searches all file access events for user ID 1000
gotanbl~:>ausearch --start today --loginuid 1000 --raw | aureport -f --summary