Auditing Linux Servers with Auditd

Monitoring and securing a Linux server is essential for administrators who want to protect their servers from unauthorized access, suspicious activities, or unintended changes.

This is where Auditd, the Linux Audit Daemon, comes into play. It is a powerful tool that allows you to track system events, monitor file access, and keep a detailed record of what happens on your Linux server.

In this guide, you will learn what Auditd is, how it works, and how to use it effectively to audit and secure your Linux servers.

I assume you're working on a properly set-up Ubuntu server. If not, check out my guide on preparing Ubuntu servers to get started.

What is Auditd?

Auditd is the user-space part of the Linux Auditing System, a built-in feature of the Linux kernel. It is a tool that helps you monitor and log events happening on your Linux server, making it easier to respond to and investigate security incidents.

Based on pre-defined rules, Auditd generates log entries to record as much information about the events that are happening on your server as possible.

Auditd can record important actions, like who accessed a file, which commands were run, or if someone made changes to critical system configuration files.

It works by listening for specific events triggered by the Linux kernel, such as:

• File access (read, write, execute).
• System call activities (what processes are doing).
• User logins and authentication attempts.
• Changes to files, directories, or system configurations.

Once these events are detected, Auditd logs them into a file located at:

/var/log/audit/audit.log

For example, if you want to know who modified the /etc/passwd file, Auditd can log the who, what, and when of that event.

In simple terms, Auditd gives you the ability to watch over your Linux server, record important activities, and keep track of changes to ensure everything is secure and under control.

Auditd Architecture

Linux distributions are divided into two key areas: kernel space, which is the core of the operating system, and user space, where user-level programs (like your web server, text editor, or any software you install) and services run.

The separation between the kernel and user-level programs helps ensure high security and stability, which is one of the main reasons Linux is so reliable.

This means that user-level programs cannot directly access system resources like hardware or kernel-controlled functions. Instead, they rely on system calls (syscalls) to ask the kernel to perform tasks for them.

Auditd operates in user space, meaning it runs outside the kernel but works closely with kernel features.

The Linux Auditing System, integrated into the Linux kernel, provides a framework for tracking and logging various activities on the server, especially security-related ones.

The kernel generates auditing data and sends it to Auditd in user space for processing.

As the user-space component of the Linux Auditing System, Auditd collects and manages this data, allowing administrators to review and analyze security-related activities happening on the server.

This seamless interaction between the kernel and Auditd ensures robust monitoring and auditing capabilities built into the Linux server.

Installing Auditd

For Debian-based distributions, like Ubuntu, you can install the latest version of Auditd along with its relevant plugins by running:

sudo apt install auditd audispd-plugins

This command ensures that both the core auditing functionality and additional plugins are installed.

After installation, the auditd service (daemon) is added. It is enabled and running by default, which you can verify using the sudo systemctl status auditd.service command.

Now, let’s check whether any Auditd rules are in effect by using the sudo auditctl -l command:

ivan@vm1:~$ sudo auditctl -l
[sudo] password for ivan:
No Rules
ivan@vm1:~$

As you see, we haven’t created any rules yet since we just installed Auditd.

The auditctl command is what we use to manage rules, and the -l option lists the rules.

Monitoring File Changes

Let's say that I want to monitor the /etc/ssh/sshd_config file for any changes.

This file is critical because it contains the configuration settings for the SSH service, which controls remote access to our server. Unauthorized modifications to it could lead to a security breach or unauthorized access.

To monitor changes to the file, we use the auditctl command to create a rule:

sudo auditctl -w /etc/ssh/sshd_config -p rwa -k sshd_changes

Here’s what each option does:

• -w: This stands for "watch", and it points to the object we want to monitor. In our case, it specifies the file to watch.
• -p rwa: This indicates the object's permissions we want to monitor. In our case, these are:
  • r: Read access to the file (when someone reads the contents).
  • w: Write permissions (modifications to the file content).
  • a: Attribute changes (metadata changes such as ownership or permissions).
