Scan de ports : lire le résultat, pas réciter
la commande

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. Toutes les sorties ci-dessous sont réelles, prises dans la session d'écriture sur des cibles autorisées.

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 (45.33.32.156)
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. Ce n'est pas rien : 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. Confondre les deux, c'est passer à côté du renseignement.

Restent les deux ports open : 22 et 80. Un service écoute, il accepte les connexions, il est joignable depuis Internet. C'est exactement le périmètre qu'un attaquant énumère en premier, et c'est là que la détection de version (colonne VERSION) change tout. 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.

  open            un service accepte les connexions sur ce port
  closed          le port répond, mais aucun service n'écoute
  filtered        un pare-feu bloque la sonde, l'état reste inconnu
  unfiltered      le port est joignable, ouvert ou fermé indéterminé
  open|filtered   nmap ne peut trancher entre ouvert et filtré (fréquent en UDP)
  closed|filtered nmap ne peut trancher entre fermé et filtré

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.

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

Maintenant la mécanique. 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. C'est toute la différence entre lister des numéros et savoir ce qui écoute, et c'est aussi 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 dix 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, le Redis sans authentification. 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 exactement 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, tient en un mot : 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, exactement 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.

  graine (domaine)
       |
       v
  découverte des sous-domaines  ->  scan de ports + versions
       |                                   |
       |                                   v
       |                          corrélation CVE (bannière/version)
       v                                   |
  comparaison au scan précédent  <---------+
       |
       v
  DELTA : nouveau port ouvert, version qui change, finding résolu

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

• 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.
• 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 précisément 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 exactement là où la reconnaissance s'arrête.

Questions fréquentes sur le scan de ports