Nmap pour cartographier un réseau, des hôtes aux services exposés

Nmap pour cartographier un réseau, des hôtes aux services exposés

nmap envoie des paquets à des adresses IP (Internet Protocol) et déduit de ce qui revient, ou ne revient pas, quelles machines existent, quels ports répondent et quels logiciels écoutent derrière. C’est l’outil de cartographie réseau de référence, pour l’attaquant comme pour celui qui défend. Sa sortie se lit vite et se croit trop facilement : un résultat nmap décrit un chemin réseau à un instant donné, pas la vérité d’une machine.

Explication de la marmotte

Avant d’acheter une maison, on en fait le tour : combien de portes, combien de fenêtres, lesquelles ferment mal. nmap fait ce tour pour un réseau d’ordinateurs. Il sert à savoir ce qui est réellement accessible de dehors, de préférence avant qu’un cambrioleur ne dresse la même liste, avec nettement moins de bienveillance.

→ Lire l’explication complète de la marmotte

À quoi sert nmap, qui l’édite et sous quelle licence

nmap répond à trois questions, dans cet ordre : qu’est-ce qui est allumé, qu’est-ce qui écoute, qu’est-ce qui tourne. Tout le reste (détection du système d’exploitation, scripts, traceroute) vient se greffer sur ces trois étapes.

Le projet est édité par Gordon Lyon (alias Fyodor) et le Nmap Project. Le code est publié sous la NPSL (Nmap Public Source License), une licence fondée sur la GPL (GNU General Public License) version 2 et complétée de clauses propres au projet. Conséquence pratique : l’usage interne est libre, mais embarquer nmap dans un produit propriétaire redistribué demande une licence commerciale distincte, vendue par l’éditeur. Les éditeurs de scanners de vulnérabilités le savent ; les équipes qui bricolent une appliance maison, moins souvent.

La distribution inclut des compagnons qui servent : Ncat (connexions réseau à la main), Nping (forge de paquets), Ndiff (comparaison de deux scans) et Zenmap (interface graphique).

Prérequis de plateforme : les modes de scan qui forgent des paquets exigent les droits root (ou des capacités équivalentes sur les sockets brutes) sous Linux, et le pilote de capture Npcap sous Windows. Sans privilèges, nmap fonctionne, mais dans un mode dégradé décrit plus bas, et ne prévient pas spécialement qu’il voit moins bien.

On le sort dans quatre situations : vérifier ce qu’une règle de pare-feu laisse réellement passer, inventorier un sous-réseau dont la documentation relève de la tradition orale, préparer ou recouper un test d’intrusion, et contrôler qu’une sonde de détection voit bien ce qu’elle prétend voir.

Découverte d’hôtes : décider quelles adresses méritent un scan

Scanner 65 535 ports sur chaque adresse d’une plage où neuf adresses sur dix sont vides, c’est long. nmap commence donc par trier les adresses vivantes.

Sur le segment local, il utilise ARP (Address Resolution Protocol) : une machine qui veut communiquer en IPv4 est obligée d’y répondre, pare-feu local ou pas. C’est la découverte la plus fiable qui existe, et elle ne fonctionne que sur le même domaine de diffusion.

Au-delà d’un routeur, nmap lancé avec privilèges envoie par défaut quatre sondes : une requête d’écho ICMP (Internet Control Message Protocol), un SYN (synchronize) TCP (Transmission Control Protocol) vers le port 443, un ACK (acknowledge) TCP vers le port 80 et une requête d’horodatage ICMP. Une seule réponse suffit à déclarer l’hôte vivant. Sans privilèges, il se rabat sur des tentatives de connexion vers les ports 80 et 443.

Le piège est là : un hôte qui ne répond à aucune de ces sondes est déclaré éteint, et ses ports ne sont jamais scannés. Un serveur qui n’expose que le port 22 derrière un pare-feu muet disparaît de la carte. L’option -Pn supprime cette étape et traite chaque adresse comme vivante ; on paie en temps, puisque chaque adresse vide subit un scan complet jusqu’à expiration des délais.

Position à tenir : -Pn sur une liste d’hôtes connue et courte, découverte ajustée (sondes -PS ou -PA vers des ports choisis) sur les grandes plages. Et l’option -n, qui coupe la résolution DNS (Domain Name System) inverse, sauf besoin explicite des noms : elle accélère le scan et évite d’annoncer ses intentions au serveur de noms de la cible.