• -k sshd_changes: Assigns a unique key (name) to the rule for easier searching in logs.

To confirm the rule was created, we list our rules again using the sudo auditctl -l command:

ivan@vm1:~$ sudo auditctl -l
[sudo] password for ivan:
-w /etc/ssh/sshd_config -p rwa -k sshd_changes
ivan@vm1:~$

Alright, our rule is there.

Now, let's test our rule to see how Auditd behaves when we interact with the /etc/ssh/sshd_config file.

To generate a read event, we'll use the cat command to simply view the contents of the /etc/ssh/sshd_config file:

sudo cat /etc/ssh/sshd_config

Next, let's modify the file to generate a write event. This could be something simple, like adding a comment to the file:

sudo sh -c 'echo "# Comment" >> /etc/ssh/sshd_config'

Finally, let's change the file's permissions to generate an attribute change event:

sudo chmod 600 /etc/ssh/sshd_config

This command changes the file's permissions so that only the root user has read and write access.

Now that we've interacted with the /etc/ssh/sshd_config file, we need to check the Auditd logs to verify that the events were captured correctly.

Analyzing Rule Logs

Let's analyze the logs that were generated by Auditd after we tested our rule.

We can use the ausearch command with the -i option to interpret the logs in a human-readable format and the -k option to filter by the key we assigned like this:

sudo ausearch -i -k sshd_changes

This will display all the events related to the /etc/ssh/sshd_config file that were triggered by the rule we created.

You can also use aureport to generate a summary of the generated logs filtered by the key:

sudo aureport -i -k | grep "sshd_changes"

This will give you a summarized report of the events that were captured, making it easier to review the activity related to the file.

Let's start by using the ausearch command. The first log entry you may see is something like this:

type=PROCTITLE .... : proctitle=auditctl -w /etc/ssh/sshd_config -p rwa -k sshd_changes
....
type=CONFIG_CHANGE .... : auid=ivan ses=345 subj=unconfined op=add_rule key=sshd_changes list=exit res=yes

This log entry indicates that the auditctl command itself was executed, which created the rule we applied to monitor the /etc/ssh/sshd_config file. The type=CONFIG_CHANGE line indicates that the rule was successfully added, and it also logs the rule's configuration.

Next, let's take a look at the second log entry, which corresponds to our test where we used the cat command to read the contents of the file:

type=PROCTITLE .... : proctitle=cat /etc/ssh/sshd_config 
type=PATH .... : item=0 name=/etc/ssh/sshd_config inode=66811 dev=08:00 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD .... : cwd=/home/ivan 
type=SYSCALL .... : arch=x86_64 syscall=openat success=yes exit=3 a0=AT_FDCWD a1=0x7ffeb3cb07b2 a2=O_RDONLY a3=0x0 items=1 ppid=34033 pid=34034 auid=ivan uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=345 comm=cat exe=/usr/bin/cat subj=unconfined key=sshd_changes

Let’s break it down:

• type=PROCTITLE: This line shows the command that was executed.
• type=PATH: This indicates that the /etc/ssh/sshd_config file was accessed.
• type=CWD: This shows the current working directory when the command was run, which was /home/ivan in this case.
• type=SYSCALL: This entry shows the system call made during the command execution. The openat syscall was used to open the /etc/ssh/sshd_config file for reading (0_RDONLY). It also contains details like the user (auid=ivan), process ID, and command that was executed (cat in this case), as well as the success status of the action (success=yes).

There should be three additional log entries corresponding to the last two tests we performed.

For the write test, when we attempted to add a comment to the /etc/ssh/sshd_config file using the sudo sh -c 'echo "# Comment" >> /etc/ssh/sshd_config' command, two log entries were created:

• The first log entry reflects the initial failed attempt. This entry shows the -bash command and an openat syscall with the O_WRONLY|O_CREAT|O_APPEND flags, but the operation was unsuccessful (exit=EACCES (Permission denied)) because the user Ivan (auid=ivan uid=ivan) did not have permission to modify the file directly. This happens because the redirection (>>) is handled by the shell, and without sudo, it runs as the unprivileged user.
• The second log entry corresponds to the actual execution of the command using sudo sh -c. Here, the command was executed with elevated privileges (auid=ivan uid=root), and the openat syscall succeeded (exit=3), allowing the file modification to proceed.

This dual-entry behavior is a result of how the shell and redirection operate in conjunction with privilege elevation via the sudo command.

Finally, for the attribute change test, when we modified the file's permissions using the chmod command, you should expect a log entry that includes the chmod command along with a fchmodat syscall.

Now, let's take a look at the logs generated by the aureport command to summarize the events we captured.

Here's a sample of the report output:

1237. 12/20/2024 11:18:49 sshd_changes yes /usr/sbin/auditctl ivan 45451
1238. 12/20/2024 11:25:38 sshd_changes yes /usr/bin/cat ivan 45887
1239. 12/20/2024 11:31:43 sshd_changes no /usr/bin/bash ivan 46283
1240. 12/20/2024 11:31:45 sshd_changes yes /usr/bin/dash ivan 46284
1241. 12/20/2024 11:31:49 sshd_changes yes /usr/bin/chmod ivan 46299

Each of these entries shows that the relevant actions (read, write, and attribute change) were successfully logged.

Let’s pipe the output of aureport into head instead of grep so that we can view the column headers:

ivan@vm1:~$ sudo aureport -i -k | head
[sudo] password for ivan:

Key Report
===============================================
# date time key success exe auid event
===============================================
...
ivan@vm1:~$

The status in the success column will be either yes or no, depending on whether the user successfully performed an action that triggered a rule violation.

If the event wasn’t caused by a rule being triggered, the status may appear as a question mark.

You may see multiple log events when opening or editing a file with a text editor because the various syscalls made by the editor are logged individually by Auditd.

Monitoring Directory Changes

In addition to monitoring individual files, Auditd allows you to monitor entire directories for changes. This is useful for tracking activities like the creation or deletion of files, changes to file attributes, and any modifications within sensitive directories.

Imagine a team of administrators needs a secure directory called secureadmins to store critical configuration files that should only be accessible to the administrators Ivan and Elie. This directory must be highly secure to prevent unauthorized access.

The commands we are going to use ensure that only the secureadmins group can access the directory.

First, create a group for the admins:

sudo groupadd secureadmins

After that, add users Ivan and Elie to the group:

sudo usermod -a -G secureadmins ivan
sudo usermod -a -G secureadmins elie

Then, create the directory:

sudo mkdir /secureadmins

Next, set the owner and group for the directory:

sudo chown nobody:secureadmins /secureadmins

This assigns the ownership of the directory to:

• Owner: nobody, which prevents any specific user from having special control.
• Group: secureadmins, so group members (Ivan and Elie) can access it.

Finally, set directory permissions:

sudo chmod 3770 /secureadmins

These permissions ensure the following:

• The SetGID ensures that files created in the directory inherit the group ownership.
• The Sticky Bit prevents users from deleting or renaming files they don’t own.
• Only members of secureadmins can access, modify, or create files in the directory.
• No access for anyone outside the group.

You can confirm the directory’s permissions with this command:

ls -ld /secureadmins/

The output should look like this:

drwxrws--T 2 nobody secureadmins 4096 Dec 27 10:00 /secureadmins/

Only Ivan, Elie, and processes explicitly running as part of the secureadmins group can access and modify files in the /secureadmins directory.

Now, to monitor the /secureadmins directory, run the following command:

sudo auditctl -w /secureadmins/ -k secureadmins_monitor

This time, I left out the -p option because I want track all actions (read, write, execute, and attribute changes) within the /secureadmins directory.

However, if I only want to monitor for when someone tries to cd into the directory, I would use the following command:

sudo auditctl -w /secureadmins/ -p x -k secureadmins_monitor

Now, perform actions like creating, modifying, or deleting files in /secureadmins/ as one of the group members to generate audit events. You can also change the directory's attributes, like permissions, to test attribute change logging.

