Scan de ports : lire le résultat, mesuré sur nos
propres serveurs

Trois lignes. C'est tout ce que scanme.nmap.org, le serveur que le projet Nmap met à disposition pour s'entraîner, a renvoyé quand je l'ai scanné pour préparer cet article : un SSH ouvert, un port SMTP filtré, un serveur web ouvert. Le reste des cent ports testés a répondu fermé. Trois états différents en trois lignes, et c'est déjà là que se joue l'essentiel : un scan de ports ne vaut pas par la commande qu'on tape, il vaut par ce qu'on sait lire dans ce qu'il rend.

La plupart des tutoriels s'arrêtent à la commande. On va faire l'inverse : partir du résultat. Ce que veut dire un port ouvert face à un port filtré, pourquoi la colonne SERVICEvous ment tant que vous n'avez pas demandé les versions, comment on passe d'un numéro de port à une CVE, et ce qu'un attaquant ou un outil de gestion de surface d'attaque externe en tire à votre place.

Et parce qu'un scan ne s'apprend vraiment que sur une machine dont on connaît la vérité, j'ai aussi scanné les 65 535 ports de nos trois serveurs et comparé le résultat à leur configuration. Sur l'un d'eux, le pare-feu déclarait 3 ports TCP ouverts et 6 étaient joignables depuis Internet. Toutes les sorties ci-dessous sont réelles, prises sur nos machines ou sur des cibles qui autorisent le scan.

Ce qu'un scan de ports vous dit vraiment

Voici la sortie brute du scan qui ouvre l'article. J'ai demandé à nmap les cent ports les plus courants, avec détection de version (-sV), sur le serveur d'entraînement du projet :

$ nmap -sV --top-ports 100 scanme.nmap.org

Nmap scan report for scanme.nmap.org (adresse masquée)
Host is up (0.18s latency).
Not shown: 97 closed tcp ports (conn-refused)
PORT   STATE    SERVICE VERSION
22/tcp open     ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.13 (Ubuntu Linux; protocol 2.0)
25/tcp filtered smtp
80/tcp open     http    Apache httpd 2.4.7 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Nmap done: 1 IP address (1 host up) scanned in 10.20 seconds

La ligne qui compte le plus est celle qu'on lit trop vite : Not shown: 97 closed tcp ports. Quatre-vingt-dix-sept ports ont répondu qu'ils étaient joignables mais que personne n'écoutait derrière. Un port fermé qui répond confirme que l'hôte est vivant et qu'aucun filtrage ne s'interpose. Le port 25/tcp, lui, est marqué filtered, et c'est une information différente : nmap n'a pas pu savoir s'il y a un serveur mail, parce qu'un pare-feu a avalé la sonde en silence. Deux ports non exploitables, deux raisons opposées.

Restent les deux ports open : 22 et 80. Un service écoute, il accepte les connexions, il est joignable depuis Internet. C'est le périmètre qu'un attaquant énumère en premier, et c'est là que la détection de version (colonne VERSION) intervient. On y revient plus bas, car sans elle nmap se contente de deviner.

Les six états d'un port, et pourquoi filtered n'est pas closed

La documentation de Nmap définit six états possibles pour un port, pas trois. La nuance n'est pas académique : elle dit combien vous pouvez faire confiance au résultat. Un scan qui rend surtout des filtered vous renseigne davantage sur le pare-feu de la cible que sur ses services, et un scan UDP produit une catégorie hybride qu'on ne rencontre presque jamais en TCP.

Les deux états composés (open|filtered et closed|filtered) apparaissent quand la cible reste muette et que nmap ne peut pas conclure. C'est le lot commun de l'UDP, qui n'a pas de poignée de main pour confirmer une connexion. En clair : un port silencieux n'est pas un port fermé, et traiter l'absence de réponse comme une bonne nouvelle est l'erreur d'interprétation la plus courante. Ce vocabulaire est le même quel que soit l'outil ; nmap l'a simplement rendu canonique.

Ce que nmap a trouvé sur nos propres serveurs

Lire un scan sur scanme, c'est bien. Le confronter à ce que l'on croit savoir de sa propre infrastructure, c'est autre chose. Le 7 octobre 2026, j'ai passé nos trois serveurs (le serveur de production, un serveur annexe et un troisième) au même traitement, depuis un accès résidentiel français, en IPv4.

La mesure

Un balayage SYN des 65 535 ports TCP de chaque machine (nmap -sS -p- --max-rate 800 -T4, nmap 7.92), puis la détection de version sur les ports ouverts, puis un scan UDP de six ports courants (53, 123, 161, 443, 500 et 1194). En parallèle, j'ai relu en SSH, sans rien modifier, ce que chaque hôte déclare : les ports en écoute, la politique du pare-feu ufw et les conteneurs Docker. Un port compte comme "autorisé" s'il est ouvert à tous dans ufw, et comme "joignable" s'il répond open au scan depuis l'extérieur. Trois machines, c'est un retour d'expérience, pas une statistique : les chiffres décrivent notre infrastructure, pas Internet. Les adresses IPv6 des machines n'ont pas été scannées.