Scan de ports et états rendus : ouvert, fermé, filtré

Le scan par défaut avec privilèges est le SYN scan (-sS) : nmap envoie le premier paquet d’une ouverture de connexion TCP, lit la réponse, et n’achève jamais la poignée de main. Le schéma suivant montre comment chaque type de réponse devient un état.

Trois états à ne pas confondre :

• open : un service a accepté l’ouverture. C’est la surface d’attaque.
• closed : la machine a répondu par un RST (reset). Rien n’écoute, mais le paquet est arrivé jusqu’à elle : le chemin est ouvert, et le jour où un service démarre sur ce port, il sera exposé sans qu’aucune règle ne change.
• filtered : aucune réponse exploitable. Un équipement a jeté ou rejeté le paquet, et nmap ne sait rien de ce qu’il y a derrière.

Un port fermé est donc une information de filtrage plus inquiétante qu’un port filtré. Vingt ans de revues de pare-feu apprennent que la règle « tout autoriser vers ce serveur, de toute façon il n’écoute que sur le 443 » survit toujours au serveur pour lequel elle a été écrite.

Sans privilèges, nmap bascule sur le scan par connexion complète (-sT), qui passe par l’appel système ordinaire. Il est plus lent et, surtout, il termine la poignée de main : la connexion apparaît dans les journaux applicatifs de la cible, là où le SYN scan ne laisse de trace que sur le réseau.

UDP (User Datagram Protocol) se scanne avec -sU et se comporte autrement, faute de poignée de main : une réponse applicative donne open, un message ICMP « port inaccessible » donne closed, et le silence donne open|filtered, c’est-à-dire « aucune idée ». Comme beaucoup de systèmes limitent leurs messages ICMP d’erreur à environ un par seconde, un scan UDP complet d’une seule machine se compte en heures. On cible donc une courte liste de ports (53, 123, 161, 500 selon le contexte) et on y ajoute la détection de version, qui envoie des charges propres à chaque protocole et lève une partie de l’ambiguïté. Les mécanismes sous-jacents sont détaillés dans la page sur les comportements d’UDP et de TCP.

Dernier point de périmètre : sans option, nmap teste les 1 000 ports TCP les plus fréquents, pas les 65 535. Un service d’administration posé sur un port exotique passe au travers. Pour un inventaire d’exposition, c’est -p- ou rien.

Détection de services et de versions, scripts NSE

Sans option de détection, le nom de service affiché à côté d’un port vient d’une table de correspondance : le port 443 s’appelle « https » parce que le fichier le dit, pas parce que quelqu’un a vérifié. Un serveur SSH (Secure Shell) déplacé sur le port 443 sera étiqueté https sans le moindre scrupule.

L’option -sV corrige cela : nmap ouvre une vraie connexion, écoute la bannière, envoie des sondes tirées de sa base et compare les réponses à des signatures. Le résultat nomme le produit et souvent sa version. Deux réserves s’imposent. La version annoncée est déclarative : les distributions rétroportent les correctifs de sécurité sans changer le numéro, donc une version « vulnérable » ne prouve pas la vulnérabilité, et une bannière se maquille en une ligne de configuration. Et la détection est bavarde : elle établit des connexions complètes et envoie des charges que certains services fragiles digèrent mal.

Le NSE (Nmap Scripting Engine) exécute des scripts écrits en Lua contre les ports trouvés. Les scripts sont rangés par catégories, dont default, safe, discovery, version, auth, vuln, brute, intrusive, exploit et dos. L’option -sC lance la catégorie default ; --script sélectionne un script ou une catégorie. Des scripts comme ssl-cert (certificat présenté) ou ssl-enum-ciphers (suites cryptographiques acceptées en TLS, Transport Layer Security) rendent des services réels à un architecte.

Les catégories ne sont pas décoratives : brute peut verrouiller des comptes, dos et exploit font ce que leur nom annonce, intrusive peut faire tomber un service. Lancer « tous les scripts pour voir » sur un environnement de production est une façon originale de transformer un inventaire en incident. Hors mandat explicite, on reste sur default et safe.

L’option -O tente d’identifier le système d’exploitation à partir du comportement de la pile réseau ; -A regroupe détection de système, versions, scripts par défaut et traceroute. Pratique en laboratoire, trop bruyant ailleurs.

Ce qu’un scan nmap révèle et ce qu’un pare-feu fausse