Use the ausearch command to review logs for the secureadmins_monitor key:

sudo ausearch -i -k secureadmins_monitor

Or generate a summary of the logged events using the aureport command:

sudo aureport -i -k | grep "secureadmins_monitor"

If you see the root user when using the aureport command, it's because you switched to the user using the su command from root, instead of opening a new SSH session and logging in directly as that user.

Auditing Syscalls

Now, let's say I want to monitor when someone performs a certain action. To do this, I need to use syscalls.

This isn't difficult, but the syntax is a bit trickier compared to monitoring files or directories.

With this rule, I want to monitor whenever Ivan attempts to open or create a file:

sudo auditctl -a always,exit -F arch=b64 -F auid=1001 -S openat -k monitor_ivan

Here’s what each option does:

• -a always,exit: It tells Auditd to always log the event when the specified syscall happens, and to do so on exit, meaning when the syscall finishes.
• -F: It is used to build a rule field, and we can see two rule fields in this
  command:
  • arch=b64: This first rule field specifies the server's CPU architecture. b64 means that the server is running on a 64-bit x86_64 architecture. For 32-bit servers, use b32, but b64 is what you will mostly see nowadays.
  • auid=1001: This second rule field specifies the user ID number of the user that we want to monitor.
• -S openat: This specifies the syscall to monitor. In this case, it is the openat syscall, which is used to open or create a file.

Now, I will access the server as the user Ivan and run the cat command on the /etc/ssh/sshd_config file. Before doing so, I want to check if Auditd has already generated any logs. To do this, I use the command:

sudo ausearch -i -k monitor_ivan

To my surprise, I see numerous log entries, even though Ivan hasn’t done anything on the server yet.

• In the second log entry, I see that Ivan accessed the /etc/passwd file.
• In the third log entry, I see that Ivan accessed the /etc/login.defs file.
• Ivan also accessed the /etc/group file.

However, Ivan didn’t choose to access these files directly. These actions were performed automatically by the server during the normal login process.

If I now use the cat command to see the content of the /etc/ssh/sshd_config file, it will generate even more log entries because running this command requires the server to load additional files in the background.

This highlights an important point: when creating Auditd rules, you need to carefully consider what you want to monitor. If your rules are too broad, you might end up with an overwhelming number of log entries, making it difficult to find the information you actually need.

To effectively monitor someone’s actions, you should create more specific rules to avoid collecting excessive, irrelevant information.

Making Rules Persistent

By default, any rule we add from the command line will only persist until we reboot the server. Once we reboot the server, these rules will be lost and the monitoring will stop.

This is because the auditctl command modifies the runtime configuration of Auditd, meaning the changes are active for the current session but do not persist after a reboot.

To ensure rules persist after a reboot, we need to save them to a rule file inside the /etc/audit/rules.d/ directory. For example, create a file called custom.rules and add our previous rule like this:

-w /secureadmins/ -k secureadmins_monitor

Next, restart the auditd service to apply the rule:

sudo systemctl restart auditd.service

Restarting the auditd service inserts all rules into the audit.rules file located in the /etc/audit/ directory. Whether the rules are in a single file or spread across multiple files in /etc/audit/rules.d/, Auditd reads them all.

If you examine the /etc/audit/audit.rules file after restarting, you'll find the rules appended at the end, like this:

## This file is automatically generated from /etc/audit/rules.d
-D
-b 8192
-f 1
--backlog_wait_time 60000
-w /secureadmins/ -k secureadmins_monitor

Here’s what each part of the file means:

• -D: Deletes all current rules to start with a clean slate. This means any rules added via the command line will be removed during the service restart (or reboot) since restarting it will read the audit.rules file again.
• -b 8192: Sets the size of the audit backlog buffer. A larger buffer prevents event loss during high log generation. If the buffers fill up, the server stops generating audit events.
• --backlog_wait_time 60000: Sets the backlog wait time to 60 seconds. This determines how long a process waits for buffer space before dropping audit events.
• -f: Defines the failure mode for critical errors:
  • 0 (Silent): Ignores errors and logs them silently, prioritizing uptime.
  • 1 (Default): Logs errors and continues running, useful for general-purpose servers.
  • 2 (Panic): Halts the system for high-security environments, ensuring no operations proceed without auditing.

