Comment fonctionne la détection du système d'exploitation avec Nmap : comprendre le fingerprinting de pile TCP/IP

Ce leurre utilise un profil de déception Windows Server. Les bannières des services sont cohérentes, rien dans la couche applicative n’indique que la machine tourne sous Linux, pourtant Nmap l’identifie comme tel.

Nmap est l’un des outils de reconnaissance réseau les plus utilisés en cybersécurité offensive. Il permet de découvrir les hôtes actifs, d’énumérer les ports ouverts, d’identifier les services exposés ainsi que leurs versions, et d’estimer le système d’exploitation d’une machine cible.

La raison est que le moteur de fingerprinting OS de Nmap ne se base pas sur les bannières mais observe plutôt le comportement de la pile TCP/IP lorsqu’elle répond à des paquets spécialement construits.

Dans cet article, nous allons voir en détail comment fonctionne le fingerprinting OS de Nmap et ce qu’il faut pour construire une usurpation crédible d’un système d’exploitation. Nous aborderons également les défis rencontrés lors du développement du moteur de déception OS d’Anantis TrapEye.

Comment le fingerprinting est-il possible si tous les OS suivent les RFC TCP ?

Parce que les RFC laissent une marge de choix dans les implémentations.

Les RFC TCP définissent le comportement attendu du protocole, mais ne spécifient pas chaque détail. Par exemple, un segment TCP doit annoncer une fenêtre de réception, mais les RFC ne définissent pas une valeur précise. Elles décrivent également comment gérer les paquets valides, mais laissent certains cas non définis, comme les paquets sans aucun flag TCP actif, car ils ne font pas partie du trafic normal.

Lorsque la spécification laisse une marge d’interprétation, les développeurs des systèmes d’exploitation doivent faire des choix. Ces choix peuvent avoir été faits par un développeur Microsoft il y a plusieurs décennies ou provenir d’un ancien commit du noyau Linux. Une fois déployés, ils ont tendance à rester inchangés, car modifier le comportement TCP peut introduire des problèmes de compatibilité avec les systèmes existants.

Nmap exploite ces différences, qui constituent souvent une empreinte beaucoup plus fiable qu’une bannière de service, qui peut être modifiée simplement avec un fichier de configuration.

TTL et taille de fenêtre TCP

Quand on pense au fingerprinting OS, deux signaux viennent souvent à l’esprit : le TTL et la taille de fenêtre TCP.

TTL

Chaque paquet IP contient un champ Time To Live (TTL) : un compteur décrémenté de un à chaque routeur traversé. Lorsqu’il atteint zéro, le paquet est supprimé. Son objectif est d’empêcher les boucles de routage : sans TTL, un paquet mal routé pourrait circuler indéfiniment entre plusieurs routeurs.

La RFC ne définit pas la valeur initiale du TTL, laissant les systèmes d’exploitation choisir leurs propres valeurs par défaut :

Exemple: un paquet reçu avec un TTL de 57 a probablement été envoyé avec une valeur initiale de 64 et a traversé sept routeurs. C’est une indication raisonnable que la machine distante utilise un système Unix.

Cependant, le TTL reste un signal faible. Il existe seulement quelques valeurs initiales courantes, et Nmap compare les fingerprints avec une base contenant des milliers de signatures.

Taille de fenêtre TCP

La fenêtre TCP correspond à la quantité de données qu’un hôte accepte de recevoir avant qu’un ACK (accusé de réception) ne doive être renvoyé. C’est un mécanisme de contrôle de flux qui empêche un serveur rapide de submerger un client plus lent.

La valeur annoncée dépend de la configuration choisie par le système d’exploitation. Windows a historiquement utilisé des valeurs comme 8192 puis 65535. Linux annonce souvent des valeurs autour de 64240 ou 65160 selon la version du noyau et le MSS.

Comparée au TTL, la taille de fenêtre fournit davantage d’informations car elle reflète le comportement de la pile TCP plutôt qu’une simple estimation du nombre de sauts réseau.

Cependant, elle reste une simple valeur présente dans un en-tête de paquet. Comme le TTL, elle peut être facilement modifiée, par exemple avec une simple commande sysctl.

Comment Nmap réalise son fingerprinting

Une idée reçue répandue est que le fingerprinting OS repose sur un seul paquet.

nmap -O envoie en réalité seize requêtes différentes et décompose les réponses en environ quinze groupes d’attributs. Pour obtenir les meilleurs résultats, il utilise à la fois un port ouvert et un port fermé. En effet, la différence entre la manière dont une machine accepte et refuse des connexions fait partie de son empreinte.

Numéros de séquence

Lorsqu’un hôte accepte une connexion, il choisit un Initial Sequence Number (ISN). Ce nombre doit être imprévisible pour une raison importante : en 1994, Kevin Mitnick a compromis les systèmes de Tsutomu Shimomura en prédisant les ISN générés par une pile TCP. Si un attaquant peut correctement prédire un ISN, il peut injecter des paquets dans une connexion TCP existante.

Nmap collecte les ISN présents dans ces réponses et calcule plusieurs statistiques. L’une d’elles est le plus grand commun diviseur (PGCD) des différences entre plusieurs numéros de séquence successifs.

Deux générateurs pseudo-aléatoires peuvent être suffisamment imprévisibles tout en restant statistiquement différents. Nmap ne vérifie pas si les numéros de séquence sont aléatoires mais certaines spécificités.

Par exemple, un générateur peut incrémenter un compteur interne d’une valeur fixe avant d’ajouter du bruit aléatoire, tandis qu’un autre peut tirer chaque valeur indépendamment depuis un générateur cryptographiquement sécurisé. Les deux empêchent suffisamment bien le détournement TCP, mais chacun possède une signature statistique différente pouvant être identifiée.

IP ID

Chaque paquet IP possède un identifiant de 16 bits utilisé pour le réassemblage des fragments. La manière dont cette valeur est générée dépend de l’implémentation.

Les anciennes versions de Windows utilisaient un compteur global unique, incrémenté de un pour chaque paquet sortant, toutes connexions confondues. Les versions modernes de Linux utilisent souvent la valeur zéro pour les paquets qui ne sont pas fragmentés, tandis que d’autres systèmes utilisent des valeurs aléatoires ou des compteurs par flux.

Nmap analyse ces comportements et observe l’évolution des valeurs sur plusieurs paquets.

Timestamps

Les timestamps TCP constituent une autre source d’information pour le fingerprinting OS. Chaque segment TCP peut inclure une valeur de timestamp générée depuis un compteur interne du noyau. Cette option est principalement utilisée pour des mécanismes comme PAWS (Protection Against Wrapped Sequence numbers) et la mesure du temps aller-retour (RTT).

Nmap mesure l’évolution de cette valeur entre ses différentes requêtes et utilise le temps écoulé pour estimer la fréquence de l’horloge utilisée.

Les anciens systèmes Linux utilisaient souvent une fréquence de 100 Hz, tandis que les versions plus récentes de Linux et FreeBSD utilisent 1000 Hz.

Avec seulement quelques paquets, Nmap peut donc déduire certaines caractéristiques de l’horloge utilisée par la pile TCP distante.

Le support des timestamps TCP constitue également un signal intéressant. Historiquement, Windows désactivait les timestamps TCP par défaut. L’absence de cette option devient donc une partie de l’empreinte. Nmap l’enregistre sous la forme TS=U (unsupported) et lui attribue un score comme pour n’importe quel autre attribut.

Ordre des options TCP

Les options TCP sont un autre exemple de comportement spécifique à chaque implémentation. Un SYN-ACK peut contenir des options comme MSS, SACK, timestamp et window scaling. La majorité des systèmes modernes supportent les mêmes options, mais leur ordre varie selon les implémentations.

Linux :

1. MSS
2. SACK
3. Timestamp
4. NOP
5. WScale

Windows :

1. MSS
2. NOP
3. WScale
4. SACK
5. Timestamp

Nmap enregistre cet ordre sur plusieurs sondes (O1 à O6). Comme les RFC n’imposent pas d’ordre spécifique, chaque pile TCP a développé sa propre convention.

Sondes malformées

Après les sondes SYN, Nmap envoie des paquets que les applications normales génèrent rarement : des segments sans aucun flag activé ou des paquets ACK ne correspondant à aucune connexion existante.

Ces paquets sont utiles car les RFC définissent le comportement normal, mais laissent de nombreux cas invalides sans spécification précise. Les différentes implémentations TCP ont donc fait des choix différents pour les gérer. Certaines répondent avec un RST, certaines restent silencieuses, et d’autres produisent des variations plus subtiles.

Certaines piles ont également historiquement laissé des valeurs non nulles dans certains champs, même lorsque le flag correspondant n’était pas activé. Ces comportements sont sans impact fonctionnel mais deviennent des empreintes très distinctives.

Comment Nmap évalue une empreinte

L’empreinte obtenue est comparé à la base de données nmap-os-db à l’aide d’un système de pondération.

Cette pondération montre pourquoi certaines idées reçues sur le fingerprinting OS sont trompeuses. Le TTL et la taille de fenêtre TCP sont faciles à observer et à modifier, mais ils ont un impact relativement faible sur le score final.

Contourner le fingerprinting OS de Nmap

Une fois que l’on comprend comment Nmap construit un fingerprint, le contourner consiste à contrôler les signaux qu’il observe.

Certaines parties du fingerprint sont de simples attributs présents dans les paquets, comme le TTL, la taille de fenêtre TCP ou l’ordre des options TCP. D’autres résultent du comportement interne du noyau : génération des numéros de séquence, progression des timestamps, allocation des IP ID ou gestion des erreurs. Ces dernières ne peuvent pas être modifiées de manière fiable sans reproduire l’état interne normalement maintenu par le système d’exploitation.

Il existe deux approches principales pour construire un moteur de déception de système d’exploitation.

Émulation complète de la pile TCP/IP en espace utilisateur

La première approche consiste à remplacer entièrement la pile TCP/IP du noyau par une implémentation en espace utilisateur. Chaque paquet est généré par le moteur de déception, ce qui offre un contrôle total sur tous les comportements réseau observables. C’est le modèle utilisé par des projets comme Honeyd.

Son principal avantage est le contrôle maximal du fingerprint. Le moteur de déception peut faire apparaître un système comme n’importe quel autre système d’exploitation d’un point de vue réseau.

En contrepartie, la pile TCP du noyau n’intervient plus. Le moteur doit implémenter lui-même le comportement TCP normalement fourni par le système d’exploitation. Si l’objectif est d’exposer un service SSH, SMB ou HTTP réaliste derrière cette pile TCP personnalisée, il ne peut pas simplement transférer la connexion vers un service existant. Le noyau ne connaît pas la connexion TCP émulée ; une application classique ne peut donc pas s’y attacher via une socket standard.

Modification des paquets à la volée

La seconde approche consiste à laisser le système d’exploitation gérer normalement les connexions, puis à modifier les paquets avant qu’ils ne quittent la machine. Les applications continuent de fonctionner normalement, tandis que certaines caractéristiques du fingerprint sont réécrites à la volée. La difficulté est que tous les attributs ne sont pas aussi faciles à modifier.

Cette approche offre moins de contrôle qu’une pile TCP entièrement en espace utilisateur, car certains comportements générés par le noyau sont difficiles, voire impossibles, à réécrire de manière cohérente. En revanche, elle préserve le réalisme des services natifs sans nécessiter de reconstruire toute la pile réseau.

Pour une plateforme de déception, conserver de vrais services tout en contrôlant les signaux de fingerprinting les plus importants constitue généralement le meilleur compromis. Les services interactifs restent réalistes, tandis que le fingerprint réseau exposé peut être manipulé sans remplacer complètement la pile TCP/IP.

À propos d’Anantis

Anantis TrapEye est notre plateforme avancée de déception. L’émulation des systèmes d’exploitation n’est qu’une des nombreuses couches de son modèle de déception : nos leurres présentent une cible cohérente et crédible avec laquelle un attaquant interagit suffisamment longtemps pour révéler ses intentions.

En savoir plus

Références

• https://nmap.org/book/osdetect-methods.html
• https://raw.githubusercontent.com/nmap/nmap/refs/heads/master/nmap-os-db
• https://github.com/DataSoft/Honeyd