File Integrity Monitoring mit AIDE: unautorisierte Änderungen zuverlässig erkennen

1. Was File Integrity Monitoring ist und warum es compliance-relevant ist

File Integrity Monitoring, kurz FIM, bezeichnet die kontinuierliche Überwachung kritischer Dateien und Verzeichnisse auf unautorisierte Änderungen. Ein FIM-System erstellt zunächst eine Baseline mit kryptografischen Prüfsummen, Berechtigungen und weiteren Attributen aller überwachten Pfade, und vergleicht bei jedem Lauf den aktuellen Zustand gegen diese Baseline. Jede Abweichung, ob durch legitime Wartung oder einen Angriff verursacht, wird gemeldet.

Die Relevanz von File Integrity Monitoring für Compliance liegt darin, dass praktisch jeder größere Standard eine Form davon explizit verlangt. PCI-DSS Anforderung 11.5 fordert FIM für kritische Systemdateien direkt. Ein CIS Benchmark empfiehlt es als Best Practice zur Erkennung von Manipulation. Auch ISO 27001 verlangt implizit Mechanismen zur Erkennung unautorisierter Änderungen an Konfigurationen im Rahmen des Change Managements.

AIDE, kurz für Advanced Intrusion Detection Environment, ist die verbreitetste quelloffene Lösung für File Integrity Monitoring unter Linux. Anders als kommerzielle Alternativen läuft AIDE vollständig lokal, ohne Cloud-Abhängigkeit, und erlaubt feingranulare Kontrolle darüber, welche Attribute pro Pfad überwacht werden. Diese Flexibilität macht AIDE zur naheliegenden Wahl für Server, auf denen Datenhoheit und Nachvollziehbarkeit im Vordergrund stehen.

2. AIDE installieren und Grundkonfiguration

Die Installation von AIDE für File Integrity Monitoring ist auf allen gängigen Distributionen unkompliziert über den Paketmanager möglich. Nach der Installation liegt die Hauptkonfigurationsdatei unter /etc/aide/aide.conf beziehungsweise /etc/aide.conf, abhängig von der Distribution. Diese Datei definiert sowohl globale Einstellungen wie den Datenbank-Pfad als auch die Regeln, welche Pfade mit welcher Prüftiefe überwacht werden.

Ein wichtiger erster Schritt vor der produktiven Nutzung von File Integrity Monitoring mit AIDE ist die Entscheidung, wo die Baseline-Datenbank gespeichert wird. Liegt sie auf demselben, potenziell kompromittierten System, kann ein Angreifer mit Root-Rechten die Datenbank ebenfalls manipulieren und die Erkennung aushebeln. Die robuste Lösung kopiert die Datenbank nach jeder Aktualisierung auf ein separates, schreibgeschütztes Medium oder einen zentralen Server.

#!/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. Regeln definieren: Verzeichnisse und Attribute festlegen

Der Kern jeder File Integrity Monitoring Konfiguration mit AIDE sind die Regeln, die festlegen, welche Attribute pro Pfad geprüft werden. AIDE definiert vordefinierte Regelgruppen wie p für Berechtigungen, i für Inode, n für Anzahl der Links, u und g für Owner und Gruppe, sowie sha256 für den kryptografischen Hash des Dateiinhalts. Diese Basisregeln lassen sich zu benannten Regelsets kombinieren, etwa FULLCHECK für maximale Prüftiefe oder LOGCHECK für Log-Verzeichnisse, in denen sich Größe und Inhalt erwartungsgemäß ständig ändern.

Eine sinnvolle Strategie bei der Konfiguration von File Integrity Monitoring ist die Abstufung nach Kritikalität: Systembinärdateien in /usr/bin und /usr/sbin bekommen die strengste Prüfung inklusive Hash, Konfigurationsdateien in /etc ebenfalls, während Log-Verzeichnisse nur auf Berechtigungsänderungen geprüft werden, nicht auf Inhalt. Ohne diese Abstufung produziert AIDE bei jedem Lauf hunderte irrelevante Meldungen zu wachsenden Log-Dateien und begräbt echte Findings im Rauschen.

# /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. Initiale Baseline erstellen und Datenbank verwalten

Nach der Regeldefinition erstellt aideinit oder aide --init die initiale Baseline-Datenbank, die alle überwachten Pfade im aktuellen, als vertrauenswürdig angenommenen Zustand erfasst. Diese Initialisierung sollte unmittelbar nach der Server-Härtung erfolgen, wenn das System nachweislich sauber ist, nicht Wochen später, wenn bereits unklare Änderungen vorgenommen wurden.

Jede legitime Änderung am System, etwa ein Sicherheitsupdate oder eine Anwendungsauslieferung, erfordert eine kontrollierte Aktualisierung der File Integrity Monitoring Baseline, sonst meldet AIDE bei jedem Lauf dieselben, bereits bekannten Abweichungen erneut. Der Prozess dafür ist immer derselbe: Änderung durchführen, Ursache verifizieren, dann aide --update ausführen und die neue Datenbank als aktuelle Baseline übernehmen.

#!/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. Automatisierte Checks per Cron und systemd Timer

Manuelles Ausführen von File Integrity Monitoring Checks ist auf Dauer keine verlässliche Strategie, weil es von menschlicher Erinnerung abhängt. Ein täglicher, automatisierter Lauf über Cron oder einen systemd Timer stellt sicher, dass Abweichungen zeitnah erkannt werden, idealerweise während einer Zeit mit geringer Systemlast, um die Performance-Auswirkung zu minimieren.