The last line in the file is our rule, added from the /etc/audit/rules.d/custom.rules file.

The first four lines in audit.rules come from the default /etc/audit/rules.d/audit.rules file. To modify these settings, such as changing the failure mode to -f 2, edit the /etc/audit/rules.d/audit.rules file and restart the auditd service.

Finally, I want to introduce another way to manage rules using the augenrules command, which reads rules from the /etc/audit/rules.d/ directory.

Let’s say you’ve just installed Auditd and added your rules using rule files in the /etc/audit/rules.d/ directory. Once your rules are in place, you want to make them persistent across reboots and apply them.

Here’s how:

ivan@vm1:~$ sudo auditctl -l
[sudo] password for ivan:
No rules
ivan@vm1:~$ sudo vim /etc/audit/rules.d/custom.rules
ivan@vm1:~$ sudo augenrules --check
/usr/sbin/augenrules: Rules have changed and should be updated
ivan@vm1:~$ sudo augenrules --load
...
ivan@vm1:~$

First, we check for any changes. If there are changes, the command will detect them. Then, we use the --load option to apply the changes. This automatically appends any newly added rules to the end of the /etc/audit/audit.rules file. If you remove a rule and rerun the commands, it will detect and apply the change as well.

The great thing about this approach is that you can check for changes and apply them without restarting the auditd service.

Using Predefined Rulesets

In the /usr/share/doc/auditd/examples/rules directory, you’ll find several predefined rulesets. To use any of these rulesets, simply copy the relevant .rules file to the /etc/audit/rules.d/ directory.

For example:

sudo cp /usr/share/doc/auditd/examples/rules/30-pci-dss-v31.rules /etc/audit/rules.d/

Once copied, restart the auditd service to apply the new rules, or use the sudo augenrules --load command.

If you find that a particular rule doesn’t work for your setup or needs to be adjusted, you can easily modify the rule file by commenting out unnecessary lines.

Deleting Rules

Now that you know how to add rules using the auditctl command or by creating custom rule files, let’s look at how to delete rules.

If you added a rule with the auditctl command (which only lasts for the current session and disappears after a reboot), you can delete it using the same command but replacing -w with -W.

For example, to add a rule:

sudo auditctl -w /secureadmins/ -k secureadmins_monitor

To delete the same rule:

sudo auditctl -W /secureadmins/ -k secureadmins_monitor  

If the rule was added using a rule file in the /etc/audit/rules.d/ directory, using the -W option will only delete the rule temporarily. It will reappear after a reboot because Auditd will read all rule files again.

To delete the rule permanently, remove the corresponding rule file from /etc/audit/rules.d/ and restart the auditd service, or use the sudo augenrules --load command.

If you want to delete a rule that monitors a specific syscall, use the -d option as follows:

sudo auditctl -d always,exit -F arch=b64 -F auid=1001 -S openat -k monitor_ivan

This will delete the rule we previously created to monitor whenever Ivan tries to open or create a file.

Generating Authentication Reports

By default, Auditd logs authentication attempts and user logins, both failed and successful. This is part of its core functionality to provide a security audit trail for the server.

These logs help identify potential brute-force attacks or unauthorized access attempts.

To generate an authentication report, we simply use the sudo aureport -au command. You may get a long list of authentication attempts. I will pipe the command into tail -4 to get the last 4 events:

25462. 12/30/2024 11:39:31 git 134.209.194.117 ssh /usr/sbin/sshd no 2468
25463. 12/30/2024 11:40:11 esroot 65.21.109.67 ssh /usr/sbin/sshd no 2474
25464. 12/30/2024 11:40:13 gitlab 65.21.109.67 ssh /usr/sbin/sshd no 2478
25465. 12/30/2024 11:40:35 apache 65.21.109.67 ssh /usr/sbin/sshd no 2482

