File Integrity Monitoring with AIDE: Reliably Detecting Unauthorized Changes

1. What File Integrity Monitoring is and why it matters for compliance

File Integrity Monitoring, FIM for short, refers to the continuous monitoring of critical files and directories for unauthorized changes. A FIM system first creates a baseline with cryptographic checksums, permissions and further attributes of all monitored paths, and on every run compares the current state against this baseline. Every deviation, whether caused by legitimate maintenance or an attack, is reported.

The relevance of File Integrity Monitoring for compliance lies in the fact that practically every major standard explicitly requires some form of it. PCI-DSS Requirement 11.5 directly demands FIM for critical system files. A CIS Benchmark recommends it as best practice for detecting tampering. ISO 27001 also implicitly demands mechanisms to detect unauthorized configuration changes as part of change management.

AIDE, short for Advanced Intrusion Detection Environment, is the most common open source solution for File Integrity Monitoring on Linux. Unlike commercial alternatives, AIDE runs entirely locally, with no cloud dependency, and allows fine grained control over which attributes are monitored per path. This flexibility makes AIDE the natural choice for servers where data sovereignty and traceability are priorities.

2. Installing AIDE and basic configuration

Installing AIDE for File Integrity Monitoring is straightforward via the package manager on all common distributions. After installation, the main configuration file resides at /etc/aide/aide.conf or /etc/aide.conf, depending on the distribution. This file defines both global settings such as the database path and the rules for which paths are monitored with which depth of checking.

An important first step before productively using File Integrity Monitoring with AIDE is deciding where the baseline database is stored. If it resides on the same, potentially compromised system, an attacker with root privileges can also manipulate the database and defeat detection. The robust solution copies the database to a separate, write protected medium or a central server after every update.

#!/usr/bin/env bash
# Install AIDE for File Integrity Monitoring on Debian/Ubuntu
set -euo pipefail

apt-get update
apt-get install -y aide aide-common

# RHEL/Rocky Linux equivalent
# dnf install -y aide

echo "AIDE version:"
aide --version

echo "Default config location:"
ls -la /etc/aide/aide.conf 2>/dev/null || ls -la /etc/aide.conf

3. Defining rules: directories and attributes to watch

The core of any File Integrity Monitoring configuration with AIDE are the rules that determine which attributes are checked per path. AIDE defines predefined rule groups such as p for permissions, i for inode, n for the number of links, u and g for owner and group, as well as sha256 for a cryptographic hash of the file content. These base rules can be combined into named rule sets, such as FULLCHECK for maximum depth or LOGCHECK for log directories where size and content are expected to change constantly.

A sensible strategy when configuring File Integrity Monitoring is to grade rules by criticality: system binaries in /usr/bin and /usr/sbin get the strictest check including hash, configuration files in /etc as well, while log directories are only checked for permission changes, not content. Without this grading, AIDE produces hundreds of irrelevant findings about growing log files on every run and buries real findings in noise.

# /etc/aide/aide.conf
# File Integrity Monitoring rule sets by criticality level

database_in  = file:/var/lib/aide/aide.db
database_out = file:/var/lib/aide/aide.db.new
gzip_dbout    = yes

# Rule set definitions
FULLCHECK = p+i+n+u+g+s+m+c+sha256
CONFCHECK = p+i+n+u+g+sha256
LOGCHECK  = p+u+g

# Critical system binaries: full integrity check including hash
/usr/bin   FULLCHECK
/usr/sbin  FULLCHECK
/bin       FULLCHECK
/sbin      FULLCHECK

# Configuration files: hash and permissions, but allow inode changes
/etc       CONFCHECK

# Application deployment path for Magento releases
/var/www/magento/app CONFCHECK
!/var/www/magento/var
!/var/www/magento/pub/media

# Log directories: permissions only, content changes constantly
/var/log   LOGCHECK

4. Creating the initial baseline and managing the database

After defining rules, aideinit or aide --init creates the initial baseline database, capturing all monitored paths in their current, assumed trustworthy state. This initialization should happen immediately after server hardening, when the system is verifiably clean, not weeks later, once unclear changes have already been made.

Every legitimate change to the system, for instance a security update or an application deployment, requires a controlled update of the File Integrity Monitoring baseline, otherwise AIDE reports the same, already known deviations again on every run. The process for this is always the same: perform the change, verify the cause, then run aide --update and adopt the new database as the current baseline.

#!/usr/bin/env bash
# Initialize AIDE baseline and establish the controlled update workflow
set -euo pipefail

