Inbraakdetectie & Monitoring 9 min leestijd

AIDE op Linux: Volledige Gids voor Bestandsintegriteit Monitoring met Systemd Timers in 2026

Leer hoe je AIDE (Advanced Intrusion Detection Environment) correct installeert, configureert en automatiseert op Linux servers. Een praktische gids met systemd timers, veilige baseline-opslag, productieklare configuratie en vergelijking met Tripwire en Samhain.

Editorial Team

Een ingebroken server merk je vaak pas weken later. Echt waar — ik heb het zelf meegemaakt bij een klant: aanvallers plaatsten een rootkit, vervingen /bin/login, wijzigden /etc/passwd en lieten een persistent webshell achter diep weggestopt in een systeembibliotheek. Pas bij een routine-audit kwam het aan het licht. Zonder file integrity monitoring (FIM) heeft je SOC simpelweg geen kans om dit soort wijzigingen te detecteren voordat de schade onomkeerbaar is.

AIDE — de Advanced Intrusion Detection Environment — is al sinds de jaren '90 het de facto open source antwoord op deze uitdaging. En ja, in 2026 is het nog steeds een van de meest betrouwbare tools voor host-based intrusion detection op Linux. Niet flashy, niet hip, maar het werkt gewoon.

Deze gids gaat verder dan de gemiddelde tutorial. We bouwen samen een productieklare AIDE-installatie met systemd timers, beveiligde baseline-opslag, slimme regelsets die je 's nachts niet wakker bellen met false positives, en integratie met je bestaande monitoring-stack zoals Wazuh of CrowdSec.

Wat is AIDE en waarom heb je het nodig?

AIDE bouwt een cryptografische snapshot (de zogenaamde baseline) van alle bestanden die je wilt monitoren. Bij iedere controle vergelijkt de tool de huidige staat van het bestandssysteem met die baseline. Veranderingen in permissies, eigenaar, grootte, modificatietijd, inode of hash worden netjes gerapporteerd.

De voordelen ten opzichte van puur log-based detectie:

  • Tamper detection: Zelfs als een aanvaller de logs wist (en geloof me, dat doen ze), ziet AIDE de gewijzigde binaries.
  • Compliance: PCI DSS 11.5, ISO 27001 A.12.4 en de CIS Benchmarks vereisen FIM op kritieke bestanden.
  • Lichtgewicht: Geen daemon, geen open netwerkpoorten, minimale resource-footprint.
  • Offline werking: Werkt prima op air-gapped systemen waar agent-based oplossingen het laten afweten.

Hoe AIDE zich verhoudt tot Tripwire en Samhain

In 2026 zijn er drie grote spelers in de open source FIM-ruimte. Hier is een eerlijke vergelijking — geen marketing-spin:

EigenschapAIDETripwire (OSS)Samhain
Actief onderhoudenJaNee (stilgevallen 2018)Ja
Opzet complexiteitLaagHoogHoog
Rootkit detectieNeeNeeJa
Gecentraliseerd beheerNee (DIY)Alleen commercieelJa (yule server)
SIEM integratieVia syslog/scriptBeperkt (OSS)Native
Aanwezig in distro reposOveralBeperktEPEL/AUR

Voor de meeste Linux-administrators is AIDE gewoon de juiste keuze: het zit standaard in elke distributie, wordt actief onderhouden door de community op GitHub, en is eenvoudig genoeg om correct in te zetten zonder dagenlange training. Persoonlijk heb ik Samhain ooit een seizoen lang geprobeerd en die yule-server bleek meer onderhoud te vergen dan het me opleverde.

AIDE installeren op Debian, Ubuntu en RHEL

De pakketnaam is gelukkig consistent over distributies heen. Op Debian/Ubuntu zit een wrapper-script (aideinit) ingebouwd; op de RHEL-familie werk je rechtstreeks met aide.

# Debian / Ubuntu 24.04 / 26.04
sudo apt update
sudo apt install -y aide aide-common

# RHEL / Rocky / AlmaLinux 9 / 10
sudo dnf install -y aide

# Verifieer versie (minimaal 0.18 aanbevolen in 2026)
aide --version

Versie 0.18 bracht ondersteuning voor BLAKE2 hashes en threaded checks, wat de scantijd op grote bestandssystemen aanzienlijk verkort. Werk je nog met een oudere versie? Overweeg dan zeker een backport — het verschil is op een 4 TB volume gewoon merkbaar.

De configuratie begrijpen: /etc/aide/aide.conf

De AIDE configuratie bestaat uit drie onderdelen: directieven (databasepad, hash-algoritmes), group definitions (welke attributen monitoren we), en selecties (welke paden vallen onder welke groep). Klinkt ingewikkelder dan het is.

# /etc/aide/aide.conf - kernregels

# Locatie van baseline database
database_in=file:/var/lib/aide/aide.db.gz
database_out=file:/var/lib/aide/aide.db.new.gz
database_new=file:/var/lib/aide/aide.db.new.gz
gzip_dbout=yes

# Standaard rapport naar stdout (cron pakt dit op)
report_url=stdout
report_url=file:/var/log/aide/aide.log

# Groepsdefinities: welke attributen controleren we?
# p = permissies, i = inode, n = aantal links, u = uid, g = gid
# s = grootte, b = blokken, m = mtime, c = ctime, sha256 = hash
NORMAL = p+i+n+u+g+s+b+m+c+sha256
DIR    = p+i+n+u+g
PERMS  = p+u+g+acl+selinux+xattrs
LOG    = p+u+g+n+S
DATAONLY = p+n+u+g+s+sha256

# Selecties: welke paden krijgen welke regelset?
/boot       NORMAL
/bin        NORMAL
/sbin       NORMAL
/usr/bin    NORMAL
/usr/sbin   NORMAL
/usr/lib    NORMAL
/etc        PERMS
/etc/passwd NORMAL
/etc/shadow NORMAL
/etc/ssh    NORMAL
/etc/sudoers NORMAL
/etc/sudoers.d NORMAL
/root       NORMAL

# Logs: alleen permissies, anders krijg je volle false positives
/var/log    LOG

# Uitsluitingen (begin met !)
!/var/log/journal
!/var/lib/aide
!/var/cache
!/var/spool
!/tmp
!/proc
!/sys
!/dev
!/run

Welke paden monitoren — en welke juist niet

Een veelgemaakte fout (die ik zelf ook ooit maakte) is "alles" willen monitoren. Resultaat: duizenden false positives bij iedere apt upgrade of dnf update. Niemand leest die rapporten daarna nog. Focus dus op paden waar legitieme verandering zeldzaam is:

  • Wel monitoren: /boot, /bin, /sbin, /usr/bin, /usr/sbin, /usr/lib, /etc, SSH-configuratie, sudoers, cron-directories.
  • Niet monitoren met sha256: /var/log (constant in beweging), /var/lib/mysql, /var/lib/postgresql, applicatiedata.
  • Volledig uitsluiten: /proc, /sys, /dev, /run, /tmp, container-overlays in /var/lib/docker of /var/lib/containers.

De eerste baseline aanmaken

Na het schrijven van de configuratie initialiseer je de database. Doe dit direct na een schone installatie van het besturingssysteem, voordat services online komen. Anders neem je mogelijk al gecompromitteerde bestanden op in je vertrouwde baseline — en dat is precies het tegenovergestelde van wat je wilt.

# Initialiseer baseline (kan 5-30 minuten duren afhankelijk van schijfgrootte)
sudo aide --init

# De nieuwe database staat op aide.db.new.gz, hernoem naar aide.db.gz
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# Verifieer integriteit van de baseline zelf
sha256sum /var/lib/aide/aide.db.gz | sudo tee /var/lib/aide/aide.db.gz.sha256

# Voer de eerste check uit (moet 0 verschillen tonen)
sudo aide --check

De baseline beschermen tegen manipulatie

Je AIDE-database is je vertrouwensanker. Als een aanvaller deze kan wijzigen, kan hij zijn sporen ook in toekomstige checks moeiteloos verbergen. Drie praktische opties voor 2026:

  1. Read-only mount: Plaats de database op een aparte partitie die als read-only is gemount, behalve tijdens baseline-updates.
  2. Remote opslag via SSH: Kopieer de baseline na elke geautoriseerde update naar een centrale, gehardende vault host.
  3. Immutable bit: Gebruik chattr +i om de database file immutable te maken. Aanvallers met root kunnen dit ongedaan maken, maar het stopt low-skill ransomware en automated kits in hun spoor.
# Maak database immutable
sudo chattr +i /var/lib/aide/aide.db.gz

# Synchroniseer naar remote vault (na elke geautoriseerde wijziging)
sudo rsync -avz --rsync-path="sudo rsync"     /var/lib/aide/aide.db.gz     [email protected]:/srv/aide-baselines/$(hostname)/

# Roteer baselines met datum-stempel voor forensisch onderzoek
sudo cp /var/lib/aide/aide.db.gz     /var/lib/aide/archive/aide.db.$(date +%Y%m%d).gz

Automatisering met systemd timers (de moderne aanpak)

Veel oude tutorials gebruiken nog steeds cron. Niets mis mee in principe, maar in 2026 zijn systemd timers gewoon de aanbevolen aanpak: ze zijn beter auditbaar, ondersteunen randomized delays (handig om I/O-pieken te spreiden over je fleet), en integreren netjes met journald.

De service unit

# /etc/systemd/system/aide-check.service
[Unit]
Description=AIDE File Integrity Check
After=network-online.target

[Service]
Type=oneshot
Nice=19
IOSchedulingClass=idle
ExecStart=/usr/bin/aide --check --config=/etc/aide/aide.conf
StandardOutput=append:/var/log/aide/aide-check.log
StandardError=append:/var/log/aide/aide-check.log
SuccessExitStatus=0 1 2 3 4 5 6 7

# Hardening van de service zelf
ProtectSystem=strict
ReadWritePaths=/var/log/aide
PrivateTmp=yes
NoNewPrivileges=yes

De SuccessExitStatus-regel is cruciaal — sla die niet over. AIDE geeft exit codes tussen 1 en 7 terug om verschillende soorten wijzigingen aan te duiden (1 = nieuwe bestanden, 2 = verwijderde, 4 = gewijzigde, gecombineerd via bitmask). Zonder deze regel ziet systemd elke detectie als een failure en wordt je dashboard al snel een rode zee.

De timer unit

# /etc/systemd/system/aide-check.timer
[Unit]
Description=Run AIDE integrity check daily

[Timer]
OnCalendar=*-*-* 03:15:00
RandomizedDelaySec=30min
Persistent=true
Unit=aide-check.service

[Install]
WantedBy=timers.target

# Activeer de timer
sudo systemctl daemon-reload
sudo systemctl enable --now aide-check.timer

# Controleer de status
systemctl list-timers aide-check.timer
journalctl -u aide-check.service --since today

Alerting integreren met Wazuh, journald en e-mail

AIDE detecteert wijzigingen, maar zonder alerting weet niemand het. En een rapport in /var/log/aide dat niemand leest, is geen detectie — dat is een spreadsheet. Hier zijn drie pragmatische integratiepatronen.

1. E-mail alerts bij elke wijziging

#!/bin/bash
# /usr/local/sbin/aide-mail-check.sh
set -euo pipefail

REPORT=$(mktemp)
trap "rm -f $REPORT" EXIT

if ! aide --check --config=/etc/aide/aide.conf > "$REPORT" 2>&1; then
    RC=$?
    if [ "$RC" -ne 0 ]; then
        mail -s "[AIDE] Wijzigingen gedetecteerd op $(hostname)"             [email protected] < "$REPORT"
    fi
fi

2. Logging naar journald voor SIEM-ingest

# Stuur AIDE output naar journald met structured fields
aide --check 2>&1 |     systemd-cat -t aide -p warning

# Filter in een SIEM op SYSLOG_IDENTIFIER=aide
journalctl -t aide --since "1 hour ago" -o json

3. Wazuh integratie via custom decoder

Heb je Wazuh al draaien voor SIEM? Voeg dan gewoon een file monitor toe aan ossec.conf:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/aide/aide-check.log</location>
</localfile>

Baseline updaten na geautoriseerde wijzigingen

Wanneer je een systeem patcht of een nieuwe service installeert, zal AIDE legitieme wijzigingen rapporteren. Dat is goed nieuws — het bewijst dat je tooling werkt. Bouw dit proces wel in je change management workflow:

# 1. Documenteer welke wijzigingen je verwacht (ticket-ID etc.)
# 2. Voer de wijziging uit (apt upgrade, ansible-playbook, ...)
# 3. Run een check en review het verschil
sudo aide --check | less

# 4. Indien geautoriseerd: update baseline
sudo aide --update

# 5. Vervang oude database
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# 6. Synchroniseer naar vault (zie eerder)

