Aller au contenu

Network ToolsSecurity Mis à jour le 2026-07-27

Scanner hôtes et services avec nmap (inventaire et vérification autorisés)

Un guide défensif et à usage autorisé de nmap : découverte d'hôtes, scans SYN et connect, choix des ports, détection de services et d'OS, gabarits de rythme, formats de sortie pour la traçabilité, et lecture des états open, filtered et closed pour vérifier vos propres règles de pare-feu.

nmap envoie des sondes conçues sur mesure vers un hôte et vous rapporte quels ports TCP et UDP répondent, dans quel état chacun se trouve — et, si vous le demandez, quel logiciel écoute derrière. Lancé contre une infrastructure qui vous appartient, c’est un outil d’inventaire et de vérification : il vous dit quels ports le monde extérieur atteint vraiment, si un changement de pare-feu a fait ce que vous vouliez, et si un service que vous pensiez avoir coupé écoute encore. Une exécution typique ressemble à sudo nmap -sS -sV -p- 10.0.3.9, et la réponse qui compte, c’est la colonne d’état — open, filtered ou closed — parce que chacune est une affirmation différente sur votre pare-feu. Ce guide reste du côté défensif de l’outil : scanner vos propres hôtes pour confirmer que la réalité correspond à l’intention.

Ce que vous allez accomplir

  • Découvrir quels hôtes d’un sous-réseau sont actifs avec un balayage ping, sans toucher à un seul port.
  • Choisir le bon type de scan selon vos privilèges — scan SYN en root, scan connect quand vous ne l’êtes pas.
  • Sélectionner les ports délibérément avec -p, -p- et --top-ports, et comprendre pourquoi le scan UDP est lent et flou.
  • Identifier services et versions avec -sV, lancer le jeu de scripts par défaut avec -sC, et lire les suppositions d’OS avec -O.
  • Sauvegarder chaque scan dans un format analysable pour comparer deux scans et prouver qu’un changement de pare-feu a eu exactement l’effet voulu.

Prérequis

  • L’autorisation d’abord, toujours. Ne scannez que des hôtes qui vous appartiennent ou pour lesquels vous avez une permission explicite et écrite de tester. Scanner les ports de l’infrastructure de quelqu’un d’autre viole la politique d’utilisation acceptable de tout fournisseur infonuagique et de tout réseau que vous traverseriez, et dans bien des juridictions c’est une infraction criminelle, peu importe l’intention. Ce guide suppose que la cible est votre propre VM, votre propre sous-réseau, ou un système dont le propriétaire vous a autorisé par écrit. Si vous ne pouvez pas pointer cette autorisation, arrêtez ici.
  • nmap installé. Vérifiez avec nmap --version ; vous devriez voir quelque chose comme Nmap version 7.94 — toute version 7.x prend en charge chaque drapeau de ce guide. Installez-le avec apt install nmap, dnf install nmap, ou sur macOS brew install nmap.
  • Le compte root, pour les types de scan qui fabriquent des paquets bruts. -sS (scan SYN), -sU (UDP), -O (détection d’OS) et le traceroute exigent tous CAP_NET_RAW, donc en pratique vous lancez sudo nmap. Sans root, nmap bascule silencieusement vers un scan connect — utilisable, mais plus lent et plus visible dans les journaux de la cible.
  • Connaître l’adresse ou la plage de votre cible. Un hôte unique (10.0.3.9), une plage CIDR (10.0.3.0/24), une plage avec tiret (10.0.3.1-50) ou un nom d’hôte : tout fonctionne.

Comment ça marche

nmap procède par phases. Il décide d’abord quelles cibles sont vivantes (découverte d’hôtes), puis quels ports de chaque hôte vivant méritent une sonde, puis en option ce qui tourne derrière ces ports. Chaque phase réduit le travail de la suivante, et c’est pourquoi un scan complet -p- d’un /24 avec détection de version peut prendre des minutes alors qu’un balayage ping de la même plage prend des secondes. Comprendre les phases, c’est aussi savoir lire la sortie : l’état d’un port est l’interprétation par nmap de la façon dont la cible a répondu à une sonde, et cette interprétation, c’est toute la valeur de l’outil.