Un scan mesure la conversation entre un point de départ et une cible, équipements intermédiaires compris. Changer le point de départ change la réponse. La topologie suivante montre les deux positions à comparer : le scanner externe ne voit que ce que le pare-feu traduit, le scanner interne voit tout ce que le serveur écoute.

Depuis l’extérieur, on obtient l’exposition réelle, filtrage et NAT (Network Address Translation, traduction d’adresses) compris. Depuis l’intérieur, on obtient ce que la machine offre, donc ce qu’un attaquant atteindra le jour où il aura pris pied sur le segment. Les deux scans sont nécessaires ; l’écart entre les deux mesure ce que le pare-feu fait vraiment, par opposition à ce que son jeu de règles raconte.

Quatre façons dont un équipement intermédiaire fausse le résultat :

• Le silence. Un pare-feu qui jette les paquets rend tous les ports filtered et allonge le scan, chaque sonde attendant son délai avant retransmission.
• Les réponses usurpées. Certains équipements répondent à la place de la cible : un RST forgé fait passer un port filtré pour fermé ; un mandataire de poignée de main (protection contre l’inondation de SYN) renvoie un SYN/ACK sur tous les ports, et la machine semble tout exposer. La détection de version tranche : derrière un faux port ouvert, aucune application ne répond, et nmap affiche typiquement tcpwrapped.
• La limitation de débit. Au-delà d’un seuil, l’équipement cesse de répondre ou bloque la source. Les ports testés ensuite apparaissent filtrés alors qu’ils ne le sont pas, et rien dans la sortie ne signale le basculement.
• Le filtrage par source. Une règle qui n’autorise que certaines adresses rend le scan dépendant de l’adresse du scanner : le résultat vaut pour cette source, et pour elle seule.

L’option --reason affiche le type de réponse qui a motivé chaque état ; elle devrait être systématique, puisqu’elle distingue un silence d’un rejet ICMP. Un résultat surprenant se recoupe avec un second scan plus lent, depuis une autre source, avant d’atterrir dans un rapport.

Exemple : trois usages concrets de nmap

Les adresses ci-dessous sont des adresses privées ou de documentation ; pour s’exercer sans mandat, le projet met à disposition l’hôte scanme.nmap.org, dont le scan modéré est autorisé par l’éditeur.

Inventorier un segment local. Découverte seule, sans scan de ports, sans résolution de noms :

# -sn : découverte d'hôtes uniquement ; -n : pas de résolution DNS inverse
sudo nmap -sn -n 192.168.10.0/24

Mesurer l’exposition externe d’une adresse. Tous les ports TCP, débit plafonné pour ne pas déclencher la limitation en face, motif de chaque état, sortie dans les trois formats :

# -p- : ports 1 à 65535 ; --max-rate : plafond en paquets par seconde
# -Pn : pas de découverte, l'hôte est connu ; -oA : sorties normale, XML et grepable
sudo nmap -sS -Pn -n -p- --max-rate 500 --reason -oA externe-203.0.113.1 203.0.113.1

Qualifier ce qui répond. Détection de version et scripts par défaut, sur les seuls ports trouvés ouverts à l’étape précédente :

# -sV : versions ; -sC : scripts de la catégorie default
sudo nmap -sV -sC -Pn -n -p 22,443 -oA services-203.0.113.1 203.0.113.1

# Suites TLS acceptées sur le port 443
nmap -Pn -n -p 443 --script ssl-enum-ciphers 203.0.113.1

Suivre la dérive dans le temps. C’est l’usage qui rapporte le plus au défenseur : comparer le scan du jour à un état de référence et ne lire que les différences.

# Compare deux sorties XML (eXtensible Markup Language) et liste les écarts
ndiff reference.xml externe-203.0.113.1.xml

Un port qui apparaît entre deux scans sans demande de changement correspondante est soit une erreur, soit pire. Dans les deux cas, quelqu’un doit l’expliquer.

Détecter un scan nmap : journaux de pare-feu et IDS

Un scan de ports est l’un des événements les plus faciles à voir sur un réseau, à condition de regarder. Le schéma décrit les deux chaînes de détection : les journaux du pare-feu d’un côté, la sonde IDS (Intrusion Detection System, système de détection d’intrusion) de l’autre.

Côté journaux, la signature est comportementale : une source, beaucoup de ports ou beaucoup d’hôtes, des refus en rafale. Elle suppose que les refus soient journalisés, ce qui n’est pas le cas partout, pour des raisons de volume. Côté IDS, un moteur comme Suricata dispose de jeux de règles publics comportant une catégorie consacrée aux scans, et peut compter les événements par source avec des seuils. Certains marqueurs sont offerts : les scripts NSE qui parlent HTTP (HyperText Transfer Protocol) s’annoncent par défaut avec un agent utilisateur mentionnant « Nmap Scripting Engine », et les sondes de détection de version sont reconnaissables. Le déploiement d’une sonde est décrit dans le guide Suricata, la lecture de ce qu’elle remonte dans la page sur les menaces réseau et leur détection.

Ce que cette détection ne garantit pas : un scan étalé (gabarits -T0 ou -T1, quelques ports par heure) passe sous tout seuil raisonnable, un scan réparti sur de nombreuses sources aussi, et l’agent utilisateur se modifie. Détecter nmap, c’est détecter l’attaquant pressé ou négligent. Cela reste rentable, les deux espèces étant abondantes.

Côté interne, le signal vaut de l’or : un poste bureautique qui balaie son propre sous-réseau n’a aucune raison légitime de le faire. Sur Internet, en revanche, le scan est un bruit de fond permanent ; alerter sur chaque balayage externe revient à sonner l’alarme chaque fois qu’il pleut.

Limites de nmap et conditions d’exploitation

Ce que nmap ne garantit pas :

• L’exhaustivité. Ports hors liste par défaut, hôtes muets écartés à la découverte, UDP ambigu, IPv6 impossible à balayer par force brute : chaque angle mort est silencieux.
• La vulnérabilité. Une version détectée et un script de la catégorie vuln donnent des indices, pas un diagnostic. Le scanner de vulnérabilités authentifié et la revue de configuration restent nécessaires ; le test d’intrusion aussi, cadré comme le décrit la page commander et exploiter un test d’intrusion.
• La couche applicative. Un port 443 ouvert ne dit rien des vingt applications servies derrière le même mandataire inverse selon le nom demandé.
• La durée de validité. Un scan vaut pour l’instant où il a tourné.

Le compromis central tient en une ligne : vitesse contre fiabilité. Un scan rapide perd des paquets, déclenche les limitations et rend des faux « filtrés » ; un scan lent est exact et occupe la nuit. Pour un inventaire défensif, la recommandation est tranchée : tous les ports TCP, débit plafonné, deux points de vue (interne et externe), sortie XML conservée et comparée. La discrétion n’a aucun intérêt quand on scanne son propre réseau ; l’exactitude, si.

Conditions d’exploitation à prévoir :

• Le scanner est une cible. nmap tourne avec les droits root et analyse des réponses fournies par des machines potentiellement hostiles ; les scripts NSE sont du code exécuté avec ces mêmes droits. On le tient à jour, on ne charge pas de scripts tiers non relus, et la machine de scan est durcie et dédiée.
• Les résultats sont sensibles. Un fichier de sortie est une carte de la surface d’attaque, versions comprises. Il se stocke avec des droits restreints et une durée de conservation définie, pas dans un partage commun.
• L’exemption de détection est un risque. Placer l’adresse du scanner en liste blanche de l’IDS évite le bruit, et crée une adresse depuis laquelle tout scan est invisible. Mieux vaut étiqueter les alertes que les supprimer, et vérifier que les fenêtres de scan correspondent au calendrier prévu.
• Les équipements fragiles existent. Imprimantes, automates et vieux boîtiers embarqués supportent mal la détection de version et les scripts. Sur ces périmètres, découverte et scan de ports seuls, à débit réduit.

D’autres fiches de la même famille sont regroupées dans la rubrique Outils.

Cadre légal du scan de ports en France

On ne scanne que ce qu’on a le droit de tester : périmètre défini, accord écrit du responsable du système, dates et adresses sources consignées. Cette règle ne souffre aucune exception du type « c’était juste pour vérifier ».

En France, le texte de référence est le code pénal, articles 323-1 et suivants. L’article 323-1 réprime l’accès ou le maintien frauduleux dans un système de traitement automatisé de données ; l’article 323-2, le fait d’entraver ou de fausser son fonctionnement, ce qu’un scan agressif ou un script de la catégorie dos peut produire ; l’article 323-3-1, la détention ou la mise à disposition, sans motif légitime, d’outils conçus pour commettre ces infractions ; l’article 323-7 punit la tentative des mêmes peines. Les quanta de peine figurent dans le texte en vigueur sur Légifrance, seule source à citer. La qualification d’un scan donné relève du juge et du conseil d’un avocat, pas d’une fiche d’outil.

