Linux File Integrity Monitoring: Catching Stealthy Changes with AIDE

Table of Contents

Protecting Your Filesystem from the Unknown

I remember the panic of seeing a 2 AM SSH brute-force attack on one of my production nodes. Even after blocking the IP, a nagging question remained: what did they touch? Once an attacker gains a foothold, they often leave a back door or modify a system binary to hide their presence. You cannot rely on file timestamps alone. A sophisticated attacker will use touch to reset access times, making the file look untouched to the naked eye.

That is why I rely on File Integrity Monitoring (FIM). I use AIDE (Advanced Intrusion Detection Environment) to create a digital fingerprint of every critical file on my system. If even a single bit in a binary changes, AIDE flags it immediately. Think of it as a high-tech tripwire for your Linux filesystem.

FIM vs. Standard System Logging: Where AIDE Fits In

Security monitoring isn’t one-size-fits-all. To build a solid defense, you need to understand how different tools complement each other.

Standard Logging (Syslog/Journald)

Logs tell a story about events. They record when a user logs in or when a service fails. However, a root-level attacker can easily wipe these logs or stop the logging service entirely. Logs rarely tell you if the /usr/bin/ls binary was swapped for a malicious version.

Real-time Monitoring (Auditd/Inotify)

Tools like auditd track system calls as they happen. They are excellent for identifying who modified a file at 10:15 PM. The trade-off is performance. On a busy web server, auditd can generate gigabytes of data every hour, which quickly becomes a nightmare to analyze.

Snapshot-based FIM (AIDE)

AIDE takes a different approach. It creates a baseline database of file attributes, including permissions, sizes, and cryptographic hashes like SHA-512. When you run a check, AIDE compares the current disk state against this known-good snapshot. It is the gold standard for forensic analysis because it identifies exactly what changed, even if the logs were deleted.

The Reality of Using AIDE

Before deploying AIDE across your infrastructure, you should weigh the operational costs against the security benefits.

The Benefits

Zero Background Noise: AIDE is not a background daemon. It consumes zero CPU and RAM until you trigger a check, making it perfect for low-resource VPS instances.
Cryptographic Certainty: By using multiple hash algorithms, it is statistically impossible for an attacker to modify a file without triggering an alert.
Granular Control: You can exclude volatile directories like /var/log while maintaining strict watch over /etc/shadow.

The Challenges

Maintenance Overhead: Every time you run apt upgrade, you must update the AIDE database. If you forget, your next report will show hundreds of “false positives” from legitimate software updates.
Reactive Detection: AIDE is a detective tool, not a preventative one. It won’t stop a file from being modified; it only alerts you after the damage is done.
Database Security: If an attacker modifies your files and then runs aide --update, your baseline is compromised. You must store the database on a remote, read-only system to be truly secure.

Production Deployment Strategy

If you are deploying this in a production environment, don’t try to monitor everything at once. Start with a focused policy to avoid alert fatigue.

Focus on Binaries and Configs: Monitor /etc, /bin, /sbin, and /usr/bin. Avoid /var/tmp or /home unless you have a specific reason to watch them.
Off-site Storage: Immediately move your database to a remote secure server or a read-only volume after initialization.
Automated reporting: Schedule a daily cron job to email summaries to your security team so you don’t have to remember to check manually.

Step-by-Step Implementation Guide

This walkthrough uses Ubuntu 22.04, but the commands are nearly identical for other Debian-based distros and very similar for RHEL.

Step 1: Install AIDE

Start by updating your local package index and installing the utility.

sudo apt update
sudo apt install aide -y

During the process, you might see a prompt about mail configuration. Most admins choose “Internet Site” to allow the server to send reports via an SMTP relay.

Step 2: Initialize the Baseline

Next, you need to capture the current state of your system. This is your “known-good” baseline.

sudo aideinit

On a standard 50GB SSD with about 20% utilization, this usually takes 3 to 5 minutes. The command creates a new database file located at /var/lib/aide/aide.db.new.gz.

Step 3: Activate the Database

AIDE looks for aide.db.gz to perform checks. Since the initialization creates a .new file, you must rename it to make it active.

sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

I highly recommend copying this file to a separate, secure machine right now. If the server is compromised, this file is your only way to prove what changed.

Step 4: Simulating an Intrusion

To see it in action, let’s simulate a common attacker move: adding a backdoor user to the system.

echo "tempadmin:x:0:0:tempadmin:/root:/bin/bash" | sudo tee -a /etc/passwd
sudo aide --check

AIDE will produce a detailed report. It will show that /etc/passwd was modified and list the specific changes in file size and SHA-512 hash values.

Step 5: Customizing Your Rules

If AIDE is too noisy, you can refine what it watches. On Ubuntu, the configuration is managed in /etc/aide/aide.conf or files within /etc/aide/aide.conf.d/.

To monitor a specific directory like a web root with high-security settings, add a custom rule:

# Define a rule: p (permissions), i (inode), n (links), u (user), g (group), s (size), m (mtime), c (ctime), sha512 (hash)
WebRule = p+i+n+u+g+s+m+c+sha512

/var/www/html WebRule

Step 6: Updating After Software Changes

When you perform legitimate maintenance, like running apt upgrade, AIDE will correctly identify these as changes. To set a new baseline, update the database:

sudo aide --update
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Step 7: Automating Daily Checks

Manual checks are easily forgotten. I usually drop a script into /etc/cron.daily/aide-check to automate the process:

#!/bin/bash
/usr/bin/aide --check | mail -s "AIDE Report for $(hostname)" [email protected]

Ensure the script is executable:

sudo chmod +x /etc/cron.daily/aide-check

Final Thoughts on Database Integrity

The biggest risk with AIDE is the database itself. If I were an attacker with root access, my first move would be running aide --update to hide my tracks. To prevent this, some sysadmins store the database on a read-only USB stick. Others use a central server to push the database to the node, run the check, and immediately delete the local copy. Security is never a “set it and forget it” task, but AIDE gives you the visibility needed to trust your own filesystem again.