Sur un serveur Linux, un rootkit est l’une des menaces les plus difficiles à repérer, car son objectif est précisément de se cacher. Il peut masquer des processus, modifier des commandes système, intercepter des connexions ou dissimuler la présence d’un attaquant. Détecter un rootkit demande donc une approche méthodique, mêlant observation, vérification d’intégrité, analyse réseau et comparaison avec des sources fiables.
Un rootkit est un ensemble d’outils conçus pour maintenir un accès furtif à une machine compromise. Sur Linux, il peut agir à différents niveaux : dans l’espace utilisateur, en remplaçant des commandes comme ps, ls ou netstat, ou plus profondément dans le noyau, via un module chargé pour modifier le comportement du système. Les rootkits les plus avancés cherchent à rendre invisibles certains fichiers, ports réseau, comptes utilisateurs ou processus.
La difficulté vient du fait qu’un serveur infecté peut continuer à fonctionner normalement. Un site web répond, les services critiques tournent, les sauvegardes s’exécutent. Pourtant, en arrière-plan, un intrus peut collecter des identifiants, préparer un rebond vers d’autres machines ou installer des portes dérobées. C’est pourquoi la détection ne doit pas se limiter à la recherche d’un fichier suspect dans un répertoire inhabituel.
Les rootkits s’inscrivent dans une famille plus large de menaces capables de s’adapter et de contourner les contrôles classiques. À ce titre, les mécanismes d’évasion observés dans un logiciel malveillant qui modifie son apparence rappellent l’importance de ne pas se fier uniquement à une signature antivirus. Sur un serveur Linux, il faut croiser les indices.
Un rootkit ne laisse pas toujours une trace évidente. Les premiers signaux sont souvent indirects : charge processeur anormale, consommation mémoire inhabituelle, lenteurs ponctuelles, connexions SSH inattendues ou redémarrages inexpliqués de services. Un administrateur attentif peut aussi remarquer des écarts dans les heures de modification de fichiers système, des tâches cron inconnues ou des comptes utilisateurs qui n’étaient pas documentés.
Les journaux d’authentification sont une source essentielle. Sur Debian et Ubuntu, le fichier /var/log/auth.log centralise notamment les connexions SSH et les usages de sudo. Sur Red Hat, CentOS ou AlmaLinux, on consultera plutôt /var/log/secure. Des connexions réussies depuis des adresses IP inconnues, des tentatives répétées suivies d’un succès, ou un usage de sudo à des horaires inhabituels doivent être examinés avec sérieux.
Il faut également surveiller les modifications de configuration. Un changement dans sshd_config, l’apparition d’une clé publique inconnue dans authorized_keys ou l’ouverture d’un port non documenté sont des indices concrets. Pris isolément, chacun peut avoir une explication légitime. Ensemble, ils peuvent former un scénario cohérent d’intrusion avec persistance.
La vérification des processus actifs est une étape classique, mais elle doit être menée avec prudence. Si un rootkit a remplacé ou modifié des commandes comme ps, top ou lsof, leur sortie peut être falsifiée. Comparer les résultats de plusieurs outils permet parfois de mettre en évidence une incohérence. Par exemple, un port ouvert visible avec ss mais absent de lsof mérite une investigation.
Les modules noyau chargés doivent aussi être contrôlés. La commande lsmod permet de les lister, tandis que /proc/modules donne une vue issue du système de fichiers proc. Un module au nom étrange, sans lien avec le matériel ou les services du serveur, doit être recherché dans la documentation de la distribution et dans les paquets installés. Certains rootkits noyau tentent toutefois de se masquer à ce niveau, ce qui limite la fiabilité d’un contrôle effectué depuis la machine potentiellement compromise.
Les intrusions automatisées exploitent souvent plusieurs machines à la chaîne, notamment lorsque des identifiants faibles ou des services exposés sont détectés. Les mécanismes de propagation décrits dans les programmes capables de se diffuser sans action humaine montrent pourquoi un serveur isolé en apparence peut en réalité faire partie d’un mouvement plus large sur un réseau.
Un rootkit sert souvent à maintenir un canal de communication avec l’extérieur. L’analyse réseau est donc indispensable. Les commandes ss -tulpn, ip a, ip route et tcpdump peuvent révéler des connexions persistantes, des ports en écoute non documentés ou des échanges réguliers vers une adresse inconnue. Sur un serveur de production, il est utile de comparer ces observations avec l’architecture attendue : quels services doivent réellement écouter, sur quelles interfaces et vers quelles destinations ?
Un serveur web qui initie soudainement des connexions sortantes vers des adresses IP situées dans des pays sans lien avec l’activité de l’entreprise n’est pas forcément compromis, mais cela justifie une vérification. Les communications DNS méritent aussi de l’attention. Des requêtes fréquentes vers des domaines générés automatiquement, ou très récents, peuvent signaler une tentative de contact avec une infrastructure de commande et contrôle.
Les journaux du pare-feu, de l’IDS ou du reverse proxy apportent un éclairage complémentaire. Sur une infrastructure bien supervisée, un rootkit laisse parfois moins de traces sur la machine locale que dans les équipements périphériques. C’est l’un des grands principes de la réponse à incident : ne pas dépendre uniquement des informations produites par le système suspect.
Des outils comme chkrootkit, rkhunter, Lynis ou certains agents EDR peuvent aider à détecter des traces de rootkits connus. Ils vérifient notamment la présence de fichiers suspects, de permissions anormales, de signatures historiques ou de configurations dangereuses. Sur un serveur Linux, ils constituent un bon point de départ, surtout lorsqu’ils sont installés avant l’incident et exécutés régulièrement.
Leur limite est importante : un résultat négatif ne prouve pas l’absence de compromission. Les rootkits récents, personnalisés ou conçus pour une cible précise peuvent échapper aux contrôles standards. À l’inverse, un faux positif est possible lorsqu’un outil de sécurité interprète mal un composant légitime ou une configuration atypique. Les alertes doivent donc être contextualisées, documentées et comparées avec l’état attendu du système.
Dans certaines attaques, l’objectif n’est pas seulement la discrétion technique, mais le vol d’identifiants ou de sessions. Les risques évoqués dans les malwares spécialisés dans l’interception de données sensibles illustrent pourquoi une compromission serveur doit toujours conduire à examiner les secrets stockés : clés SSH, tokens d’API, mots de passe applicatifs et certificats.
La comparaison d’intégrité est l’une des méthodes les plus solides pour détecter une altération. Sur les distributions Debian et Ubuntu, debsums permet de vérifier les fichiers installés par les paquets, lorsque les sommes de contrôle sont disponibles. Sur les systèmes RPM, rpm -Va signale les écarts entre les fichiers présents et ceux attendus par la base de paquets. Ces outils peuvent mettre en évidence une commande système modifiée ou un fichier de configuration altéré.
Il est aussi recommandé de maintenir une base d’intégrité avec AIDE ou Tripwire. L’intérêt est maximal lorsque la base de référence est créée sur un système sain, puis stockée hors de la machine surveillée. Si l’empreinte de /bin/ls change sans mise à jour légitime, l’alerte est beaucoup plus crédible. Cette approche demande de la discipline, mais elle reste très efficace dans les environnements où la stabilité des serveurs est importante.
Les fichiers critiques doivent être examinés avec attention : /etc/passwd, /etc/shadow, /etc/sudoers, les répertoires /etc/cron.*, les unités systemd, les clés SSH et les scripts exécutés au démarrage. L’apparition d’un utilisateur avec un UID 0, équivalent à root, est un signal grave. De même, une unité systemd au nom banal mais lançant un binaire dans /tmp ou /dev/shm doit être considérée comme suspecte.
Lorsqu’un rootkit est suspecté, la tentation est grande de supprimer les fichiers suspects et de relancer les services. C’est rarement la meilleure décision. Un serveur potentiellement compromis doit d’abord être isolé du réseau, tout en évitant de détruire des éléments utiles à l’analyse. Selon le contexte, il peut être pertinent de réaliser une image disque, de collecter la mémoire vive et d’exporter les journaux vers un emplacement fiable.
La réponse dépend de la criticité du serveur et des obligations de l’organisation. Dans un environnement professionnel, il faut prévenir les responsables sécurité, documenter la chronologie et identifier les accès exposés. Les mots de passe, clés SSH, tokens et certificats présents sur la machine doivent être considérés comme compromis tant que l’enquête n’a pas démontré le contraire.
Dans la plupart des cas, la reconstruction depuis une image saine est préférable à un nettoyage manuel. Un rootkit peut avoir modifié des composants difficiles à vérifier, et une suppression partielle laisse parfois une porte dérobée active. Les stratégies de sauvegarde et de restauration, également cruciales face à un chiffrement malveillant des fichiers, doivent être testées avant l’incident, pas improvisées pendant la crise.
Détecter un rootkit est difficile ; réduire les occasions d’installation l’est moins. La première mesure consiste à maintenir le système et les applications à jour. Les services exposés sur Internet, comme SSH, les panneaux d’administration, les bases de données ou les interfaces de supervision, doivent être strictement limités. L’authentification par clé, la désactivation de la connexion root directe et l’usage d’un pare-feu réduisent fortement la surface d’attaque.
La journalisation centralisée est un autre pilier. Si les logs sont envoyés en temps réel vers un serveur distinct, un attaquant qui modifie les traces locales aura plus de mal à effacer l’historique complet. Les solutions de supervision doivent surveiller les connexions, les nouveaux ports en écoute, les modifications de fichiers sensibles et les écarts de charge. Une alerte bien réglée vaut mieux qu’un tableau de bord jamais consulté.
Enfin, la détection repose aussi sur une bonne connaissance de l’existant. Un inventaire des services, des comptes, des tâches planifiées et des flux réseau rend les anomalies plus visibles. Sur un serveur Linux, la question n’est pas seulement de savoir si un rootkit connu est présent, mais si le système se comporte encore comme prévu. C’est cette comparaison entre l’état attendu et l’état réel qui permet, le plus souvent, de faire émerger la vérité.