As you can see, all are failed authentication attempts that Auditd logged.

If you want to get more information about a particular event, use the ausearch -a command followed by the event number, like this:

ivan@vm1:~$ sudo ausearch -a 2468
[sudo] password for ivan:
----
time->Mon Dec 30 11:39:31 2024
type=USER_AUTH msg=audit(1735558771.846:2468): pid=2637 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:authentication grantors=? acct="git" exe="/usr/sbin/sshd" hostname=134.209.194.117 addr=134.209.194.117 terminal=ssh res=failed'
ivan@vm1:~$

Ubuntu, by default, also logs authentication attempts in the /var/log/auth.log file.

Tracking User Login

Besides generating authentication reports using sudo aureport -au, you can also track user login activity with the aulast and aulastlog commands.

These utilities provide detailed insights into both historical and recent user logins, allowing you to effectively monitor and analyze login patterns on your server.

The aulast command displays a history of user login and logout events by searching through the Auditd logs.

Here's an example of the output:

ivan@vm1:~$ sudo aulast
[sudo] password for ivan:
ivan     pts/1        92.75.35.67      Sat Jan 11 09:51 - 20:33  (10:42)
ivan     pts/1        92.75.35.67      Sun Jan 12 08:27 - 19:47  (11:20)
reboot   system boot  6.8.0-51-generic Sat Jan 11 09:17 
ivan     pts/1        92.75.35.67      Mon Jan 13 08:56   still logged in
ivan@vm1:~$

From this output:

• The user ivan accessed the server multiple times from the same IP address (92.75.35.67) on different days.
• The session duration is shown in parentheses (10:42 means 10 hours and 42 minutes).
• Server reboots are also logged.
• A user currently logged in is marked with still logged in.

The aulastlog command shows the most recent login details for all users on the server.

Here's an example of the output:

ivan@vm1:~$ sudo aulastlog
[sudo] password for ivan:
Username         Port         From                       Latest
root             /dev/pts/0   92.75.35.67                01/13/2025 09:55:57
daemon                                                   **Never logged in**
ivan             /dev/pts/1   92.75.35.67                01/13/2025 10:18:21
...
ivan@vm1:~$

From this output:

• root last logged in on 01/13/2025 at 09:55:57 from the 92.75.35.67 IP address.
• ivan last logged in shortly after on 01/13/2025 at 10:18:21 from the same IP address.
• System users like daemon have never logged in, as indicated by **Never logged in**.

This utility complements aulast by focusing on the latest activity rather than providing a full login history.

Tracing a Process

Something cool I want to show you is how to trace a process! This allows you to monitor the syscalls, file accesses, and other activities performed by a running program or command.

I absolutely love this feature because it gives me the ability to dive deep into what happens behind the scenes when a specific command is executed. You can really understand what’s going on at a low level, which is great for debugging or just satisfying your curiosity!

To do this, we’ll use the autrace command, which temporarily adds Auditd rules to track the execution of a specific command.

Before we begin, make sure there are no existing Auditd rules. That’s right – you need to remove any previously created rules for autrace to work, or else you'll encounter an error.

Here’s what I do: I keep my rule files saved and use the augenrules command to load them. When I want to use the autrace command, I first delete all the current rules with:

sudo auditctl -D

Once I'm done using autrace, I simply restart the auditd service to apply my saved rules again, or use the sudo augenrules --load command.

The reason this works is that deleting rules using sudo auditctl -D only removes them temporarily, so it’s not an issue.

Now, after deleting all the rules, I want to trace the execution of the cat command against the sshd_config file. I do this by running the following command:

sudo autrace /usr/bin/cat /etc/ssh/sshd_config

This will allow autrace to track the execution of the cat command. The command will execute normally, and you will see the content of the file.

However, at the last line, you will see something like this:

Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 34358'

This indicates that the trace has finished.