Deux machines sur trois sont conformes à leur politique. La troisième expose le double de ce que son pare-feu déclare, et la cause est connue de tous ceux qui ont déjà mélangé ufw et Docker sans y prêter attention. Quand un conteneur publie un port (-p dans un docker run, ou ports: dans un fichier compose) sur toutes les interfaces, Docker écrit ses propres règles iptables et les place avant celles d'ufw. Le paquet est accepté avant même qu'ufw ait été consulté, et ufw status continue d'afficher une politique propre. Ici l'exposition était voulue sur le fond ; elle était simplement absente de la seule politique que l'on relit.

Le plus parlant est ailleurs. Avant même ce scan, Shodan avait déjà indexé 2 de ces 3 ports en trop. L'écart entre la politique affichée et la réalité, un moteur public le connaissait, nous non. Le troisième port, un service TCP qui envoie pourtant sa bannière à la connexion et ouvert depuis au moins 64 jours, n'y figurait pas : un index public n'est pas un inventaire, et c'est l'objet de l'article sur ce que Shodan indexe. Sur nos trois serveurs et scanme, il retrouvait 15 des 18 ports exposés (83,3 %), 15 sur 17 (88,2 %) si l'on retire un OpenVPN muet qu'aucun scanner externe ne peut voir.

Le serveur de production : 65 533 ports filtrés, et un UDP indéchiffrable

Sur le serveur de production, le résultat TCP est l'image même d'un pare-feu en politique de rejet : 65 533 ports reviennent filtered, 2 sont open. L'UDP est une autre histoire, et c'est l'illustration la plus nette de l'état open|filtered décrit plus haut.

