How to Install and Use AIDE on Linux for File Integrity Monitoring

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

Comparing File Integrity Monitoring Solutions on Linux

Did an unexpected port suddenly open on your server? Has malicious code been stealthily injected into your web files? The ultimate nightmare for any sysadmin is an attacker quietly tampering with system binaries or configuration files undetected. This is precisely where File Integrity Monitoring (FIM) comes into play.

When it comes to tracking file modifications on Linux, sysadmins typically have three primary options:

  • Writing custom Bash/Python scripts with sha256sum: You define a list of critical directories (/etc, /bin), compute initial SHA256 hashes, and schedule a cron job to verify them periodically.
  • Deploying a centralized Host IDS (Wazuh, OSSEC): A full-featured Agent-Manager architecture. The platform aggregates logs in real time, monitors running processes, and triggers automated Active Responses whenever an anomaly is detected.
  • Using a standalone FIM tool like AIDE (Advanced Intrusion Detection Environment): An open-source successor to Tripwire. AIDE takes a comprehensive snapshot—capturing permissions, inodes, mtime, file sizes, and SHA256/SHA512 hashes—and cross-references them during subsequent scans.

Pros and Cons of Each Approach

1. Custom Hashing Scripts

Pros: Extremely lightweight. Requires no external dependencies beyond coreutils already bundled with Linux.

Cons: Easy for skilled attackers to bypass. Homegrown scripts often miss extended attributes and SELinux contexts, fail to detect inode swapping, and perform poorly when scanning over 50,000 files.

2. Wazuh or OSSEC

Pros: Centralized management through an intuitive dashboard. Easily aggregates logs across hundreds of nodes and dispatches instant alerts to Telegram or Slack within seconds.

Cons: Resource-intensive. The management server demands at least 4GB to 8GB of RAM to handle Elasticsearch/Indexer and Manager components. For a lightweight VPS with 1 vCPU and 1GB RAM, this setup is simply not viable.

3. AIDE

Pros: Lean, reliable, and straightforward. The entire configuration resides in a single text file. AIDE performs deep audits—checking permissions, ownership, link counts, and SHA-512 hashes—while consuming virtually zero RAM when idle.

Cons: Lacks a graphical web interface. You must manually fine-tune regex exclusion rules. Careless configuration can cause daily log rotations to flood your inbox with hundreds of false positives.

Choosing the Right Solution

For enterprise server clusters spanning dozens of nodes, Wazuh is well worth the investment. Conversely, if you manage a handful of standalone VPS instances running Nginx, PHP-FPM, or PostgreSQL, AIDE provides the optimal balance of security and minimal overhead.

In day-to-day administration, the golden rule when configuring AIDE is: Strictly exclude dynamic directories. Failing to exclude paths like /var/log, /tmp, or application caches will generate reports thousands of lines long. This inevitably leads to alert fatigue, making it all too easy to overlook genuine indicators of compromise.

Step-by-Step AIDE Deployment on Ubuntu/Debian and RHEL/AlmaLinux

Step 1: Installing AIDE

On Debian or Ubuntu:

sudo apt update
sudo apt install aide aide-common -y

On RHEL, AlmaLinux, or Rocky Linux:

sudo dnf install aide -y

Step 2: Customizing Rules in the Configuration File

The default configuration file is located at /etc/aide/aide.conf (Debian/Ubuntu) or /etc/aide.conf (RHEL/AlmaLinux).

AIDE uses concise rule flags to define which attributes to inspect:

  • p: Permissions
  • i: Inode number
  • n: Number of links
  • u: User owner
  • g: Group owner
  • s: File size
  • m: Modification time (mtime)
  • c: Metadata change time (ctime)
  • sha256: SHA-256 hash algorithm

Open the configuration file in nano or vim:

sudo nano /etc/aide/aide.conf

Define a custom rule group named MYCUSTOM to strictly audit critical system binaries:

# Define attribute check group
MYCUSTOM = p+i+n+u+g+s+m+c+sha256

# Apply to critical system directories
/etc MYCUSTOM
/bin MYCUSTOM
/sbin MYCUSTOM
/usr/bin MYCUSTOM

# Explicitly exclude (!) directories with frequent data modifications
!/var/log
!/var/cache
!/tmp
!/var/tmp

Step 3: Initializing the Baseline Database

First, capture a clean baseline snapshot of your filesystem to use as the ground truth:

sudo aideinit

Note: On RHEL and AlmaLinux, use the following command instead:

sudo aide --init

On systems with an SSD and roughly 60,000 files, hashing typically finishes within 30 to 60 seconds. Once complete, AIDE outputs the baseline database to /var/lib/aide/aide.db.new (or /var/lib/aide/aide.db.new.gz).

Move this file into place as the active database to enable integrity checking:

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

Step 4: Testing Intrusion Detection

To compare the live filesystem against your baseline database:

sudo aide --check

If no modifications have occurred, the output will confirm: “AIDE found NO differences”.

Now, simulate an intrusion by tampering with /etc/hosts and placing an unauthorized script into /bin:

# Append a malicious domain to the hosts file
echo "192.168.1.200 evil-attacker.com" | sudo tee -a /etc/hosts

# Create a mock executable backdoor
sudo touch /bin/backdoor_test
sudo chmod +x /bin/backdoor_test

Run the check again:

sudo aide --check

AIDE immediately flags every discrepancy with pinpoint accuracy:

AIDE found differences between database and filesystem!!

Added entries:
/bin/backdoor_test

Changed entries:
/etc/hosts

Detailed information about changes:
File: /etc/hosts
  Size     : 221                              , 255
  Mtime    : 2026-11-06 10:15:20              , 2026-11-06 12:30:00
  SHA256   : a8f5c7...                        , e3b0c4...

Every modified parameter—from file size and mtime to cryptographic checksums—is clearly reported without missing a detail.

Step 5: Updating the Baseline Database After Maintenance

Whenever you update packages via apt upgrade or alter your Nginx configuration, AIDE will naturally report those files as modified. You must refresh the baseline database to reflect these authorized changes:

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

Step 6: Automating Periodic Audits with Cron

Running manual checks is neither practical nor sustainable. Configure a cron job to automatically run an integrity scan every day at 3:00 AM:

sudo crontab -e

Add the following entry to route reports directly to the administrator’s email address:

0 3 * * * /usr/bin/aide --check | mail -s "[Alert] VPS File Integrity Report" [email protected]

If a Mail Transfer Agent (MTA) is not configured, you can redirect the output to /var/log/aide/aide-check.log and build a lightweight Python bot to dispatch Telegram alerts whenever modifications are detected.

Share: