Chkrootkit et Rkhunter 2026 : Détecter les Rootkits Linux

Les rootkits Linux constituent l'une des menaces les plus redoutables auxquelles font face les équipes de sécurité : furtifs par conception, ils s'enfouissent dans le noyau ou les binaires système pour dissimuler leur présence aux outils de supervision classiques. En 2025, plus de 35 % des compromissions de serveurs Linux analysées en contexte d'incident impliquaient une forme de persistance via rootkit ou backdoor — et dans la majorité des cas, la détection n'est intervenue qu'après plusieurs semaines d'exploitation silencieuse. Face à ce risque, deux outils open source font référence depuis des années dans la communauté Linux : chkrootkit et rkhunter. Ce guide pratique vous accompagne pas à pas dans leur installation, leur configuration, l'interprétation de leurs alertes, la gestion des faux positifs et l'automatisation des scans. Vous découvrirez également comment réagir lorsqu'un rootkit est effectivement détecté, quels artefacts collecter pour une investigation forensique, et quels outils complémentaires comme AIDE, Tripwire ou Wazuh peuvent renforcer votre posture de détection. Que vous administriez un serveur de production, un VPS exposé sur Internet ou une infrastructure d'entreprise, maîtriser ces outils est indispensable.

Les rootkits Linux : comprendre la menace avant de détecter

Un rootkit est un ensemble de techniques et d'outils conçus pour maintenir un accès privilégié à un système compromis tout en dissimulant cette présence aux outils d'administration et de sécurité. Contrairement aux malwares classiques qui cherchent simplement à s'exécuter, un rootkit vise la furtivité totale : il modifie la perception qu'a le système d'exploitation de lui-même.

On distingue principalement trois familles de rootkits Linux. Les rootkits en espace utilisateur (user-level rootkits) remplacent les binaires système classiques — ls, ps, netstat, find — par des versions modifiées qui excluent sélectivement les fichiers, processus et connexions appartenant à l'attaquant. Ils sont plus simples à déployer mais aussi plus faciles à détecter en comparant les hashes des binaires avec une référence saine.

Les rootkits noyau (kernel-level rootkits, LKM — Loadable Kernel Module) sont nettement plus dangereux. En se chargeant comme module noyau, ils opèrent au niveau le plus privilégié du système et peuvent intercepter les appels système eux-mêmes. Des rootkits historiques comme Suckit, Adore-ng ou Azazel fonctionnent sur ce principe : en accrochant la table des appels système (syscall table), ils peuvent falsifier les résultats de readdir(), getdents() ou stat() pour qu'aucun outil classique ne détecte les fichiers, processus ou sockets dissimulés. La détection de ces rootkits nécessite des approches indirectes : comparaison de résultats entre /proc et les appels directs, analyse mémoire, ou utilisation d'outils comme unhide qui détectent les divergences de comptage de PIDs.

Les bootkits représentent la troisième catégorie et la plus persistante : ils s'installent dans le MBR, le secteur VBR ou le firmware UEFI, et se chargent avant même le noyau Linux. Ils résistent donc à une réinstallation du système d'exploitation si le firmware est compromis. Des variantes comme Lojax ou plus récemment CosmicStrand témoignent de la sophistication croissante de ces vecteurs, qui restent toutefois rares en dehors d'attaques étatiques ciblées.

Les objectifs des attaquants déployant un rootkit sont multiples : maintenir un accès backdoor discret sur le long terme, créer un relais pour des attaques ultérieures (pivot, C2), exfiltrer des données de manière continue, ou intégrer le serveur à un botnet. La durée moyenne entre compromission et détection dépasse souvent 100 jours dans les organisations dépourvues d'outillage de détection spécifique. Comprendre ces mécanismes est le prérequis pour utiliser efficacement chkrootkit et rkhunter.

Chkrootkit : présentation, architecture et installation

Chkrootkit est l'un des plus anciens outils de détection de rootkits Linux encore maintenus. Développé par Nelson Murilo et Klaus Steding-Jessen, il repose sur une architecture simple : un script shell principal (chkrootkit) qui orchestre l'exécution de plusieurs binaires C auxiliaires (chklastlog, chkwtmp, ifpromisc, chkdirs, chkproc, etc.). Chaque composant vérifie un aspect précis du système à la recherche de signatures connues de rootkits ou de comportements suspects.