Les six ports UDP sondés sont revenus open|filtered, et un seul était réellement ouvert : notre OpenVPN. Il est configuré pour ignorer tout paquet qui ne porte pas la bonne signature (l'option tls-auth), donc il ne répond jamais à une sonde. Vu de l'extérieur, un port UDP ouvert et muet est strictement indiscernable d'un port filtré. Ce n'est pas une faiblesse de nmap, c'est la nature du protocole, et c'est aussi pourquoi les moteurs d'exposition ne voient pas ce service. La conclusion pratique vaut pour tous les scans UDP : un open|filtered ne se tranche qu'avec la configuration de l'hôte, ou avec une sonde qui parle le bon protocole.

La commande nmap, de la découverte rapide au balayage complet

Le comportement par défaut de nmap ne scanne que les 1000 ports TCP les plus fréquents, ce qui suffit pour un état des lieux mais laisse filer tout ce qui se planque sur un port haut. Voici les variantes qu'on utilise vraiment, du plus rapide au plus exhaustif, avec ce que chacune apporte :

# Découverte rapide : les 1000 ports courants, juste l'état
nmap cible

# Tous les ports TCP (65535), pour débusquer un service sur un port haut
nmap -p- cible

# Ports précis + détection de version du logiciel qui écoute
nmap -sV -p 22,80,443,8080 cible

# Scan UDP des ports les plus courants (lent, souvent open|filtered)
nmap -sU --top-ports 20 cible

# Scan complet réaliste : versions + scripts par défaut + tous les ports
nmap -sV -sC -p- cible

Le -p- est l'option qu'on oublie et qui rapporte le plus : c'est le seul moyen de voir la console de debug oubliée sur 9000 ou l'interface d'admin sur 8443. Le -sU couvre l'UDP, où vivent DNS, SNMP et bien des services qu'un scan TCP ignore totalement. Reste un piège que la sortie par défaut tend à tout le monde. Scannez votre propre machine sans -sV et regardez la colonne SERVICE :

$ nmap localhost

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
2222/tcp open  EtherNetIP-1
3000/tcp open  ppp
5432/tcp open  postgresql

2222/tcp annoncé EtherNetIP-1, 3000/tcp annoncé ppp : c'est faux. Ces machines hébergent un second SSH et un serveur de développement. La colonne SERVICE sans -sV n'est qu'un annuaire figé qui associe un numéro de port à un nom conventionnel. Elle ne prouve rien de ce qui tourne réellement, et c'est ce qui sépare un simple scanner de vulnérabilités mal réglé d'un outil qui interroge vraiment le service.

Détection de versions et scripts NSE, du port au CVE

L'option -sV corrige ce mensonge. nmap se connecte à chaque port ouvert, lui envoie des sondes spécifiques et compare la réponse à sa base de signatures, qui couvre selon sa propre documentation plus de 180 protocoles. C'est ce qui a fait apparaître OpenSSH 6.6.1p1 et Apache httpd 2.4.7 dans le premier scan. Une version précise, c'est la clé d'entrée vers une CVE : on rapproche la bannière du service d'une base de failles connues, et on obtient une hypothèse de vulnérabilité à vérifier.

Le moteur de scripts NSE va un cran plus loin. La catégorie vuln (nmap --script vuln) exécute des tests de failles connues, et des scripts comme vulners confrontent la version détectée à une base de CVE. Plus modestement, des scripts d'information enrichissent le résultat sans rien exploiter. En voici deux passés sur le port 80 de scanme, qui récupèrent le titre de la page et les en-têtes de réponse :

$ nmap -sV --script=http-title,http-headers -p 80 scanme.nmap.org

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
| http-headers:
|   Server: Apache/2.4.7 (Ubuntu)
|   Content-Type: text/html
|_  (Request type: HEAD)
|_http-title: Go ahead and ScanMe!

C'est puissant pour un premier tri, mais il faut garder la tête froide sur ce que ça vaut. nmap signale une version connue pour être vulnérable, il ne prouve pas qu'elle l'est ici et maintenant. Un correctif rétroporté par la distribution, un module désactivé, une configuration défensive : autant de raisons pour lesquelles une CVE corrélée n'est pas une CVE exploitable. Un scan de ports produit des hypothèses classées, pas des verdicts. Ce que confirme la différence entre scan de vulnérabilité et pentest : la corrélation trie, l'exploitation prouve. Pour prioriser ces hypothèses, on s'appuie ensuite sur le score CVSS et, mieux, sur l'exploitabilité réelle.

Les ports qu'on retrouve toujours exposés

À force de scanner des surfaces, un motif revient. Une poignée de ports concentre l'essentiel de l'exposition, et chacun raconte un risque différent selon qu'il devrait ou non être ouvert vers Internet. Le tableau ci-dessous liste ceux qu'on croise le plus, sans chiffre inventé sur leur fréquence : juste le service attendu et ce qu'un port ouvert y signifie.

Le vrai danger n'est presque jamais le port 443 d'un site volontairement public. C'est la base de données oubliée en 5432, la console d'admin en 8080 mise en ligne pour un test et jamais refermée. Autrement dit du shadow IT, ces actifs que personne n'a déclarés et que votre inventaire ignore. Un moteur comme Shodan passe son temps à indexer ces ports à l'échelle d'Internet, et n'importe qui peut les interroger en quelques secondes.

Du scan ponctuel à la surveillance continue de vos ports

Le problème d'un scan nmap, aussi bien lu soit-il, c'est qu'il photographie un instant. Le lendemain, un déploiement rouvre un port, une image conteneur expose un service de debug, une mise à jour change une version qui devient vulnérable. La photo est déjà périmée. C'est la limite structurelle du scan manuel, et la raison d'être de la gestion de surface d'attaque externe : rejouer cette reconnaissance en continu, à partir d'un simple nom de domaine, sans plage d'IP à fournir.

Concrètement, le module de cartographie de surface de l'EASM own2pwn part d'une graine, découvre les sous-domaines par les journaux de Certificate Transparency et le DNS, puis confirme chaque actif par un scan de ports et une empreinte de service, la chaîne décrite plus haut, mais automatisée et répétée. Le module de pentest automatisé enchaîne avec plus de 240 modules de détection qui corrèlent les CVE par bannière et version, non-intrusifs par conception, avec un débit plafonné par hôte. À chaque passage, l'inventaire est comparé au précédent : ce qui remonte à l'écran, c'est le delta, le port qui vient de s'ouvrir ou la version qui a changé, pas l'export complet.

Cette bascule du port vers le finding, puis du finding vers le risque priorisé, c'est le passage du scan brut à la gestion des vulnérabilités. Le scan reste la première brique. Il ne devient utile en défense que branché sur un cycle qui le compare à lui-même dans le temps.

À retenir

• Le pare-feu affiché n'est pas le pare-feu réel. Sur l'un de nos serveurs, ufw déclarait 3 ports TCP et 6 étaient joignables : Docker publie ses ports avant ufw. Shodan en avait déjà indexé 2 sur 3. Seul un scan externe tranche.
• Lisez les états avant les services. open, closed et filtered ne disent pas la même chose : un port filtré révèle un pare-feu, un port fermé confirme un hôte vivant sans service.
• La colonne SERVICE ment sans -sV. Sans détection de version, nmap devine à partir d'une table statique port-vers-nom. La version réelle est la clé d'entrée vers une CVE.
• -p- pour tout voir, -sU pour l'UDP. Les services les plus dangereux se cachent sur les ports hauts et en UDP, hors des 1000 ports scannés par défaut. Et en UDP, un open|filtered ne se tranche qu'avec la configuration : 6 sur 6 chez nous, pour un seul port réellement ouvert.
• Corrélation n'est pas exploitation. Un script NSE qui signale une version vulnérable produit une hypothèse, pas une preuve. La confirmation demande un pentest.
• Un scan ponctuel périme vite. Seule une surveillance continue attrape le port rouvert hier ou la version devenue vulnérable ce matin.

Savoir lire un scan de ports, c'est la compétence de base de la reconnaissance offensive, et c'est aussi la première ligne de défense. Si l'exercice vous a donné envie de vérifier ce que votre organisation expose vraiment, sans plage d'IP à fournir ni agent à installer, c'est ce que fait la plateforme EASM own2pwn en continu. Et si vous voulez qu'un humain aille prouver ce qu'un scan ne fait que suggérer, un pentest web en boîte noire reprend là où la reconnaissance s'arrête.

Questions fréquentes sur le scan de ports