You can use ausearch to review the detailed records of the traced execution, like this:

sudo ausearch -i -p 34358

Once you're finished with the trace, simply run the sudo augenrules --load command to apply your Auditd rules again.

Auditd's Configuration File

The primary configuration file for Auditd is auditd.conf, located in the /etc/audit/ directory, which controls various settings related to how the auditd service operates.

In most cases, it’s best to stick with the default settings and adjust them only when necessary.

While there are many settings available, I'll focus on a few important ones to give you a better understanding of how to configure Auditd for your needs.

The first setting you may want to change is the log_file setting, which controls the location of the Auditd log file. By default, the logs are written to /var/log/audit/audit.log. However, depending on your needs, you might want to change this path to a different location or storage device. The log file is where all the audit events are saved.

The next three settings you might want to adjust are max_log_file, max_log_file_action and num_logs.

The max_log_file setting controls the maximum size of the log file in megabytes. Once the file reaches this limit, it triggers an action defined by the max_log_file_action setting. By default, the action is set to ROTATE, which means that when the log file reaches the maximum size, Auditd will create a new log file and keep rotating older logs. The log files are numbered, with lower numbers being older. The num_logs setting controls how many rotated logs are kept before they are discarded.

By default, max_log_file is set to 8 MB, and num_logs is set to 5. For many setups, these defaults are sufficient to maintain an effective log history without consuming too much disk space. However, if your server generates a high volume of logs, you might need to adjust these values to suit your needs.

To apply any changes made to the auditd.conf file, remember to restart the auditd service using the sudo systemctl restart auditd command.

More About auditctl

So far, we’ve used the auditctl command to create, delete, and list rules. Now, let’s explore how you can use it to control Auditd itself.

With the auditctl command, you can check the status of Auditd and change some of its configurations directly from the command line.

I want to begin with the -s option, which displays the current status of Auditd, including its configuration details:

ivan@vm1:~$ sudo auditctl -s
[sudo] password for ivan:
enabled 1
failure 2
pid 75821
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 60000
backlog_wait_time_actual 0
loginuid_immutable 0 unlocked
ivan@vm1:~$

As you can see, Auditd is currently enabled. You can stop Auditd by running the sudo auditctl -e 0 command and re-enable it using sudo auditctl -e 1. This provides a quick way to control Auditd.

However, keep in mind that these changes are temporary. If you reboot the server, Auditd will start again. As mentioned earlier, the auditctl command modifies the runtime configuration of Auditd, so the changes are only active for the current session.

If you want to stop Auditd permanently, you can use the systemctl command to stop and disable the auditd service.

You can also use the auditctl command to change the failure mode, buffer size, and backlog wait time.

For example, you can change the failure mode with:

sudo auditctl -f 2

Change the buffer size with:

sudo auditctl -b 4096

And set the backlog wait time with:

sudo auditctl --backlog_wait_time 30000

However, for these changes to persist after a reboot, you need to modify the /etc/audit/rules.d/audit.rules file and restart the auditd service.

The -s option also provides additional information:

• The pid value shows the process number of the auditd service. If the pid is 0, it indicates that the auditd service is not running.
• The lost entry tells you how many events have been discarded.
• The backlog field indicates how many events are currently queued, waiting for Auditd to read them.

You can use the -v option to check the version of Auditd:

ivan@vm1:~$ sudo auditctl -v
[sudo] password for ivan:
auditctl version 3.1.2
ivan@vm1:~$

Finally, the -h option provides help about the usage of the auditctl command. It gives you a quick summary of the available options.

Conclusion and Final Thoughts

By now, you should have a solid understanding of how to configure and manage Auditd to meet your security and auditing needs.

However, keep in mind that while Auditd is a powerful tool for alerting you about potential security breaches, it doesn't actively harden the server against them. It’s important to combine Auditd with other security measures.

If you found value in this guide or have any questions or feedback, please don't hesitate to share your thoughts in the discussion section.

Your input is greatly appreciated, and you can also contact me directly if you prefer.