How to Install and Configure AIDE on RHEL 7

How to Install and Configure AIDE on RHEL 7

AIDE (Advanced Intrusion Detection Environment) is a host-based intrusion detection system (HIDS) that works by taking a cryptographic snapshot of your filesystem at a known-good point in time and then comparing the current state of the filesystem against that baseline to identify any files that have been added, removed, or modified. On Red Hat Enterprise Linux 7, AIDE is available directly from the standard repositories and integrates naturally with cron for automated, scheduled integrity checks. When a breach occurs, AIDE output can be the difference between detecting a compromise in minutes and discovering it weeks later. This tutorial covers installation, configuration of monitored paths and check rules, generating the initial baseline database, running integrity checks, and automating verification with cron.

Prerequisites

• RHEL 7 system with root access.
• The EPEL or Red Hat base repositories enabled (AIDE is in the base repo on RHEL 7).
• Sufficient disk space for the AIDE database (typically a few megabytes for a standard server).
• A clean, known-good system state before generating the baseline — run AIDE initialisation immediately after a fresh build, before exposing the system to network traffic.

Step 1: Install AIDE

AIDE is available in the standard RHEL 7 repositories. Install it with yum:

sudo yum install aide

Verify the installation and check the version:

aide --version

The main configuration file is located at /etc/aide.conf, and the database files live in /var/lib/aide/ by default.

Step 2: Understand and Edit /etc/aide.conf

The AIDE configuration file controls two things: which directories and files to monitor, and what attributes to check for each monitored path. The default /etc/aide.conf shipped with RHEL 7 is comprehensive and already covers the most security-relevant paths, but understanding its structure lets you customise it for your environment.

Database File Paths

Near the top of the file you will see the database path directives:

grep "^database" /etc/aide.conf

database=file:/var/lib/aide/aide.db.gz
database_out=file:/var/lib/aide/aide.db.new.gz

database is the current baseline used during checks. database_out is where a freshly initialised database is written. After initialisation, you manually rename aide.db.new.gz to aide.db.gz to promote it to the active baseline.

Check Rules

AIDE uses named rule groups to specify which attributes to check. The default rules include common combinations:

# Some default rule definitions in /etc/aide.conf:
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
NORMAL = sha256+ftype
DIR = p+i+n+u+g+acl+selinux+xattrs
PERMS = p+u+g+acl+selinux+xattrs
LOG = p+u+g+n+S+acl+selinux+xattrs

The letters map to specific attributes:

• p — permissions
• i — inode number
• n — number of links
• u — user/owner
• g — group
• s — file size
• m — modification time (mtime)
• c — change time (ctime)
• sha256 — SHA-256 hash of file contents

Selection Lines

Selection lines specify which paths to include (/path RULE) or exclude (!/path):

# Include these directories with FIPSR checking:
/boot   FIPSR
/bin    FIPSR
/sbin   FIPSR
/lib    FIPSR
/lib64  FIPSR
/usr    FIPSR
/etc    FIPSR

# Exclude volatile/noisy paths to reduce false positives:
!/etc/mtab
!/etc/adjtime
!/var/log
!/var/spool
!/var/run
!/var/lock
!/tmp
!/proc
!/sys

To add a custom directory — for example, a web application deployed under /opt/webapp — append a line to /etc/aide.conf:

echo "/opt/webapp FIPSR" >> /etc/aide.conf

To exclude a frequently changing file that would otherwise generate noise:

echo "!/etc/aide.conf" >> /etc/aide.conf

Step 3: Initialise the Baseline Database

Before AIDE can check anything it needs a baseline — a snapshot of all the monitored files at a time when you know the system is clean. This must be done before the system is put into service, or at least immediately after a verified clean state.

sudo aide --init

This process scans every file matched by the selection rules, computes hashes and collects metadata, and writes the result to /var/lib/aide/aide.db.new.gz. On a typical RHEL 7 server this takes two to five minutes. You will see output like:

AIDE, version 0.15.1