# Initial baseline creation, run right after hardening on a known-clean system
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Controlled update workflow after a legitimate change (e.g. patch deployment)
update_baseline() {
  local reason="$1"
  echo "[INFO] Updating AIDE baseline, reason: $reason"
  aide --update
  mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
  echo "$(date -Iseconds) baseline updated: $reason" >> /var/log/aide-baseline-changes.log
}

update_baseline "Security patch rollout 2026-07-30, verified via change ticket #4821"

5. Automated checks via cron and systemd timers

Manually running File Integrity Monitoring checks is not a reliable strategy long term, because it depends on human memory. A daily, automated run via cron or a systemd timer ensures that deviations are detected promptly, ideally during a period of low system load, to minimize performance impact.

A systemd timer offers an advantage over classic cron through better log integration via journalctl and built in persistence, in case the system was shut down at the scheduled time. For File Integrity Monitoring on production systems this reliability is a relevant advantage over a plain cron entry that silently fails to run on a reboot during the scheduled window.

6. Evaluating alerts and validating findings

The actual value of File Integrity Monitoring only emerges from consistently evaluating reported findings, not from the run itself. Every finding should be cross referenced against a known change: is there a change ticket, a deployment log or a patch date that explains the deviation? If this explanation is missing, the finding is a serious indicator of a possible compromise and requires deeper forensic examination.

#!/usr/bin/env bash
# Run AIDE check and route findings for review before the next legitimate update
set -euo pipefail

REPORT="/var/log/aide/aide-check-$(date +%Y%m%d).log"
mkdir -p /var/log/aide

aide --check > "$REPORT" 2>&1 || true

if grep -q "found differences" "$REPORT"; then
  echo "[ALERT] AIDE detected changes, review required before baseline update"
  mail -s "AIDE File Integrity Alert - $(hostname)" security-team@example.com < "$REPORT"
else
  echo "[OK] No unexplained changes detected"
fi

A good practice for File Integrity Monitoring is to briefly document every validated finding before the baseline is updated: date, affected path, cause and who performed the review. This history becomes a valuable audit trail over time, showing that integrity checking is not only running but also actively evaluated.

7. AIDE alongside auditd and log management

File Integrity Monitoring with AIDE provides a snapshot comparison, but no information about who made a change and exactly when. auditd closes this gap by logging every system call on monitored files in real time, including user, process and timestamp. The combination of AIDE for periodic integrity checking and auditd for real time logging covers both sides: what changed, and who caused it.

In practice this means configuring the same critical paths in both systems. If AIDE reports an unexplained change to a file in /etc/pam.d/, a look into the auditd logs for the same path and time frame immediately delivers the responsible process and user, drastically shortening investigation time in an actual incident.

8. Performance and scaling on large file systems

A frequently underestimated practical problem with File Integrity Monitoring using AIDE is runtime on large file systems with many small files, for instance on a server with extensive Magento media directories. A full hash check across millions of files can take several hours and produce I/O load noticeable during business hours.

#!/usr/bin/env bash
# Schedule AIDE checks during low-traffic windows, exclude high-churn media paths
set -euo pipefail

# Exclude frequently changing, non-critical media assets from full hashing
cat >> /etc/aide/aide.conf << 'EOF'
!/var/www/magento/pub/media/catalog
!/var/www/magento/pub/media/tmp
!/var/www/magento/var/cache
!/var/www/magento/var/page_cache
EOF

# Run the check via a systemd timer at 03:00, low traffic for most shops
cat > /etc/systemd/system/aide-check.timer << 'EOF'
[Unit]
Description=Daily AIDE File Integrity Check

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl enable --now aide-check.timer

The most important principle here: exclusions must only cover paths that are verifiably non critical for security and compliance, such as generated cache files or frequently changing product images. Core application directories, configuration files and system binaries never belong on the exclusion list, regardless of the performance gain.

9. AIDE compared to other FIM tools

AIDE is not the only option for File Integrity Monitoring on Linux. The table below compares the most common alternatives by cost, complexity and use case.

For most mid sized Linux servers, AIDE is the most pragmatic choice for File Integrity Monitoring, because it is free, well documented and operable without external dependencies. Anyone needing real time detection instead of periodic checks should consider OSSEC or Wazuh, which additionally integrate log correlation and alerting.

10. Summary

File Integrity Monitoring with AIDE detects unauthorized changes to critical files by comparing a baseline database with the current system state. Successful use requires a criticality graded rule configuration, a controlled, cleanly initialized baseline and automated, recurring checks via systemd timers or cron.

The decisive factor for real security benefit is consistently evaluating every finding against known changes, combined with auditd for real time attribution of responsibility. Anyone operating File Integrity Monitoring this way not only satisfies PCI-DSS Requirement 11.5 and comparable standards, but gains a practically usable early warning system against compromise.

11. FAQ: File Integrity Monitoring with AIDE