Le contrôle d’intégrité a une propriété gênante : il lui faut une référence prise sur un système assurément propre. Si le serveur tourne depuis trois ans et que la question d’une intrusion ne se pose qu’aujourd’hui, il est déjà trop tard pour cette référence — vous enregistreriez comme normal ce qui s’y trouve.

Sous Debian et Ubuntu, la référence existe pourtant déjà, et elle n’est pas la vôtre : chaque paquet installé porte les sommes de contrôle de ses propres fichiers. La comparaison n’exige ni configuration ni instantané préalable et fonctionne sur n’importe quel système à n’importe quel moment. L’outil s’appelle debsums.

Utilisation

sudo apt install debsums
sudo debsums -c

L’option -c n’affiche que les fichiers qui ne correspondent pas à la référence. Sans elle, la sortie est un rapport ligne à ligne sur chaque fichier du système, des dizaines de milliers de lignes.

La vérification prend quelques minutes et charge le disque, elle doit donc s’exécuter avec une priorité abaissée sur un serveur en production :

sudo ionice -c3 nice -n19 debsums -c

Lire le résultat

Une sortie vide signifie que tous les fichiers vérifiés correspondent à ce qu’a installé la distribution. Une sortie non vide demande examen, et les trouvailles se répartissent en deux classes très différentes.

Les fichiers de configuration sous /etc. Les modifier relève du travail normal : vous avez édité sshd_config, configuré nginx, ajouté des paramètres au noyau. De tels écarts sont attendus. Pour qu’ils ne gênent pas, il existe un mode dédié :

sudo debsums -e -c

-e ne vérifie que les fichiers de configuration — parfois utile pour voir la liste de tout ce que vous avez modifié sur cette machine.

Les exécutables et les bibliothèques. Un écart dans /usr/bin, /usr/sbin, /bin ou /usr/lib est précisément ce pour quoi la vérification a été lancée. Des causes légitimes existent, mais peu nombreuses : le fichier a été modifié à la main lors d’un débogage, un correctif tiers a été appliqué, le paquet était en cours de mise à jour pendant la vérification. Si rien de cela ne convient, il faut enquêter sérieusement.

Les cibles classiques d’un remplacement sont ls, ps, netstat, ss, find, sshd. Une version remplacée masque les lignes voulues dans sa sortie, et toutes vos vérifications suivantes cessent de dire la vérité.

La couverture est incomplète — et il faut le savoir

Une limite dont on ne parle généralement pas : tous les paquets ne fournissent pas de sommes de contrôle. Les fichiers de ces paquets ne sont pas vérifiés du tout et n’apparaîtront dans le rapport en aucune circonstance. La liste se consulte ainsi :

sudo debsums -l

Un rapport debsums propre signifie donc « tout va bien dans la partie vérifiée » et non « le système n’a pas été modifié ». Il en va de même pour tout ce qui a été installé hors du gestionnaire de paquets : compilé depuis les sources, téléchargé en binaire, posé par un script du site de l’éditeur — debsums n’en surveille rien par définition, et c’est exactement là qu’AIDE est nécessaire.

Exécution régulière

Le paquet fournit une tâche toute prête, activée dans /etc/default/debsums :

CRON_CHECK=weekly

Une fois par semaine est une fréquence raisonnable : la vérification charge sensiblement le disque, et les fichiers système changent rarement entre deux mises à jour. Une exécution quotidienne n’apporte rien d’autre que de la charge.

Si un fichier a réellement été remplacé

Le premier réflexe est de réinstaller le paquet pour récupérer l’original :

sudo apt install --reinstall coreutils

La commande est juste, mais pas en première action. Un binaire système remplacé signifie que quelqu’un a eu root, et restaurer le fichier ne résout pas ce problème — cela ne fait que détruire les traces. L’ordre doit être inverse : d’abord conserver une copie du fichier suspect et son heure de modification, regarder ce qui a changé d’autre à la même période, vérifier les tâches cron, les clés SSH et la liste des utilisateurs. Restaurer seulement ensuite.

Rappelez-vous aussi les limites de la méthode : si le système est profondément compromis, debsums lui-même et les bibliothèques qu’il utilise peuvent avoir été remplacés aussi. Une vérification depuis l’intérieur ne peut donner de garantie absolue — cela se fait en démarrant depuis un support externe. Pour le travail quotidien, cela suffit néanmoins : l’écrasante majorité des attaques est automatisée et n’a pas cette sophistication.

Sa place dans l’ensemble

debsums est appréciable parce qu’il n’exige rien et fonctionne immédiatement — ce qui en fait un point de départ commode pour un serveur dont vous ne connaissez pas l’histoire. Sa faiblesse est la couverture incomplète et l’absence de connaissance de tout ce qui est installé hors des paquets. Le couple « debsums plus AIDE » ferme les deux côtés : la référence toute prête de la distribution pour les fichiers système et votre propre instantané pour le reste.

Comme toujours, l’enjeu n’est pas de l’exécuter mais d’avoir sous les yeux le dernier résultat avec sa date. À quoi cela ressemble, la démonstration ci-dessous le montre.