Right, let’s talk about auditd. This is the part where most security guides get a little… dry. They’ll throw a wall of rules at you and tell you to go be safe. Not us. We’re going to get into the why. Because auditd is arguably the most powerful and most misconfigured tool on a Linux system. It’s the system’s paranoid, hyper-observant notetaker. It doesn’t stop anything from happening; it just writes down everything that does happen, in gruesome detail, so you can figure out who to yell at later.

Think of it like a black box flight recorder for your server. It’s useless until something goes horribly wrong, and then it’s the most important thing in the world.

The first thing you need to know is that the audit system consists of two main parts: the userspace daemon (auditd) that collects the events, and the kernel side that hooks into everything interesting. The rules you add tell the kernel what to watch for.

Installing and Basic Sanity Checking

First, let’s get it on the box. On your Red Hat/CentOS/Fedora world:

sudo yum install audit  # or 'sudo dnf install audit' on newer Fedora

And on your Debian/Ubuntu universe:

sudo apt install auditd audispd-plugins

Once it’s installed, start it and enable it to come up on boot:

sudo systemctl enable --now auditd

Now, let’s make sure it’s actually alive and not deeply unhappy. The auditctl command is your direct line to the running audit system.

sudo auditctl -s

This will spit out the current status. You’re looking for enabled 1 and pid with a number. If you see enabled 0, well, that’s a problem. The daemon’s probably not running. Go kick it with sudo systemctl restart auditd.

The Anatomy of an Audit Rule

This is where the magic happens, and also where most people’s eyes glaze over. A rule isn’t just random incantations; it has a structure. The most common and useful type is a file system watch rule, and it looks like this:

sudo auditctl -w /etc/passwd -p wa -k critical_account_change

Let’s break down this little masterpiece of paranoia:

  • -w /etc/passwd: The -w means “watch.” We’re telling the kernel to keep an eye on this specific path.
  • -p wa: The -p is for permissions. What are we watching for? w for write and a for attribute change. So, if someone modifies the file or changes its permissions/ownership, we want to know. You can use r for read and x for execute, but be very careful with r—on a busy system, you will log an ungodly amount of data.
  • -k critical_account_change: The -k is for a “key.” This is a free-text tag you add to the event. It’s your best friend later when you’re sifting through 5 million log entries. You can grep for this key to find all the related events. Always, always use a meaningful key.

Making Rules Persistent (So They Survive a Reboot)

Here’s the first “gotcha.” The auditctl command adds rules live to the running kernel. The moment you reboot, they’re gone. Poof. This has tripped up more than one sysadmin. To make them permanent, you need to write them to a rules file.

The main file is /etc/audit/rules.d/audit.rules (on Debian/Ubuntu) or /etc/audit/rules.d/audit.rules (on RHEL). You can just append your rules to this file, one per line, without the auditctl part.

So, our rule from above becomes a line in /etc/audit/rules.d/audit.rules:

-w /etc/passwd -p wa -k critical_account_change

To load all the rules from this file after you’ve edited it, you can run:

sudo augenrules --load

Or just restart the daemon:

sudo systemctl restart auditd

Always, and I mean always, follow up with sudo auditctl -l to list all loaded rules and verify your beautiful new rule is actually there. I’ve spent an hour debugging only to realize I had a typo in the rules file. Don’t be me.

Actually Reading the Darn Logs

The logs don’t live in /var/log/syslog or messages. Oh no, that would be too simple. They live in /var/log/audit/audit.log. And they are… dense.

Let’s say you want to see all the events related to our critical_account_change key:

sudo ausearch -k critical_account_change

This will vomit a bunch of events at you. To make it human-readable, especially for file path watches, pipe it into aureport:

sudo ausearch -k critical_account_change | aureport -f -i

The -i flag “interprets” numeric entities (like user IDs) into human-readable names. This is a lifesaver.

The Pitfalls and The “Oh Crap” Moments

  1. Performance: This is the big one. Every rule adds overhead. Watching a directory recursively (-w /home/ -p rwa) is a fantastic way to bring a system to its knees. Be surgical. Watch specific, important files, not entire directories, unless you have a very good reason and a very powerful machine.
  2. Log Rotation: audit.log will grow forever until it consumes all disk space, which will then take down your system. This is not a question of if, but when. Manage this in /etc/audit/auditd.conf. The max_log_file and max_log_file_action parameters are your friends. I usually set max_log_file_action = ROTATE and keep a sane number of old logs (like 10). Ignore this at your peril.
  3. The Noise: If you watch everything, you see nothing. The signal gets lost in the noise. Start with a few key rules: /etc/passwd, /etc/shadow, sudoers files, and critical application binaries. Then, as you get comfortable with the logs, add more based on your threat model.

The Linux Audit System is a beast, but it’s a tameable one. It asks you to be thoughtful about what you care about. And in security, that’s the whole point.