Ein systemd Timer bietet gegenüber klassischem Cron den Vorteil einer besseren Log-Integration über journalctl und eingebauter Persistenz, falls das System zum geplanten Zeitpunkt heruntergefahren war. Für File Integrity Monitoring auf Produktivsystemen ist diese Zuverlässigkeit ein relevanter Vorteil gegenüber einem einfachen Cron-Eintrag, der bei einem Reboot während des geplanten Zeitfensters stillschweigend ausfällt.

6. Alerts auswerten und Findings validieren

Der eigentliche Wert von File Integrity Monitoring entsteht erst durch die konsequente Auswertung der gemeldeten Findings, nicht durch den Lauf selbst. Jede Meldung sollte gegen eine bekannte Änderung abgeglichen werden: Gibt es ein Change-Ticket, ein Deployment-Log oder ein Patch-Datum, das die Abweichung erklärt? Fehlt diese Erklärung, ist die Meldung ein ernstzunehmender Hinweis auf eine mögliche Kompromittierung und erfordert eine tiefere forensische Prüfung.

#!/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

Eine gute Praxis für File Integrity Monitoring ist, jeden validierten Fund kurz zu dokumentieren, bevor die Baseline aktualisiert wird: Datum, betroffener Pfad, Ursache und wer die Prüfung durchgeführt hat. Diese Historie wird über die Zeit zu einem wertvollen Audit-Trail, der zeigt, dass Integritätsprüfung nicht nur läuft, sondern auch aktiv ausgewertet wird.

7. AIDE in Verbindung mit auditd und Log-Management

File Integrity Monitoring mit AIDE liefert einen Momentaufnahme-Vergleich, aber keine Information darüber, wer eine Änderung wann genau vorgenommen hat. Diese Lücke schließt auditd, das jeden Systemaufruf auf überwachte Dateien in Echtzeit protokolliert, inklusive Nutzer, Prozess und Zeitstempel. Die Kombination aus AIDE für periodische Integritätsprüfung und auditd für Echtzeit-Protokollierung deckt beide Seiten ab: was sich geändert hat, und wer es verursacht hat.

Praktisch bedeutet das, dieselben kritischen Pfade in beiden Systemen zu konfigurieren. Meldet AIDE eine unerklärte Änderung an einer Datei in /etc/pam.d/, liefert ein Blick in die auditd-Logs für denselben Pfad und Zeitraum sofort den verantwortlichen Prozess und Nutzer, was die Untersuchungszeit bei einem tatsächlichen Vorfall drastisch verkürzt.

8. Performance und Skalierung bei großen Dateisystemen

Ein häufig unterschätztes praktisches Problem bei File Integrity Monitoring mit AIDE ist die Laufzeit bei großen Dateisystemen mit vielen kleinen Dateien, etwa auf einem Server mit umfangreichen Magento Media-Verzeichnissen. Ein vollständiger Hash-Check über Millionen von Dateien kann mehrere Stunden dauern und I/O-Last erzeugen, die während der Geschäftszeiten spürbar wird.

#!/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

Der wichtigste Grundsatz dabei: Ausschlüsse dürfen nur Pfade betreffen, die nachweislich unkritisch für Sicherheit und Compliance sind, wie generierte Cache-Dateien oder häufig wechselnde Produktbilder. Kern-Anwendungsverzeichnisse, Konfigurationsdateien und Systembinärdateien gehören niemals in die Ausschlussliste, unabhängig vom Performance-Gewinn.

9. AIDE im Vergleich zu anderen FIM Tools

AIDE ist nicht die einzige Option für File Integrity Monitoring unter Linux. Die folgende Tabelle vergleicht die gebräuchlichsten Alternativen nach Kosten, Komplexität und Einsatzgebiet.

Für die meisten Linux-Server im Mittelstandsbereich ist AIDE die pragmatischste Wahl für File Integrity Monitoring, weil es kostenlos, gut dokumentiert und ohne externe Abhängigkeiten betreibbar ist. Wer Echtzeit-Erkennung statt periodischer Checks benötigt, sollte OSSEC oder Wazuh in Betracht ziehen, die zusätzlich Log-Korrelation und Alerting integrieren.

10. Zusammenfassung

File Integrity Monitoring mit AIDE erkennt unautorisierte Änderungen an kritischen Dateien durch den Vergleich einer Baseline-Datenbank mit dem aktuellen Systemzustand. Erfolgreicher Einsatz erfordert eine nach Kritikalität abgestufte Regelkonfiguration, eine kontrollierte, sauber initialisierte Baseline und automatisierte, regelmäßige Checks über systemd Timer oder Cron.

Der entscheidende Faktor für echten Sicherheitsgewinn ist die konsequente Auswertung jeder Meldung gegen bekannte Änderungen, kombiniert mit auditd für die Echtzeit-Zuordnung von Verantwortlichkeit. Wer File Integrity Monitoring so betreibt, erfüllt nicht nur PCI-DSS Anforderung 11.5 und vergleichbare Standards, sondern gewinnt ein praktisch nutzbares Frühwarnsystem gegen Kompromittierung.

11. FAQ: File Integrity Monitoring mit AIDE