Le contrôle d’intégrité répond à une question à laquelle ni un antivirus ni un pare-feu ne répondent : qu’est-ce qui a changé sur ce serveur depuis la semaine dernière ? Un analyseur par signatures cherche du malveillant connu ; AIDE ne sait rien de la malveillance, il sait que ce fichier était différent hier. Pour détecter une porte dérobée ajoutée à un fichier existant, c’est la seule approche qui fonctionne.

AIDE s’installe en deux commandes. Le configurer pour que ses rapports soient lus est la partie difficile — et c’est d’ordinaire ce qui le tue : le premier rapport arrive avec dix mille lignes, personne n’ouvre le second, et un mois plus tard la tâche est supprimée.

Installation et première base

sudo apt install aide aide-common
sudo aideinit

L’initialisation prend de quelques minutes à une demi-heure : les empreintes de tous les fichiers sont calculées. Le résultat est déposé à côté de la base de travail avec le suffixe .new et doit être mis en service :

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

Ensuite, une vérification se lance ainsi :

sudo aide --check

Ce qu’il faut exclure pour que le rapport reste lisible

Les réglages se trouvent dans /etc/aide/aide.conf et dans le répertoire /etc/aide/aide.conf.d/. La configuration Debian livrée vérifie trop de choses, et la première chose à faire est d’enlever ce qui change tout seul en permanence :

  • /var/log — change à chaque seconde ;
  • /var/lib en entier — bases de données, état des paquets, état des services ;
  • /var/cache, /tmp, /proc, /sys, /run ;
  • les répertoires de téléversement et de cache du site — leur contenu est modifié par les visiteurs.

Ce qu’il vaut la peine de vérifier avec les réglages les plus stricts est une liste étroite :

  • /bin, /sbin, /usr/bin, /usr/sbin — les exécutables du système ;
  • /lib, /usr/lib — les bibliothèques ;
  • /etc — la configuration ;
  • /root/.ssh et les répertoires .ssh de vos utilisateurs ;
  • le code du site, mais sans les répertoires de téléversement et de cache.

Le repère : un rapport quotidien ordinaire doit tenir sur un écran. S’il est plus long, les exclusions sont insuffisantes, et on cessera de le lire.

Où garder la base

Un point essentiel souvent oublié. Si quelqu’un dispose de root, remplacer un fichier et mettre aussitôt à jour la base AIDE ne lui coûte rien — et la vérification annoncera ensuite que tout va bien. Une base posée sur la même machine et accessible en écriture ne protège que des accidents.

Un minimum raisonnable pour un serveur unique :

  • copier la base sur une autre machine après chaque mise à jour, et lancer la vérification en remettant cette copie en place ;
  • ou au moins conserver séparément la somme de contrôle de la base et la comparer avant la vérification :
sha256sum /var/lib/aide/aide.db

Même une mesure aussi simple transforme un remplacement silencieux en événement remarquable.

Mettre la base à jour est un acte délibéré

Après des modifications légitimes — une mise à jour du système, une nouvelle version du site — la base se reconstruit :

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

Le moment compte. Correct : lire le rapport, s’assurer que chaque modification s’explique, et seulement ensuite mettre à jour. Incorrect et très répandu : lancer aide --update selon un calendrier pour que les rapports soient propres. Dans le second cas, le système tourne, les rapports arrivent, et les modifications sont enregistrées comme normales à l’instant même où elles se produisent — le sens est donc entièrement perdu.

Calendrier et charge

Le paquet aide-common installe lui-même une tâche quotidienne. La vérification charge le disque et le processeur pendant quelques minutes, elle doit donc s’exécuter à une heure calme et avec une priorité abaissée :

0 4 * * * ionice -c3 nice -n19 /usr/bin/aide --check

Comment lire le rapport

Trois sections : fichiers ajoutés, supprimés et modifiés. Pour chaque modification, il indique ce qui diffère exactement : contenu, droits, propriétaire, date.

Ce à quoi réagir en premier :

  • une modification de n’importe quel fichier dans /bin, /sbin, /usr/bin hors d’une fenêtre de mise à jour ;
  • de nouveaux fichiers dans les répertoires système ;
  • des modifications de authorized_keys, /etc/passwd, /etc/sudoers, /etc/crontab et /etc/cron.d ;
  • l’apparition d’un fichier /etc/ld.so.preload — il n’apparaît jamais tout seul.

Cent fichiers modifiés juste après apt upgrade, c’est normal, et l’horodatage du rapport le confirme. Trois fichiers modifiés dans /usr/bin un mercredi sans mise à jour, c’est une raison de s’arrêter et de regarder.

AIDE et debsums

Les outils traitent des problèmes voisins, mais leur référence diffère. AIDE compare à votre propre instantané — il voit donc les modifications de n’importe quels fichiers, le code du site compris. debsums compare aux sommes de contrôle des paquets de la distribution — il voit donc les fichiers système remplacés sans aucune préparation, mais ne sait rien de ce que vous avez installé hors des paquets. Garder les deux est raisonnable ; en pratique, debsums vient d’ordinaire en premier, parce qu’il n’exige ni configuration ni base.

Ils partagent aussi une faiblesse : le rapport arrive par courrier, et le courrier se perd. Ce qui compte n’est donc pas que la vérification ait tourné, mais qu’il existe un endroit où son dernier résultat est visible. À quoi cela ressemble, la page de démonstration ci-dessous le montre.