Voor geautomatiseerde patch-pipelines kun je dit proces wrappen in een Ansible-rol die alleen update wanneer een vooraf gedefinieerde "expected changes"-lijst overeenkomt met de werkelijke output. Klein detail, grote impact: dit voorkomt dat een gecompromitteerde build pipeline ongezien een rootkit als "expected" markeert. Een blinde aide --update in je CI is namelijk een achterdeur die je zelf openzet.

Veelvoorkomende valkuilen en oplossingen

Probleem: AIDE meldt voortdurend wijzigingen in /var/log

Logs veranderen constant — daar is niks aan te doen. Gebruik de LOG-groep (zonder size/mtime/sha256) of sluit ze volledig uit als je log-integriteit toch al via een aparte tool zoals auditd bewaakt.

Probleem: De check duurt te lang op grote bestandssystemen

Schakel over op een snellere hash zoals xxh128 voor non-kritieke paden, en gebruik selectieve DATAONLY-groepen die geen ctime/mtime checken. Op systemen met >10M bestanden: splits de scan over meerdere timers met verschillende configuraties. Niet alle bestanden hoeven elke nacht gescand te worden.

Probleem: SELinux contexten worden niet vergeleken

Voeg +selinux en +xattrs toe aan je regelgroep. Dit is essentieel voor systemen die kernel hardening en MAC-policies serieus nemen.

Probleem: Container-images veroorzaken ruis

Sluit /var/lib/docker, /var/lib/containers en overlay-mounts expliciet uit. Voor containerintegriteit gebruik je beter image-signing met Sigstore en runtime-monitoring met Falco.

Veelgestelde vragen (FAQ)

Hoe vaak moet AIDE een integrity check uitvoeren?

Voor productie-servers wordt minimaal één keer per dag aanbevolen, bij voorkeur tijdens daluren. Hoog-risico systemen (DMZ webservers, jump hosts, secrets vaults) verdienen tweemaal per dag of zelfs uurlijkse checks van een beperkte set kritieke bestanden zoals /etc/passwd, /etc/shadow en de SSH-binaries.

Wat is het verschil tussen aide --init, --check en --update?

--init bouwt een complete nieuwe baseline (gebruik na een schone installatie). --check vergelijkt de huidige status met de baseline zonder iets te wijzigen. --update doet een check én genereert tegelijk een nieuwe baseline file (aide.db.new.gz) die je handmatig kunt promoveren tot productie-baseline na review.

Kan AIDE rootkits detecteren?

Niet rechtstreeks. AIDE detecteert wel de bestandswijzigingen die rootkits achterlaten — vervangen binaries, gewijzigde libraries, nieuwe SUID-files. Voor expliciete rootkit-detectie combineer je AIDE met rkhunter, chkrootkit, of een runtime-EDR zoals Falco of Tetragon.

Is AIDE geschikt voor containerized workloads en Kubernetes nodes?

Op de host-OS van Kubernetes nodes: absoluut, AIDE is uitstekend om kubelet, containerd en kritieke systeembestanden te monitoren. Voor de containers zelf is FIM minder zinvol — gebruik daar liever immutable images, read-only rootfs en runtime-monitoring met admission controllers en Falco-regels.

Hoe lang moet ik historische AIDE-databases bewaren?

Bewaar minimaal 90 dagen aan baseline-snapshots voor forensisch onderzoek, en archiveer kwartaal-snapshots gedurende minstens 1 jaar. Dit stelt je in staat om bij een incident terug te kijken wanneer een bepaalde wijziging precies werd geïntroduceerd. Cruciaal bij APT-investigaties, waar aanvallers maandenlang in een systeem verblijven voordat ze worden ontdekt.

Conclusie

AIDE blijft in 2026 een onmisbaar fundament voor host-based intrusion detection op Linux. Het is geen vervanging voor moderne EDR-oplossingen of network monitoring — laat dat duidelijk zijn. Maar als laag in een defense-in-depth strategie levert het iets wat geen andere tool zo goedkoop en betrouwbaar doet: een cryptografisch verifieerbaar antwoord op de vraag "is dit systeem nog hetzelfde als gisteren?". Combineer AIDE met systemd timers, een beveiligde baseline-vault en integratie in je bestaande SIEM, en je hebt een FIM-stack die jarenlang dienst doet zonder noemenswaardige onderhoudslast.

Over de Auteur Editorial Team

Our team of expert writers and editors.

Gerelateerde Artikelen