Un flux de gauche à droite d'un scan nmap — la plage de cibles alimente la découverte d'hôtes avec -sn, les hôtes vivants alimentent le scan de ports avec -sS ou -sT, les ports ouverts alimentent la détection de service et de version avec -sV, et tout est écrit avec -oA — à côté d'un panneau latéral expliquant que open signifie qu'un service a répondu, filtered qu'un pare-feu a écarté la sonde, et closed que l'hôte a répondu mais que rien n'écoute

Les trois états que vous lirez le plus sont open (quelque chose a répondu et a accepté la connexion), closed (l’hôte a répondu mais aucun service n’écoute sur ce port) et filtered (nmap n’a obtenu aucune réponse utile — un pare-feu a écarté la sonde en silence). Ce troisième état vaut la peine d’être intériorisé : filtered est ce que produit un pare-feu bien configuré, et le voir sur un port que vous vouliez bloquer, c’est la confirmation que vous cherchiez.

Étape par étape

1. Trouvez quels hôtes sont actifs. Un balayage ping (-sn) fait seulement de la découverte d’hôtes — aucun scan de port — donc c’est rapide et peu coûteux pour inventorier un sous-réseau :

sudo nmap -sn 10.0.3.0/24
Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 10.0.3.1
Host is up (0.00042s latency).
Nmap scan report for 10.0.3.9
Host is up (0.00061s latency).
Nmap scan report for 10.0.3.24
Host is up (0.00088s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 2.31 seconds

Trois hôtes ont répondu sur 256 adresses. Sur un sous-réseau local, nmap utilise ARP pour la découverte, ce qui est à la fois rapide et difficile à masquer pour un pare-feu d’hôte ; à travers un routeur, il retombe sur ICMP et quelques sondes TCP.

2. Lancez le scan par défaut sur un hôte. Sans drapeau de type de scan et en root, nmap lance un scan SYN de ses 1000 ports les plus courants. -sS le rend explicite :

sudo nmap -sS 10.0.3.9
Nmap scan report for 10.0.3.9
Host is up (0.00058s latency).
Not shown: 997 closed tcp ports (reset)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https
Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Le scan SYN envoie un SYN, guette le SYN-ACK qui veut dire open ou le RST qui veut dire closed, et ne complète jamais la poignée de main. Il exige root parce qu’il fabrique des paquets bruts. Not shown: 997 closed tcp ports est nmap qui vous dit que les 997 autres ports de sa liste top-1000 ont répondu par un RST — l’hôte est joignable et n’écoute tout simplement pas là.

3. Utilisez un scan connect quand vous n’êtes pas root. Sans privilèges, nmap ne peut pas forger de paquets bruts, alors il demande au noyau de compléter une poignée de main TCP entière avec -sT :

nmap -sT 10.0.3.9
Nmap scan report for 10.0.3.9
Host is up (0.00071s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https
Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds

Même résultat, mécanisme différent : conn-refused au lieu de reset dans la ligne « not shown » est l’indice qu’il s’agissait d’un scan connect. Il est plus lent sur de grandes plages de ports et apparaît comme des connexions complétées dans les journaux applicatifs de la cible, alors préférez -sS quand vous avez root et -sT seulement quand vous ne l’avez pas.

4. Choisissez les ports à dessein. Par défaut, nmap scanne 1000 ports courants. -p nomme des ports ou des plages précis, -p- scanne les 65535, et --top-ports N scanne les N plus courants :

sudo nmap -sS -p 22,80,443,5432 10.0.3.9
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
443/tcp  open     https
5432/tcp filtered postgresql

Ici, 5432/tcp filtered est la ligne intéressante : PostgreSQL est censé être coupé par le pare-feu depuis ce réseau, et filtered confirme que le pare-feu écarte les sondes vers lui. Pour un audit complet, sudo nmap -sS -p- 10.0.3.9 scanne chaque port et attrape un service que quelqu’un aurait monté sur un port haut inhabituel — c’est plus long, gardez-le pour la passe approfondie plutôt que pour la vérification rapide.

5. Scannez l’UDP séparément, et attendez-vous à ce que ce soit lent. L’UDP n’a pas de poignée de main, alors nmap envoie un paquet et déduit l’état du silence ou d’une erreur ICMP. Ça rend -sU lent et ses résultats plus vagues :

sudo nmap -sU --top-ports 20 10.0.3.9
PORT    STATE         SERVICE
53/udp  open          domain
123/udp open          ntp
161/udp open|filtered snmp
Nmap done: 1 IP address (1 host up) scanned in 18.44 seconds

open|filtered est le haussement d’épaules honnête de l’UDP : un port UDP fermé répond par un ICMP port-unreachable, mais un port ouvert reste souvent muet — comme un port bloqué par le pare-feu — donc nmap ne peut pas toujours les distinguer. Gardez les scans UDP aux ports qui vous importent vraiment (--top-ports 20 ou un -p explicite), parce qu’un balayage UDP complet peut prendre des heures.

6. Identifiez services et versions. -sV se connecte à chaque port ouvert et lit les bannières pour nommer le logiciel et sa version. -sC lance les scripts par défaut sûrs de nmap ; -O devine l’OS ; -A regroupe les trois plus le traceroute :

sudo nmap -sS -sV -p 22,80,443 10.0.3.9
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 9.6p1 Ubuntu 3ubuntu13.5 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http     nginx 1.24.0 (Ubuntu)
443/tcp open  http     nginx 1.24.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Vous voyez maintenant non seulement que SSH est ouvert, mais qu’il s’agit d’OpenSSH 9.6p1 — le détail de version qui vous permet de le comparer à une liste de vulnérabilités connues. Ajoutez -sC pour les scripts par défaut (ils vont, par exemple, extraire les détails du certificat TLS sur 443) ou prenez -A quand vous voulez tout et que le temps et le bruit supplémentaires ne vous dérangent pas.

7. Réglez le gabarit de rythme. -T0 à -T5 échangent la vitesse contre la politesse et la discrétion. -T3 est le défaut ; -T4 accélère en supposant un réseau rapide et fiable :

sudo nmap -sS -T4 -p- 10.0.3.9

Sur votre propre réseau local, -T4 est le bon défaut — le réseau est rapide, vous ne craignez pas de déclencher vos propres alarmes, et ça transforme un scan complet lent en scan rapide. Gardez -T0 et -T1 pour le cas rare où vous ménagez délibérément une cible fragile ; -T5 est assez agressif pour perdre des résultats sur un lien avec pertes, alors ne le prenez que sur un réseau vraiment rapide et local.

8. Consignez les résultats. Pour tout ce que vous voulez garder ou comparer, sauvegardez une sortie lisible par machine. -oN est du texte normal, -oG est « greppable », -oX est du XML, et -oA <base> écrit les trois d’un coup :

sudo nmap -sS -sV -p- -oA scans/db-2026-07-27 10.0.3.9
Nmap done: 1 IP address (1 host up) scanned in 24.10 seconds

Ça laisse scans/db-2026-07-27.nmap, .gnmap et .xml. Le fichier greppable est celui que vous comparez dans le temps — chaque port ouvert est sur sa propre ligne, donc un diff du scan de la semaine dernière contre celui d’aujourd’hui montre exactement ce qui a changé sur l’hôte.

Valider que ça fonctionne

Prouvez la boucle de bout en bout contre un service que vous contrôlez. Démarrez un écouteur jetable sur un port connu :

nc -l -p 9999 &

Puis scannez seulement ce port et confirmez que nmap le voit passer à open :

nmap -sT -p 9999 127.0.0.1
PORT     STATE SERVICE
9999/tcp open  distinct
Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

Arrêtez l’écouteur avec kill %1 et rescannez : le même port rapporte maintenant closed (l’hôte a répondu, rien n’écoute). Cette transition — open pendant que le processus tourne, closed après l’arrêt — est votre référence de ce à quoi ressemble un vrai changement d’état, et c’est le signal exact sur lequel vous vous appuyez pour vérifier une règle de pare-feu : bloquez le port, rescannez, et confirmez qu’il bascule à filtered plutôt.

Dépannage

  • Chaque port affiche filtered. Deux causes courantes. Soit un pare-feu écarte réellement toutes vos sondes — ce qui, pour un hôte verrouillé, est correct et attendu — soit vous avez demandé un type de scan que vous ne pouvez pas lancer. Si vous avez lancé -sS sans root, nmap a peut-être échoué à envoyer des paquets bruts ; relancez avec sudo, ou passez à -sT, qui n’exige aucun privilège. Si filtered persiste sous sudo contre un hôte que vous savez ouvert, l’écartement est en amont : un groupe de sécurité infonuagique ou une ACL réseau entre vous et la cible.
  • You requested a scan type which requires root privileges. -sS, -sU et -O fabriquent tous des paquets bruts et exigent CAP_NET_RAW. Lancez la commande sous sudo, ou si vous n’avez vraiment pas root, utilisez -sT pour le TCP — c’est la voie sans privilèges et elle donne la même réponse open/closed, juste plus lentement et plus visiblement.
  • Un hôte que vous savez actif rapporte « Host seems down ». nmap saute le scan de ports d’un hôte qui échoue à la découverte, et un hôte qui écarte l’ICMP paraît éteint aux sondes par défaut. Ajoutez -Pn pour sauter la découverte et le scanner quand même : sudo nmap -Pn -sS 10.0.3.9. C’est routinier contre les hôtes durcis et la plupart des VM infonuagiques, qui écartent le ping par politique.
  • Le scan est trop lent. Un -p- complet avec -sV sur un lien lent, c’est vraiment des minutes de travail. Réduisez la portée : scannez --top-ports 100 au lieu des 65535, laissez tomber -sV jusqu’à ce que vous sachiez quels ports sont ouverts, et sur votre propre réseau local rapide montez le rythme avec -T4. Si l’UDP est la partie lente, restreignez-le à la poignée de ports UDP que vous faites vraiment tourner.
  • Les résultats UDP sont tous open|filtered. C’est l’UDP qui fonctionne comme prévu, pas un bogue. Un port UDP ouvert qui ne répond pas à une sonde vide est indistinguable d’un port filtré. Pour trancher, ajoutez -sV pour que nmap envoie des charges propres au protocole qui provoquent une vraie réponse, ou acceptez l’ambiguïté et confirmez le service autrement — depuis l’hôte lui-même, ss -lun liste les sockets UDP réellement liés.

Quand c’est la mauvaise approche

nmap vous dit ce qui est joignable depuis l’endroit où vous vous tenez, ce qui est justement le mauvais angle pour certaines questions. Si vous voulez savoir sur quoi un hôte écoute peu importe le pare-feu au milieu, lancez ss -ltnp sur l’hôte lui-même — c’est instantané, faisant autorité, et sans scan. Si votre question porte sur les règles de pare-feu plutôt que sur leur effet, lisez-les directement ; les bases du pare-feu UFW couvrent leur audit et leur modification, et un scan sert à vérifier le changement après coup, pas à le faire. Si un nom résout vers la mauvaise adresse et qu’un « connection refused » est en fait un problème de DNS, dig pour le dépannage DNS vous y mène plus vite que n’importe quel scan de port. Et quand vous devez voir les vrais paquets qu’une sonde nmap produit — pour comprendre pourquoi un port lit filtered — capturer et filtrer le trafic avec tcpdump montre la sonde partir et ce qui revient, s’il y a lieu. La référence complète de chaque drapeau est le manuel officiel de nmap. Par-dessus tout : gardez le scan aux hôtes que vous possédez ou êtes autorisé à tester, et gardez la sortie sauvegardée quelque part où vous pourrez la pointer plus tard.

Si c’est le genre de travail que vous préféreriez ne plus jamais porter, c’est le quotidien d’Opérations Cloud — réservez une revue d’infrastructure.