Deux angles morts reviennent souvent. L’accord du client ne vaut pas accord de son hébergeur : les fournisseurs d’infrastructure ont leurs propres conditions sur les tests, à lire avant le premier paquet. Et une adresse IP mal recopiée dans un périmètre désigne le système de quelqu’un d’autre, qui n’a rien signé.

🐝 Ce qui arrive si on s’en passe

Sans scan régulier de son propre périmètre, la seule description de l’exposition reste la configuration déclarée : règles de pare-feu, inventaire, schémas. Aucun de ces documents ne répond aux paquets. Un service démarré par l’installation d’un paquet logiciel, une règle temporaire jamais retirée ou une traduction d’adresse oubliée restent invisibles jusqu’à ce qu’un tiers les trouve, ce que les balayages permanents d’Internet font sans relâche. On perd aussi le point de comparaison : sans état de référence daté, impossible de dire depuis quand un port répond, donc de borner une investigation. Enfin, les règles de détection ne sont jamais éprouvées : une sonde qui n’a jamais vu passer un scan connu n’a jamais prouvé qu’elle le voyait.

🦫 Explication de la marmotte 🍫

nmap envoie de petits messages aux machines d’un réseau et classe ce qui revient. Première étape : repérer quelles adresses correspondent à une machine allumée, en leur envoyant plusieurs messages différents et en notant celles qui répondent. Deuxième étape : pour chaque machine trouvée, envoyer un message à chacun de ses points d’entrée numérotés, qu’on appelle des ports. Une réponse positive signifie qu’un programme écoute ; un refus net signifie que la machine est joignable mais que rien n’écoute ; un silence signifie qu’un équipement de filtrage, placé sur le chemin, a jeté le message. Troisième étape : sur les entrées ouvertes, nmap engage un début de conversation pour identifier le programme et sa version, puis peut lancer de petits programmes complémentaires qui posent des questions plus précises. Tout dépend de l’endroit d’où part le test : depuis l’extérieur, on voit ce que le filtrage laisse passer ; depuis l’intérieur, on voit ce que les machines offrent réellement. Quand le filtrage ralentit, se tait ou répond à la place des machines, le résultat devient faux sans prévenir, d’où la nécessité de recouper. Celui qui protège un réseau s’en sert pour comparer la liste de ce qui devrait répondre avec ce qui répond vraiment. Ces tests laissent des traces dans les journaux du filtrage et déclenchent les sondes de surveillance. Enfin, la loi interdit de tester un réseau sans l’accord écrit de son responsable.

À lire aussi

• Wireshark, capturer et lire des trames réseau avec filtres et TLSFiche d'outil Wireshark, de la capture de trames à la lecture couche par couche, avec filtres de capture et d'affichage, tshark, déchiffrement TLS de son propre trafic, limites et cadre légal.
• Kali Linux pour les tests d'intrusion, usages, limites et détectionKali Linux est une distribution Debian d'OffSec pour les tests d'intrusion, avec ses usages, ses limites, sa détection sur un réseau et son cadre légal.
• Captures, observabilité et diagnostic multi-coucheFournir une méthode de dépannage structurée, du câble à l’application, avec outils système, captures paquet, logs, flux, géolocalisation et investigation.
• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.

Pages voisines

La citent

• Wireshark, capturer et lire des trames réseau avec filtres et TLS
• Kali Linux pour les tests d'intrusion, usages, limites et détection
• Prioriser les vulnérabilités avec CVSS 4.0, EPSS, KEV et exposition

Nmap pour cartographier un réseau, des hôtes aux services exposés

Elle cite

• ⇄Lien dans les deux sens :Menaces réseau, détection et réponse opérationnelle
• Configurer Suricata sur un segment réseau critique
• Mettre en place une gestion récurrente des vulnérabilités
• Migrer TLS legacy sans casser les clients anciens
• Pourquoi un automate industriel ne se patche pas
• Test d'intrusion : commander, cadrer et exploiter un pentest
• UDP, TCP et comportements de transport

⇄ : les deux pages se citent l’une l’autre.