AIDE : intégrité des fichiers Linux contre rootkits et compromissions

Quand un attaquant pose un rootkit dans /usr/bin/ ou modifie un binaire setuid pour ouvrir une backdoor, la compromission est invisible aux outils d'observation classiques. ps, ls, find peuvent eux-mêmes être trojanisés. La seule façon de détecter cette altération : comparer l'état actuel des fichiers à un état de référence pris quand le système était sain.

AIDE (Advanced Intrusion Detection Environment) fait exactement ça. Open source GPL, dispo sur toutes les distros Linux, il calcule des hashs cryptographiques de chaque fichier critique au moment de la baseline, puis détecte toute modification ultérieure. Tripwire-like, mais open source et toujours maintenu.

Pour les serveurs en production, c'est une couche détection complémentaire à auditd et Falco runtime. Aucun de ces trois ne se substitue aux autres.

• Pourquoi AIDE en complément
• Architecture et modèle de données
• Configuration et baseline initiale
• Vérifications quotidiennes et alerting
• Couverture : que mettre dans la baseline
• Mise à jour contrôlée après changement légitime
• Intégration SIEM et reporting
• Limites et pièges

Trois angles morts qu'AIDE couvre.

Modifications hors syscall watch. Un attaquant qui a un rootkit kernel peut modifier des fichiers sans déclencher les hooks auditd userland. AIDE compare des hashs au repos, pas à l'instant T : un binaire modifié sera détecté à la prochaine vérif, même si l'attaque a contourné auditd.

Modifications très anciennes. auditd capture des événements en flux. Si l'attaque date d'il y a 6 mois et qu'on n'avait pas activé la règle audit au bon moment, on ne sait pas. AIDE compare à la baseline initiale, peu importe quand la modification a eu lieu.

Couverture systémique. AIDE peut hasher 50000 fichiers en quelques minutes. Couvre /bin, /sbin, /usr, /lib, /etc exhaustivement. Une règle auditd équivalente serait coûteuse.

Pour les binaires kernel, modules, shared libs, et configurations stables, AIDE est l'outil. Pour les bases de données et fichiers volatiles, AIDE n'est pas adapté (faux positifs constants).

AIDE est simple :

• Une configuration décrit ce qu'on hash et avec quels attributs (taille, mode, owner, hash crypto, mtime, etc.).
• Un scan initial produit une base de données (typiquement /var/lib/aide/aide.db) avec les hashs de référence.
• Un scan périodique compare l'état actuel à la base de référence.
• Un rapport liste les ajouts, suppressions, modifications.

La base est un fichier binaire compressé. Pour 100k fichiers, taille typique 50-200 Mo.

Cinq types d'événements détectés :

• Added : nouveau fichier non présent dans la baseline.
• Removed : fichier de la baseline maintenant absent.
• Changed : fichier modifié (hash, taille, owner, etc.).
• Renamed : déplacement (rare).
• Symlink target changed : lien symbolique repointé.

Installation Debian/Ubuntu :

sudo apt install aide

Configuration /etc/aide/aide.conf (Debian) ou /etc/aide.conf (RHEL).

Le fichier définit des "groupes" de checks et applique ces groupes à des chemins :

# Définition des groupes de checks
NORMAL = p+i+n+u+g+s+m+c+md5+sha512
LSPP = p+i+n+u+g+s+b+m+c+md5+sha256
HIGH = p+i+n+u+g+s+b+m+c+md5+sha256+sha512+rmd160

# Application aux chemins
/boot       HIGH
/bin        NORMAL
/sbin       NORMAL
/lib        NORMAL
/usr/bin    NORMAL
/usr/sbin   NORMAL
/usr/lib    NORMAL
/etc        NORMAL

# Exclusions
!/var/log
!/var/lib
!/var/cache
!/proc
!/sys
!/run
!/tmp

Les attributs vérifiés :

Génération de la baseline initiale :

sudo aideinit
# ou: sudo aide --init
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

À ce stade, la baseline est créée. Idéalement, ce fichier de baseline est copié hors du serveur (sur un partage read-only, sur un service de stockage immutable, ou imprimé pour les paranoïaques).

Vérification :

sudo aide --check

Sortie :

AIDE 0.18.6 found differences between database and filesystem
Start timestamp: 2026-06-14 03:00:00 +0200

Summary:
  Total number of files:    158234
  Added files:              0
  Removed files:            0
  Changed files:            1

---------------------------------------------------
Changed entries:
---------------------------------------------------
f   ...    .C.. : /usr/bin/sudo

Le f indique fichier, et les .C.. indiquent les attributs modifiés.

Pour automatiser, cron quotidien :

# /etc/cron.daily/aide-check
0 3 * * * root /usr/sbin/aide --check | mail -s "AIDE report $(hostname)" sec@exemple.fr

Ou via un timer systemd pour plus de robustesse :

# /etc/systemd/system/aide-check.timer
[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

L'alerting peut router vers Slack/PagerDuty selon la criticité, surtout pour des changes en /usr/bin/ ou /lib/ qui devraient être stables.

Critère : tout fichier dont la modification non planifiée est suspecte.

À couvrir :

• /boot : kernel, initramfs, bootloader.
• /bin, /sbin, /usr/bin, /usr/sbin : tous les binaires système.
• /lib, /usr/lib : bibliothèques partagées.
• /etc : configurations.
• /usr/local/bin et /opt : binaires custom.
• Modules kernel : /lib/modules/.
• Crontabs : /var/spool/cron/, /etc/cron.*/.
• Configurations SSH, sudoers, PAM.

À exclure :

• /var/log : logs constamment réécrits.
• /var/lib (sauf cas spécifique) : data applicative volatile.
• /proc, /sys, /run, /tmp : pseudo-filesystems et volatils.
• Caches : /var/cache/.
• Mail spool : /var/spool/mail/.
• Bases de données : à exclure systématiquement.

Configuration de référence pour une baseline propre : 100k-300k fichiers selon la distro. Scan complet en 5-15 minutes sur SSD.

Après un apt upgrade qui modifie 200 paquets, AIDE va lever 200 faux positifs. Procédure standard :

1. Vérifier le rapport AIDE post-upgrade (s'assurer que les modifs correspondent aux paquets installés).
2. Corréler avec les logs apt history.log ou équivalent.
3. Reconstruire la baseline :

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

Pour automatiser dans un pipeline propre, intégrer la régénération de baseline dans le workflow de patching. Un playbook Ansible qui patche puis rebase AIDE est le pattern standard.

Pour un système immuable comme Bootc, AIDE est moins utile : l'image entière est figée. Si elle change, c'est par déploiement d'une nouvelle image, pas par modif locale.

Pour la conformité, le rapport AIDE quotidien doit aller dans un SIEM, pas seulement dans un mail.

rsyslog : sortie AIDE pipée vers logger, log central. Voir rsyslog-centralisation.

Wazuh : agent Wazuh ingère les rapports AIDE nativement et corrèle avec d'autres sources. Voir wazuh-siem.

Loki : push vers une stack moderne via Vector ou Promtail. Voir stack-logging-loki.

Grafana : dashboard nombre de modifs par hôte par jour. Une augmentation soudaine = signal à investiguer.

Pour la conformité PCI / ISO / HDS, l'auditeur veut voir :

1. Que AIDE est configuré sur les serveurs critiques.
2. Que la baseline est régulièrement régénérée.
3. Que les rapports sont consommés et que les modifications inattendues sont investiguées.
4. Que la base AIDE elle-même est protégée contre modification (idéalement stockée hors du host).

Pas du temps réel. AIDE compare à la baseline une fois par jour. Si l'attaquant modifie un binaire à 4h du matin et le restaure à 4h05, AIDE ne le voit pas (entre deux scans). Falco runtime capture les modifications en streaming syscall.

Performance scan. Sur des FS très grands (>1 To), le scan peut être long et IO-intensif. Lancer hors heures critiques.

Base AIDE compromise. Si l'attaquant accède au fichier aide.db et le réécrit, il peut masquer les modifications. Stocker la base sur read-only, sur partage NFS protégé, ou sur un stockage offline.

Faux positifs sur fichiers volatiles. Mal configurer la couverture génère du bruit. La baseline initiale doit exclure tout ce qui est volatile.

Patches OS. Régénérer la baseline est nécessaire après chaque patch. Faute d'automatiser, on accumule du retard et les vrais positifs se noient dans 1000 faux.

Pas un outil temps réel pour SOC. AIDE est une vérification périodique. Pour du SOC en flux, auditd ou Falco sont plus adaptés. Les trois cohabitent.

Compatibilité distro. AIDE est sur toutes les distros, mais le chemin de config diffère (Debian: /etc/aide/, RHEL: /etc/aide.conf). Documenter par distro.

Conformité. AIDE seul ne suffit pas pour PCI/ISO. Il faut le coupler à logging centralisé, alerting, runbook d'investigation. La détection d'une modification est inutile sans procédure d'enquête associée.

AIDE est une couche de filet de sécurité. La détection seule n'est rien : la valeur vient du couplage avec un SIEM, un runbook d'investigation, et une fréquence de rebase automatisée. Détecter une modification sans procédure d'enquête associée ne sert à rien. Garder cette baseline alignée après chaque patch et démêler les vraies altérations des faux positifs demande une présence continue ; faute de bras en interne, cette veille se sous-traite.

• AIDE documentation officielle : configuration, options, exemples.
• GitHub aide/aide : code source, releases.
• Red Hat - File integrity checking with AIDE : guide pratique RHEL.
• Debian wiki - AIDE : guide pratique Debian.
• PCI-DSS v4.0 Requirement 11.5 : exigences détection intégrité fichier.
• Tripwire alternatives - LinuxFR : comparatifs des outils HIDS classiques.