La prise d'empreinte des services : bannières et versions

Savoir qu'un port est ouvert ne dit pas ce qui s'y cache. Un serveur web, une base de données, un équipement ancien ? Quelle version, quelles options ? Cette leçon vous apprend à lire les « bannières » des services, c'est-à-dire ce qu'ils annoncent d'eux-mêmes, et à en déduire une première liste de pistes d'analyse.

Vous avez cartographié les noms (DNS) et les ports ouverts (scan). La dernière brique de la reconnaissance est la prise d'empreinte (fingerprinting) : identifier avec précision les services et leur version. Cette information est cruciale pour la phase suivante, car les vulnérabilités connues sont presque toujours associées à des versions précises de logiciels.

Qu'est-ce qu'une bannière ?

Beaucoup de services, quand on se connecte à eux, se présentent : ils renvoient une ligne de texte indiquant leur nom, parfois leur version et leur système. Cette « bannière » est conçue pour la compatibilité et le diagnostic, mais elle offre à un observateur des informations précieuses. C'est un peu comme un commerçant qui accroche à sa porte le modèle et l'année de sa serrure.

La technique qui consiste à lire ces bannières s'appelle le banner grabbing. Elle peut se faire de plusieurs manières :

• avec Nmap, grâce à l'option de détection de version (-sV) ;
• avec un utilitaire de connexion simple, comme nc (netcat) ou telnet, pour ouvrir une connexion et lire le message d'accueil ;
• pour un site web, en observant les en-têtes de réponse HTTP (via curl -I ou votre proxy Burp Suite).

Exemples dans le labo

Sur une machine cible de votre labo, la détection de version avec Nmap se fait ainsi :

nmap -sV -p 22,80 192.168.56.20

Un résultat illustratif :

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH (version ancienne indiquée par la bannière)
80/tcp open  http    Apache httpd (version ancienne) ((Ubuntu))

Pour lire une bannière « à la main », vous pouvez vous connecter au port avec netcat et observer le message d'accueil :

nc 192.168.56.20 22

Le serveur répond avec une ligne qui annonce son protocole et son logiciel. Pour un site web, interrogez les en-têtes :

curl -I http://192.168.56.20/

Vous y lirez par exemple un en-tête Server indiquant le logiciel, parfois un en-tête révélant la technologie de l'application. Gardez ces lignes dans vos preuves : elles justifieront plus tard une recommandation.

Les limites de cette technique

Une bannière est une déclaration, pas une preuve. Plusieurs raisons peuvent la rendre trompeuse :

• Un administrateur soigneux peut la masquer ou la modifier pour ne pas révéler la version ;
• Un mandataire inverse (reverse proxy) ou un équilibreur de charge répond à la place du vrai serveur ;
• Certains correctifs de sécurité sont appliqués sans changer le numéro de version affiché (c'est courant sur les distributions Linux qui rapportent les correctifs sur d'anciennes versions) ;
• À l'inverse, une bannière peut être volontairement fausse, pour tromper les scanners.

Conclusion : une version lue dans une bannière est une hypothèse, qu'il faudra vérifier. Un bon rapport distinguera toujours « version annoncée » et « vulnérabilité confirmée ». Cette honnêteté intellectuelle est une marque de professionnalisme.

Au-delà des bannières : l'empreinte comportementale

Quand les bannières sont masquées, les outils déduisent la nature d'un service à partir de son comportement : la manière dont il répond à des requêtes particulières, les options qu'il propose, l'ordre des en-têtes, les messages d'erreur. Chaque logiciel a, en quelque sorte, une « signature » de comportement. La détection de version de Nmap repose sur une grande base de signatures de ce type. De même, des outils spécialisés identifient les technologies d'un site web (système de gestion de contenu, bibliothèques) à partir de détails dans les pages et les fichiers servis.

Le système d'exploitation peut lui aussi être deviné par la façon dont sa pile réseau se comporte (valeurs par défaut, gestion des paquets). Ce n'est jamais certain à 100 %, d'où la nécessité de croiser les indices.

Pourquoi la précision compte autant

Imaginez deux testeurs qui lisent la même bannière. Le premier écrit dans son rapport : « le serveur est vulnérable ». Le second écrit : « la bannière annonce une version ancienne, pour laquelle des vulnérabilités sont référencées ; elle n'a pas été confirmée à ce stade ». Le second travail est plus honnête, plus utile et plus défendable. Si le client constate ensuite que ses correctifs étaient en réalité appliqués, le premier testeur perd toute crédibilité ; le second a simplement fait la différence entre ce qu'il savait et ce qu'il supposait.

Prenez dès maintenant l'habitude d'une échelle à trois niveaux, que vous retrouverez dans les chapitres suivants :

• Annoncé : l'information vient d'une bannière ou d'un en-tête, sans autre vérification ;
• Déduit : plusieurs indices indépendants concordent (comportement, détection de version, système d'exploitation) ;
• Confirmé : la caractéristique a été démontrée, par exemple par un test non destructif dans le périmètre autorisé.

Le point de vue défensif : en dire le moins possible

Les bonnes pratiques de durcissement incluent de réduire les informations affichées : désactiver les bannières trop bavardes, retirer les en-têtes inutiles, personnaliser les pages d'erreur. Attention toutefois : masquer une version n'est pas une protection suffisante. C'est ce qu'on appelle la « sécurité par l'obscurité » : elle gêne l'attaquant, mais ne corrige aucune faille. La vraie protection, c'est la mise à jour et la configuration correcte. Le masquage n'est qu'une couche supplémentaire.

De l'inventaire à la liste de pistes

À ce stade de la mission, votre carnet doit contenir pour chaque machine une fiche complète. Voici un exemple de ligne de synthèse pour la mission Verdelune :

Ce tableau est le pont vers le chapitre suivant : l'analyse de vulnérabilités. Chaque ligne « piste » deviendra une recherche dans les bases de vulnérabilités.

À vous de jouer : fiche de reconnaissance complète

Pour deux machines de votre labo, produisez une fiche de reconnaissance : adresse, nom DNS s'il existe, ports ouverts, bannières lues (copiez les lignes brutes dans vos preuves), version annoncée, et pour chaque service un niveau de certitude (« annoncé par la bannière », « déduit du comportement », « confirmé »). Ajoutez deux recommandations défensives pour chaque machine.

La reconnaissance est terminée : vous avez une carte. Dans le chapitre suivant, nous entrons dans l'analyse de vulnérabilités, pour savoir quelles pistes méritent vraiment d'être suivies.