/PLAYBOOK · 2026-08-12

Linux File Integrity Monitoring: AIDE Tamper Detection Config Guide

WebShell planted. System files changed. Catch it fast. Hash baseline comparison, then a full AIDE setup: init baseline, scheduled scans, alerts, and baseline updates.

Scope

Linux file integrity monitoring fits these cases: WebShell planted or pages tampered with no fast locate; post-intrusion, confirm which system files the attacker changed; compliance requires periodic checks on critical dirs (MLPS 2.0 audit and intrusion prevention). This article starts from hash baseline comparison. Full AIDE setup: init baseline, scheduled scans, alerts.

Prerequisites

One Linux server (CentOS 7+ / Ubuntu 22.04 in this guide)
Root. Can install packages.
A dedicated directory for the AIDE database. Prefer a read-only mount or backup disk so it is not tampered with the system files.

How it works

AIDE (Advanced Intrusion Detection Environment) is baseline comparison. First run hashes files in configured dirs (SHA256), plus perms, owner, size, mtime, and writes a database. Later scans recompute and diff against the baseline. Adds, deletes, and mods are flagged. WebShell drops, binary swaps, /etc/passwd edits change hashes or attributes and get caught. The database itself is a tamper target. Store it on separate backup or write-protected media. Recalibrate the baseline on a schedule.

Steps

1. Install AIDE

`# CentOS
sudo yum install -y aide

# Ubuntu
sudo apt update && sudo apt install -y aide

# Check version
sudo aide --version`

2. Configure monitoring scope

`# Edit /etc/aide.conf (CentOS) or /etc/aide/aide.conf (Ubuntu)
# Define monitoring attributes in the rules section
DATABASE_OUT=file:/var/lib/aide/aide.db.gz
DATABASE_IN=file:/var/lib/aide/aide.db.gz

# Custom rule: SHA256 hash + permissions + owner + size + links
MYCHECK = p+i+n+u+g+s+m+c+SHA256

# Monitor critical system paths
/etc MYCHECK
/bin MYCHECK
/sbin MYCHECK
/usr/bin MYCHECK
/usr/sbin MYCHECK
/var/www MYCHECK     # Web site directory; detect WebShell tampering
/boot MYCHECK

# Exclude volatile files
!/var/www/html/cache
!/var/log/.*`

Key params: `SHA256` in `MYCHECK` hashes content. `p+i+n+u+g+s+m+c` are perms, inode, nlink, owner, group, size, mtime, ctime. Prefix `!` excludes high-churn dirs.

3. Initialize the baseline database

`# Initialize (must run while the system is in a "clean" state)
sudo aide --init

# Rename the generated database to the standard name
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# Verify the database was generated
ls -lh /var/lib/aide/aide.db.gz`

4. Scheduled scan and report

`# Manual scan and compare
sudo aide --check

# Output added/modified/deleted file list; save the report to a file
sudo aide --check > /tmp/aide_report_$(date +%F).txt 2>&1

# When the scan finds no issues, output looks like:
# AIDE found NO differences between database and filesystem. Looks okay!!`

5. Cron and alerts

`# Daily 02:30 scan; send email if anomalies are found (install mailx first)
30 2 * * * /usr/sbin/aide --check 2>&1 | grep -q "differences" && echo "AIDE: files changed!" | mail -s "AIDE Alert" admin@example.com

# Or append to a log file for collection by the monitoring system
30 2 * * * /usr/sbin/aide --check >> /var/log/aide_check.log 2>&1`

6. Update baseline after confirmed changes

`# After software upgrades or legitimate file changes, regenerate the baseline to avoid false positives
sudo aide --update
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz`

Verify

`# 1. Simulated tamper test: modify a monitored file, then scan
echo "# test" >> /etc/motd
sudo aide --check | grep -i "changed" | head -3
# Should output something like: /etc/motd ............ Changed

# 2. Restore the file and scan again; should show no differences
sudo mv /etc/motd.bak /etc/motd
sudo aide --check | tail -1`

FAQ

Q1: Why mass false positives after a package update?

yum/apt upgrades rewrite binaries and configs. Hashes change. Expected. Record changes before the upgrade. After, run `aide --check` and confirm diffs match the upgraded packages. Then `aide --update` to rebuild the baseline.

Q2: What if the AIDE database itself is tampered?

The db is a prime target. Store `aide.db.gz` on a separate backup disk or object storage. Mount read-only (`mount -o ro`). GPG-sign the db and verify before scan. Cross-store checksums on another host. If the db is replaced, start incident response and re-init the baseline.

Takeaway

AIDE gives Linux a light, fast file integrity check via hash baselines. Alerts on WebShell drops and binary swaps. Init on a clean system. Exclude noisy paths. Store the db off-box. Update the baseline after real changes. Pair with log audit and IDS scripts for defense in depth.