L'approche de chkrootkit est fondamentalement basée sur les signatures et les heuristiques comportementales : il recherche des chaînes de caractères spécifiques dans les binaires système (strings associées aux rootkits connus), vérifie que les binaires critiques n'ont pas été remplacés, détecte les interfaces réseau en mode promiscuous, inspecte les fichiers de log à la recherche de tampering (lastlog, wtmp), et vérifie la présence de ports en écoute que les outils classiques ne rapportent pas.

L'installation de chkrootkit est triviale sur les distributions Debian/Ubuntu :

apt update && apt install chkrootkit

Sur les distributions Red Hat/CentOS/AlmaLinux, le paquet n'est pas toujours disponible dans les dépôts officiels. Il est alors nécessaire de compiler depuis les sources disponibles sur le site officiel du projet (chkrootkit.org — ne pas confondre avec les nombreux miroirs non officiels) :

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
tar -xzf chkrootkit.tar.gz
cd chkrootkit-*/
make sense

Notez que la cible make sense — et non make — est la cible de compilation standard pour chkrootkit. Une fois compilé, l'exécutable se trouve dans le répertoire courant. Pour vérifier la version installée :

chkrootkit -V

La version courante en 2026 est la 0.58, qui intègre les signatures des rootkits récents tout en maintenant la détection des variantes historiques. Il est recommandé de télécharger chkrootkit sur un autre système sain et de le transférer sur le serveur à auditer via un canal authentifié (scp avec vérification d'empreinte), plutôt que de l'installer directement sur un système potentiellement compromis — car si un rootkit user-level a remplacé les binaires wget, curl ou tar, l'intégrité de l'installation ne pourrait plus être garantie.

Chkrootkit : modes d'utilisation et ce qu'il vérifie

L'utilisation basique de chkrootkit se limite à l'exécution de la commande sans argument (en tant que root) :

sudo chkrootkit

Le scan complet vérifie successivement une liste de rootkits connus et de comportements suspects. La sortie est verbeuse par défaut : pour chaque test, le résultat est not infected, INFECTED, not tested ou une information spécifique. Sur un serveur moderne, l'exécution prend généralement entre 30 secondes et 2 minutes selon la taille du système de fichiers et le nombre de processus actifs.

Le mode quiet (-q) est le plus adapté à une utilisation automatisée ou à une intégration dans des scripts de surveillance :

sudo chkrootkit -q

Ce mode n'affiche que les avertissements et les détections positives, supprimant tous les messages not infected. Il réduit considérablement le volume de sortie et facilite le filtrage des alertes réelles.

Le mode expert (-x) affiche les chaînes de caractères suspectes trouvées dans les binaires analysés :

sudo chkrootkit -x

Ce mode est utile lors d'une investigation approfondie : il permet de voir quelles strings ont déclenché une alerte, ce qui aide à discriminer un vrai positif d'un faux positif. Pour analyser un chemin alternatif (par exemple un disque monté pour analyse forensique) :

sudo chkrootkit -r /mnt/suspect_system

Cette option -r est particulièrement précieuse en forensique post-incident : elle permet d'analyser un système potentiellement compromis depuis un environnement sain en montant le disque suspect et en pointant chkrootkit dessus.

Chkrootkit couvre une liste étendue de rootkits connus : Suckit, Adore, SHV (versions 4 et 5), Torvald, Bash backdoor, Enye, Sebek, et plusieurs dizaines d'autres. Au-delà des rootkits nommés, il vérifie également les binaires système susceptibles d'avoir été trojanisés : ls, ps, find, netstat, ifconfig, login, top, du et df. La vérification repose sur la présence de strings caractéristiques dans les binaires (approche heuristique) plutôt que sur une comparaison de hash cryptographique — c'est l'une de ses limites par rapport à rkhunter.

Chkrootkit : interprétation des résultats et faux positifs fréquents

L'interprétation des résultats de chkrootkit requiert de la méthode et une bonne connaissance de l'environnement audité. Le résultat INFECTED ne signifie pas nécessairement que le système est compromis : les faux positifs sont courants, en particulier sur des distributions modernes ou dans des environnements particuliers.

Le faux positif le plus fréquemment rencontré est le message :

eth0: PACKET SNIFFER(/sbin/dhclient[PID])

Ce message indique qu'une interface réseau est en mode promiscuous, ce qui est parfaitement normal lorsque le daemon DHCP (dhclient ou dhcpcd) est actif. Il peut également apparaître sur des serveurs utilisant Wireshark, tcpdump en arrière-plan, des bridges réseau (KVM/QEMU), ou des interfaces Docker/LXC. Pour confirmer qu'il ne s'agit pas d'un vrai sniffer malveillant, vérifiez le PID indiqué avec ps aux | grep PID.

Un autre faux positif classique concerne la détection du rootkit bindshell : chkrootkit signale parfois des ports standards comme suspects alors qu'ils sont simplement utilisés par des services légitimes. De même, dans les environnements Docker ou LXC, les namespaces réseau et PID peuvent déclencher des alertes liées à des processus "cachés" qui ne le sont pas réellement — ils sont simplement dans un namespace différent.

Certaines distributions Linux modifient légèrement les binaires système par rapport aux distributions upstream, ce qui peut déclencher des alertes sur des chaînes de caractères qui semblent suspectes à chkrootkit mais qui sont en réalité des patches légitimes du distributeur. Ubuntu avec ses patchs de sécurité en est un exemple récurrent.

La limitation critique de chkrootkit — et c'est fondamental à comprendre — réside dans son mode d'exécution : il s'appuie sur les binaires système du serveur audité pour effectuer ses vérifications. Si ces binaires sont eux-mêmes compromis par un rootkit user-level, chkrootkit peut être trompé et retourner des résultats faussement négatifs. Un rootkit suffisamment sophistiqué peut détecter l'exécution de chkrootkit et masquer ses traces pendant la durée du scan.

La contre-mesure consiste à utiliser chkrootkit avec ses propres binaires copiés depuis un système sain, ou à effectuer l'analyse depuis un Live CD / un système de secours bootable disposant d'un environnement non compromis. Dans le cadre d'une réponse à incident, cette précaution est non négociable.

Rkhunter : présentation, installation et configuration initiale

Rkhunter (Rootkit Hunter) est un outil de détection plus complet que chkrootkit, avec une approche hybride combinant détection de signatures, vérification d'intégrité par hashes cryptographiques, audit de configuration sécurité, et détection de comportements suspects. Développé initialement par Michael Boelen, il est maintenu par la communauté open source et continue d'être mis à jour régulièrement.

L'installation sur Debian/Ubuntu :

sudo apt update && sudo apt install rkhunter

Sur RHEL/AlmaLinux (via EPEL) :

sudo dnf install epel-release && sudo dnf install rkhunter

Une fois installé, deux commandes d'initialisation sont impératives avant le premier scan :

sudo rkhunter --update
sudo rkhunter --propupd

La première commande (--update) télécharge la base de données de signatures de rootkits la plus récente depuis les serveurs officiels du projet. La seconde commande (--propupd) est cruciale : elle calcule et enregistre les propriétés actuelles de tous les fichiers système surveillés (hashes SHA-256, permissions, appartenance, taille). Cette empreinte de référence est ensuite comparée lors de chaque scan pour détecter des modifications non autorisées. Il est indispensable d'exécuter --propupd après chaque mise à jour du système d'exploitation, sans quoi les fichiers légitimement mis à jour par les packages seront signalés comme modifiés à chaque scan.

Le fichier de configuration principal est /etc/rkhunter.conf. Les paramètres les plus importants à vérifier lors de la configuration initiale incluent :

# Spécifier le gestionnaire de paquets pour la vérification des hashes
PKGMGR=DPKG         # Sur Debian/Ubuntu
# PKGMGR=RPM       # Sur RHEL/CentOS

# Autoriser root à se connecter en SSH si nécessaire (sinon signalé)
ALLOW_SSH_ROOT_USER=no

# Désactiver les tests non pertinents pour l'environnement
DISABLE_TESTS=suspscan hidden_procs deleted_files packet_cap_apps

Lorsque PKGMGR est correctement configuré, rkhunter peut vérifier les hashes des fichiers système directement auprès de la base de données du gestionnaire de paquets, ce qui réduit considérablement les faux positifs liés aux mises à jour légitimes.

Rkhunter : utilisation, scan et interprétation des logs

Le scan interactif complet de rkhunter se lance avec :

sudo rkhunter --check

En mode interactif, rkhunter présente les résultats section par section et demande une confirmation de l'utilisateur pour continuer après chaque groupe de tests. Ce mode est adapté à une utilisation manuelle ponctuelle lors d'une investigation. La sortie est colorée (vert pour OK, rouge pour Warning ou Found) ce qui facilite la lecture.

Pour un usage automatisé, par exemple dans un cron, on utilise les options --sk (skip keypress) et --quiet :

sudo rkhunter --check --sk --quiet

L'option --report-warnings-only est également utile pour les alertes email : elle limite la sortie aux seuls avertissements, réduisant le bruit dans les notifications.

La mise à jour de la base de signatures doit être effectuée régulièrement :

sudo rkhunter --update

Tous les résultats détaillés sont consignés dans le fichier de log /var/log/rkhunter.log. Ce fichier est la source d'information principale pour l'investigation : il contient la version des définitions utilisées, les hashes calculés, les propriétés de fichiers vérifiées, et le détail de chaque alerte. La structure du log est lisible mais volumineuse — un scan complet génère généralement entre 500 et 2000 lignes selon le système.

Pour afficher uniquement les avertissements depuis le dernier scan :

sudo grep -i "warning\|found" /var/log/rkhunter.log

Rkhunter vérifie plusieurs catégories distinctes : les rootkits et backdoors connus (plus de 400 signatures), les propriétés des fichiers système (hashes, permissions, ownership), les ports en écoute suspects, la configuration SSH (autorisation root, protocole utilisé, tunneling TCP), les interfaces réseau en mode promiscuous, les fichiers cachés dans des répertoires temporaires (/tmp, /dev), les tâches cron suspectes, et plusieurs paramètres de sécurité système (présence de .rhosts, de fichiers .forward, etc.).

Rkhunter vérifie également la présence de plusieurs applications considérées comme suspectes si elles ne sont pas explicitement whitelistées : des versions de netcat avec options de backdoor (-e), des shells dans des répertoires inhabituels, des binaires setuid inattendus. Ces vérifications vont bien au-delà des seuls rootkits et font de rkhunter un outil d'audit de sécurité système à part entière.

Rkhunter : gestion des faux positifs et configuration avancée

Les faux positifs sont inévitables avec rkhunter, surtout sur des systèmes avec des configurations non standard ou des logiciels tiers. Une gestion rigoureuse de ces faux positifs est indispensable pour maintenir la valeur opérationnelle de l'outil — un système qui génère des dizaines d'alertes à chaque scan finit par être ignoré, ce qui annule complètement son utilité.

La whitelisting des scripts légitimes se fait via la directive SCRIPTWHITELIST dans /etc/rkhunter.conf :

SCRIPTWHITELIST=/usr/bin/egrep
SCRIPTWHITELIST=/usr/bin/fgrep
SCRIPTWHITELIST=/usr/bin/ldd
SCRIPTWHITELIST=/usr/sbin/prelink

Certains scripts systèmes comme ldd sont détectés comme suspects par rkhunter car ils contiennent du shell dynamique. La whitelist permet d'exclure explicitement ces faux positifs tout en maintenant la détection sur les scripts non référencés.

Après une mise à jour du système d'exploitation (via apt upgrade ou dnf update), de nombreux fichiers système voient leurs hashes changer légitimement. Sans --propupd, chaque fichier mis à jour apparaîtra comme modifié lors du prochain scan. La procédure recommandée est donc de systématiquement exécuter rkhunter --propupd après chaque mise à jour OS, idéalement en fin de script de mise à jour automatique.

Pour désactiver des tests spécifiques non pertinents pour votre environnement (par exemple, les tests de scan de paquets sur un serveur sans interface en mode monitor) :

DISABLE_TESTS=packet_cap_apps

La directive MAIL-ON-WARNING permet d'envoyer automatiquement un email lorsque des avertissements sont détectés :

MAIL-ON-WARNING=admin@votredomaine.com
MAIL_CMD=mail -s "[rkhunter] Warning on $(hostname)"

Pour les environnements Docker, il peut être nécessaire de whitelister certains chemins de fichiers utilisés par les containers, ou d'exclure des interfaces réseau virtuelles (docker0, virbr0) des vérifications de mode promiscuous :

IFACE_WHITELIST=docker0
IFACE_WHITELIST=virbr0

La directive ALLOWHIDDENDIR et ALLOWHIDDENFILE permettent de whitelister des fichiers ou répertoires cachés (commençant par un point) qui sont légitimes sur votre système :

ALLOWHIDDENDIR=/dev/.udev
ALLOWHIDDENDIR=/dev/.static

Une bonne pratique de configuration consiste à commencer avec les paramètres par défaut, effectuer un premier scan, identifier toutes les alertes, valider manuellement chacune d'elles, et progressivement whitelister les faux positifs confirmés. Cette démarche initiale peut prendre une heure sur un nouveau serveur, mais elle est investissement essentiel pour la qualité des alertes futures.

Automatisation et intégration dans une stratégie de surveillance continue

Un scan de rootkits effectué une fois lors de l'installation puis jamais répété n'a qu'une valeur limitée. L'automatisation quotidienne des scans, combinée à une notification proactive des alertes, transforme ces outils en composantes actives d'une surveillance continue.

La configuration d'un cron quotidien pour rkhunter avec envoi d'email en cas d'avertissement :

0 3 * * * root /usr/bin/rkhunter --check --sk --report-warnings-only 2>&1 | \
  mail -s "[RKHunter] $(hostname) - $(date +\%Y-\%m-\%d)" admin@votredomaine.com

Pour chkrootkit, une entrée cron similaire :

0 4 * * * root /usr/sbin/chkrootkit -q 2>&1 | \
  grep -v "^$" | mail -s "[ChkRootkit] $(hostname) - $(date +\%Y-\%m-\%d)" admin@votredomaine.com

Il est préférable de décaler les heures d'exécution des deux outils (3h et 4h par exemple) pour éviter qu'ils ne s'exécutent simultanément et ne génèrent des alertes croisées. Ces scans doivent idéalement être exécutés pendant les heures creuses pour limiter l'impact sur les performances, bien que cet impact soit généralement faible.

L'intégration avec Logwatch est native sur de nombreuses distributions : rkhunter dispose d'un service Logwatch qui consolide les alertes dans le rapport quotidien du système. Cette intégration permet de centraliser la supervision de rkhunter avec les autres logs système dans un rapport unique.

Pour les environnements disposant d'un SIEM, les logs de rkhunter peuvent être acheminés via syslog ou rsyslog vers un collecteur central. Une configuration rsyslog simple pour rediriger les logs rkhunter :

# /etc/rsyslog.d/rkhunter.conf
:programname, isequal, "rkhunter" @@siem-collector:514

L'outil Wazuh SIEM/XDR dispose de décodeurs et règles natifs pour les alertes rkhunter, permettant une corrélation avec d'autres événements de sécurité. Une alerte rkhunter combinée à une connexion SSH inhabituelle depuis une IP étrangère constitue, par exemple, un signal d'alerte composite de haute priorité que seul un SIEM peut corréler automatiquement.

La baseline de référence est un concept fondamental pour la stratégie de détection par intégrité. Elle consiste à calculer les hashes cryptographiques de tous les binaires système et fichiers de configuration critiques depuis un système sain et connu, puis à stocker ces références hors ligne (sur un support externe non accessible depuis le serveur). Lors de chaque scan, les hashes actuels sont comparés à cette référence hors ligne. Cette approche, plus robuste que la baseline stockée sur le système lui-même, est particulièrement recommandée pour les serveurs critiques. Des outils comme sha256sum sur les chemins critiques (/bin, /sbin, /usr/bin, /usr/sbin, /lib) constituent une baseline minimale efficace.

Dans le cadre d'une démarche de pentest ou d'audit de sécurité, la combinaison chkrootkit + rkhunter + vérification manuelle des modules noyau (lsmod, comparaison avec /proc/modules) constitue un triptyque de détection de base robuste, complémentaire aux scanners de vulnérabilités comme Nessus et Greenbone.

Réponse à incident : que faire quand un rootkit est détecté ?

La détection d'un rootkit par chkrootkit ou rkhunter déclenche une procédure de réponse à incident qui doit être préparée à l'avance. Improviser en situation de crise est la meilleure façon de compromettre irrémédiablement les preuves forensiques et de prolonger la durée de l'incident.

Règle numéro un : ne pas éteindre immédiatement le serveur. Un arrêt brutal détruit la mémoire volatile (RAM), qui contient des artefacts précieux : processus en cours d'exécution, connexions réseau actives, clés de chiffrement, variables d'environnement des processus malveillants. Avant toute action, évaluez le niveau de criticité de la compromission et la tolérance de votre organisation à maintenir un système potentiellement compromis en ligne pendant la durée de la collecte forensique.

La première étape est l'isolation réseau sans arrêt : bloquer les communications sortantes au niveau du pare-feu réseau (ou via iptables/nftables en local) tout en maintenant le serveur allumé. Cela empêche l'exfiltration continue de données et les communications C2 sans détruire la mémoire volatile.

La capture de la mémoire RAM est l'étape suivante critique. L'outil LiME (Linux Memory Extractor) permet de capturer la RAM d'un système Linux en cours d'exécution via un module noyau :

insmod lime-$(uname -r).ko "path=/external/memory.lime format=lime"

LiME écrit l'image mémoire sur un support externe (monté préalablement) sans modifier l'espace mémoire du processus analysé, préservant ainsi l'intégrité des preuves. L'image mémoire peut ensuite être analysée hors ligne avec Volatility.

L'outil unhide permet de détecter les processus cachés en comparant les résultats de différentes méthodes de listage de processus :

sudo unhide proc
sudo unhide sys
sudo unhide brute

L'outil unhide-tcp fait de même pour les connexions réseau, en détectant les ports en écoute que ss, netstat ou /proc/net/tcp ne rapportent pas.

Les artefacts à collecter lors d'une investigation rootkit incluent : l'image mémoire complète, les logs système (/var/log/auth.log, /var/log/syslog, /var/log/kern.log), la liste des modules noyau chargés (lsmod), les connexions réseau actives (ss -antp), les tâches cron (/etc/cron*, crontab -l pour chaque utilisateur), les fichiers récemment modifiés (find / -newer /etc/passwd -type f), les binaires setuid inattendus (find / -perm -4000), et les entrées de ~/.ssh/authorized_keys pour tous les comptes.

Recommandation finale et non négociable : après confirmation d'une compromission par rootkit, le système ne peut plus être considéré comme de confiance, quelles que soient les actions de nettoyage effectuées. La réinstallation complète depuis une image saine, suivie de l'application de toutes les mises à jour de sécurité et de l'audit des comptes et clés SSH, est la seule réponse garantissant l'intégrité du système. Tenter de "nettoyer" un système après compromission par rootkit kernel-level est une approche risquée qui laisse souvent des persistances non détectées.

Alternatives et outils complémentaires : AIDE, Tripwire et Wazuh

Chkrootkit et rkhunter sont des outils de détection réactive : ils identifient des compromissions déjà présentes. Pour une posture de sécurité robuste, ils doivent être complétés par des outils de surveillance d'intégrité continue (File Integrity Monitoring — FIM) qui détectent proactivement toute modification non autorisée des fichiers système.

AIDE (Advanced Intrusion Detection Environment) est le successeur spirituel de Tripwire open source. Il construit une base de données de référence contenant les métadonnées et hashes cryptographiques (MD5, SHA-1, SHA-256, SHA-512 selon la configuration) de tous les fichiers surveillés. Lors de chaque vérification, AIDE compare l'état actuel du système à cette base de référence et signale toute différence. L'installation et l'initialisation :

sudo apt install aide
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check

AIDE est particulièrement adapté aux environnements où la liste des fichiers système légitimes est stable (serveurs de production avec peu de mises à jour fréquentes). Sa principale contrainte est la nécessité de mettre à jour la base de référence après chaque modification légitime du système, sous peine de générer des alertes constantes.

Tripwire (commercial et open source) adopte une approche similaire avec des fonctionnalités supplémentaires : reporting plus riche, intégration dans des workflows de gestion de changements, et signature cryptographique de la base de référence pour prévenir sa falsification. La version open source reste viable mais la version commerciale offre une meilleure expérience pour les grandes organisations.

Wazuh représente l'approche la plus moderne et la plus complète. En tant qu'agent de sécurité, il intègre nativement un module FIM (syscheck) qui surveille les modifications de fichiers en temps réel, un module de détection de rootkits (rootcheck), et un agent de collecte de logs qui alimente un SIEM central. Les alertes Wazuh sont corrélables avec d'autres événements (authentifications, modifications réseau, alertes IDS) pour construire une image de menace complète.

La comparaison pratique entre ces outils : chkrootkit et rkhunter sont légers, sans daemon en permanence, et idéaux pour des scans périodiques sur des serveurs avec peu de ressources. AIDE est plus rigoureux sur l'intégrité des fichiers mais nécessite une gestion rigoureuse de la base de référence. Wazuh offre la supervision en temps réel et la corrélation multi-sources, mais requiert une infrastructure centrale (indexeur Wazuh, serveur Wazuh) et des ressources plus importantes.

Pour la majorité des serveurs Linux exposés, la stratégie recommandée est de combiner : rkhunter en scan quotidien, AIDE ou Wazuh FIM pour la surveillance d'intégrité en continu, et une solution de centralisation des logs (rsyslog vers un SIEM) pour la corrélation et la rétention d'audit. Cette combinaison couvre les trois vecteurs de détection : signatures connues, modifications comportementales, et analyse des événements systèmes.

Questions fréquentes sur chkrootkit et rkhunter