auditd#

1
/etc/audit/auditd.conf

1
# Log writing behavior
2
flush = INCREMENTAL
3
freq = 20
4

5
# Log rotation
6
num_logs = 5
7
max_log_file = 6
8
max_log_file_action = ROTATE
9

10
# Dispatcher
11
disp_qos = lossy
12
dispatcher = /sbin/audispd
13
name_format = NONE
14

15
# Disk space threshold
16
space_left = 75
17

18
# The "_action" options determine how errors or disk space issues should be handled:
19
admin_space_left_action = SUSPEND
20
disk_full_action = SUSPEND
21
disk_error_action = SUSPEND

1
/etc/audit/rules.d/*.rules

1
augenrules --load

1
/etc/audit/audit.rules

1
# ----------------------------
2
# Control Rules
3
# ----------------------------
4

5
# Delete all existing rules
6
-D
7

8
# Kernel backlog queue size
9
## Increase the buffers to survive stress events.
10
## Make this bigger for busy systems
11
-b 8192
12

13
# Set failure mode
14
# 0 = silent
15
# 1 = printk
16
# 2 = panic
17
-f 2
18

19

20
# ----------------------------
21
# File Watch Rules
22
# ----------------------------
23

24
-w /etc/passwd  -p wa -k passwd_changes
25
-w /etc/group   -p wa -k group_changes
26
-w /etc/shadow  -p wa -k shadow_changes
27
-w /etc/sudoers -p wa -k sudoers_changes

1
ausearch -k passwd_changes

Further Reading: What is auditd?#

In Linux, almost every security-related operation is ultimately handled by the Kernel.

For example:

• User login or logout
• Running sudo
• Executing a program
• Modifying /etc/passwd
• Changing file permissions (chmod)
• Deleting files
• Creating new processes

These operations are eventually translated into one or more System Calls, which are processed by the Linux Kernel.

To support security auditing and compliance requirements, the Linux Kernel provides a built-in Linux Audit Framework that records security-related events.

auditd (Linux Audit Daemon) is the userspace daemon that works with this framework.

Its responsibilities include:

• Receiving Audit Events generated by the Kernel

• Writing events to /var/log/audit/audit.log

• Managing log rotation

• Forwarding events to other plugins or logging systems (such as rsyslog or a SIEM platform)

The workflow can be summarized as follows:

1
System Call / File Change
2
            │
3
            ▼
4
Linux Kernel (Audit Framework)
5
            │
6
      Generate Audit Event
7
            │
8
            ▼
9
         auditd
10
            │
11
            ▼
12
/var/log/audit/audit.log

In general, the process works like this:

1. The administrator loads Audit Rules.

2. The Linux Kernel monitors system activity according to those rules.

3. When a rule is matched, the Kernel generates an Audit Event.

4. auditd receives the event and writes it to /var/log/audit/audit.log.

5. Administrators use tools such as ausearch and aureport to search or analyze the logs.

The responsibilities of each component are summarized below:

Understanding this architecture makes it easier to explain several common behaviors.

For example:

• Why do changes made with auditctl take effect immediately?

  • Because auditctl updates the Audit Rules stored in the Kernel directly, rather than modifying configuration files.

• Why do rules disappear after a reboot?

  • Because rules added with auditctl exist only in memory. They must be reloaded from configuration files after the system starts.

• Why can the Kernel continue generating Audit Events even if auditd is stopped?

  • Because auditing is performed by the Linux Kernel. Without auditd, there is simply no userspace daemon available to receive and write those events to disk.

A simple way to remember the Linux Audit System is:

Audit Rules tell the Kernel what to monitor; the Kernel detects events; auditd records them; and tools like ausearch and aureport help you analyze them.