### AIDE database at /var/lib/aide/aide.db.new.gz initialized.

Step 4: Promote the New Database to Active Baseline

AIDE writes the initialised database to the _new path to avoid accidentally overwriting a known-good baseline. After verifying the initialisation completed successfully, rename it to the active location:

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

Protect the database file — if an attacker can overwrite the baseline, the detection is defeated:

chmod 600 /var/lib/aide/aide.db.gz
chown root:root /var/lib/aide/aide.db.gz

For maximum security, copy the baseline database to offline or read-only storage (a USB drive, a remote server, or a WORM storage system) so it cannot be modified on the compromised host.

Step 5: Run an Integrity Check

Once the baseline is in place, you can run a check at any time with:

sudo aide --check

AIDE reads every file covered by the selection rules, recomputes the attributes and hashes, and compares them to the baseline. If everything is unchanged, the output will be brief:

AIDE, version 0.15.1

### All files match AIDE database. Looks okay!

If changes are detected, AIDE outputs a detailed report.

Step 6: Interpret AIDE Output

When AIDE detects differences, the report is divided into three sections:

Added Files

Added entries:
---------------------------------------------------
f++++++++++++++++: /etc/cron.d/malicious-job

A file that exists now but was not in the baseline. On a production server this is highly suspicious and should be investigated immediately.

Removed Files

Removed entries:
---------------------------------------------------
f----------------: /usr/bin/awk

A file that was in the baseline but no longer exists. A missing system binary is a serious alert — it may indicate binary replacement or covering of tracks.

Changed Files

Changed entries:
---------------------------------------------------
f   ...    .: /etc/passwd

The dots and letters after the path indicate which attributes changed. The column order matches the rule definition. Commonly you will see changes in mtime, ctime, size, and sha256. A change to /etc/passwd or /etc/shadow outside a planned maintenance window is a critical security event.

AIDE also shows a summary count at the end:

The attributes of the (uncompressed) database(s):
...

Number of entries:    31842

---------------------------------------------------
The attributes of the database(s):
...

Total number of entries:       31843
Number of changed entries:     1
Number of removed entries:     0
Number of new entries:         1

Step 7: Update the Baseline After Planned Changes

After any legitimate system change — applying patches, installing packages, editing config files — you must update the baseline, otherwise AIDE will continue to flag the changes as suspicious. The safe workflow is:

1. Apply the change (e.g., yum update).
2. Re-initialise the database: sudo aide --init
3. Review the new database briefly, then promote it: sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Alternatively, use aide --update, which checks and writes a new database in one pass:

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

Step 8: Schedule Automated Checks with Cron

Running AIDE manually is useful but automated daily checks ensure consistent coverage. Create a cron job that runs AIDE nightly and emails the report to the system administrator:

vi /etc/cron.d/aide

# Run AIDE integrity check every night at 02:30
# Output is emailed to root by cron's default mail handling
30 2 * * * root /usr/sbin/aide --check 2>&1 | /bin/mail -s "AIDE Report: $(hostname) $(date +%F)" root

If your server does not have a local mail agent, redirect output to a log file instead:

30 2 * * * root /usr/sbin/aide --check >> /var/log/aide/aide-check.log 2>&1

Create the log directory if it does not exist:

mkdir -p /var/log/aide
chmod 700 /var/log/aide

Ensure the cron daemon is running:

systemctl enable crond
systemctl start crond

Conclusion

AIDE provides an effective, low-overhead layer of host-based intrusion detection that can detect filesystem-level compromise long before other indicators become visible. The key to making it work in practice is establishing the baseline on a verified clean system, protecting the database from tampering, excluding volatile paths that would otherwise generate noise, and automating daily checks so that alerts are generated consistently. On RHEL 7, AIDE integrates cleanly with the existing PAM, cron, and SELinux infrastructure and requires no ongoing agent or licence cost. Treat any unexpected entry in an AIDE report as a genuine security event until proven otherwise — investigate, determine the cause, and update the baseline only after you are confident the change was authorised.