5 commandes pour tester un port avant d'accuser le réseau

Comment vérifier si un port est ouvert ? Ouvrez une connexion TCP vers l'hôte. Si elle s'établit, le port est ouvert. Si elle est refusée immédiatement, il est fermé. Si elle reste sans réponse jusqu'à l'expiration du délai, il est probablement filtré par un pare-feu. Sous Windows, la commande Test-NetConnection suffit. Sous Linux, la commande nc -zv fait le job. Cet article détaille cinq outils (Test-NetConnection, nc, curl, telnet et nmap), leurs sorties, leurs limites face à UDP et le cadre légal à respecter avant tout scan d'un port.

Ouvert, fermé, filtré : que dit réellement le réseau ?

Pour TCP, trois cas se présentent :

• Ouvert : un service écoute, l'hôte répond au SYN par un SYN/ACK, la connexion s'établit.
• Fermé : l'hôte est joignable mais rien n'écoute. Il répond par un RST, d'où le message « Connection refused », quasi instantané.
• Filtré : aucune réponse (paquet ignoré par un pare-feu) ou message ICMP d'interdiction. L'outil attend jusqu'à l'expiration du délai.

Il faut faire attention à 2 nuances dans l'interprétation des résultats. Cela dépend comment est configuré le pare-feux soit en mode DENY/DROP ou en mode REJECT.

Les deux modes de blocage du trafic par une règle de pare-feu (firewall) sont Deny (ou Drop) et Reject. Voici la différence fondamentale entre les deux :

• Deny / Drop (Bloquer discrètement) : Le pare-feu rejette le paquet de données et ne renvoie aucune réponse à l'émetteur. Pour la source, c'est comme si la cible n'existait pas ou ne répondait pas (cela provoque une expiration du délai de connexion ou timeout). C'est le mode le plus sécurisé pour masquer votre réseau face à des scans malveillants.
• Reject (Rejeter explicitement) : Le pare-feu bloque le paquet mais renvoie un message d'erreur à l'émetteur (généralement un message ICMP Destination Unreachable ou un paquet TCP RST). L'émetteur sait immédiatement que la connexion a été activement refusée, ce qui est utile pour le diagnostic en interne.

Scanme.nmap.org : une cible autorisée pour s’entraîner au scan de ports

scanme.nmap.org est un hôte de test mis à disposition par le projet Nmap (Insecure.Org) pour permettre à chacun de s’exercer au scan de ports sans risque juridique.

Sa démarche est pédagogique : plutôt que de pousser les débutants à tester leurs outils sur des machines tierces, ce qui peut être illégal ou déclencher des alertes de sécurité, le projet fournit une cible explicitement autorisée, maintenue à cet effet.

Le site invite ainsi à scanner ce serveur de manière raisonnable afin de découvrir le fonctionnement de Nmap : détection des ports ouverts, identification des services et des versions, détection du système d’exploitation.

Il s’accompagne d’une règle de bon sens : pas d’attaque, pas de scan agressif en continu, pas d’usage abusif. Les services exposés (SSH, HTTP, etc.) servent de support réaliste pour comprendre les résultats d’un scan et les interpréter. Plus largement, cette démarche rappelle un principe fondamental de la sécurité offensive : toujours disposer d’une autorisation explicite avant de tester un système.

Quelle commande Windows pour tester un port ?

Test-NetConnection (PowerShell)

C'est la commande Windows pour tester un port la plus directe, intégrée à PowerShell depuis Windows 8.1 / Server 2012 R2 (alias tnc).

Syntaxe :

Test-NetConnection -ComputerName  -Port 

Exemple reproductible :

Test-NetConnection -ComputerName scanme.nmap.org -Port 80

Sortie commentée (valeurs indicatives) :

ComputerName     : scanme.nmap.org
RemoteAddress    : 45.33.32.156
RemotePort       : 80
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.1.20
TcpTestSucceeded : True

TcpTestSucceeded est le seul champ décisif.

En cas d'échec, vous aurez False sur la ligne TcpTestSucceeded. Il n'est pas possible de savoir s'il est fermé ou filtré.

Cas d'usage : diagnostic rapide ou script, avec un résultat booléen :

Test-NetConnection -ComputerName scanme.nmap.org -Port 80 -InformationLevel Quiet

La commande ne teste que TCP, pas UDP

Quelle commande Linux pour tester un port ?

nc (netcat)

Paquet netcat-openbsd sous Debian/Ubuntu, nmap-ncat sous RHEL et dérivés.

Syntaxe :

nc -zv -w   

-z ouvre puis ferme la connexion sans envoyer de données, -v affiche le résultat, -w fixe le délai d'attente.

Exemple :

nc -zv -w 3 scanme.nmap.org 80
nc -zv -w 3 scanme.nmap.org 3389

Sortie commentée (Debian):

scanme.nmap.org [45.33.32.156] 80 (http) open
scanme.nmap.org [45.33.32.156] 3389 (ms-wbt-server) : Connection refused

Un port filtré donne Connection timed out ou Connection refused au bout de 3 secondes.

Interprétation : nc distingue clairement refus et délai dépassé. nc -z ne se contente pas de teser le port : il réalise la poignée de main TCP complète, puis ferme sans rien envoyer. Le service voit donc une connexion éphémère, que ses journaux ou une sonde de détection peuvent enregistrer. Les messages varient selon l'implémentation (OpenBSD, ncat, netcat traditionnel)

Cas d'usage : test polyvalent. L'option -u permet aussi de sonder UDP, mais la prudence s'impose : UDP n'ayant pas de poignée de main, nc conclut à un succès dès qu'aucune erreur ICMP ne revient, y compris pour un port filtré ou un service muet (voir la section dédiée).

curl

Utile quand le service testé est applicatif (HTTP, HTTPS) ou quand telnet n'est pas installé.

Exemple :

curl -sSv -o /dev/null --connect-timeout 5 https://example.com:443/

Sous Windows 11, utilisez curl.exe et -o NUL : dans Windows PowerShell 5.1, curl est un alias d'Invoke-WebRequest.

Interprétation : le code 7 indique un port fermé, le 28 un port probablement filtré. Un port ouvert suivi d'une erreur TLS ou HTTP prouve que la couche TCP fonctionne.

Cas d'usage : séparer un problème réseau d'un problème applicatif. Pour un protocole non HTTP, curl -v telnet://<hôte>:<port> ouvre une connexion brute, mais elle reste en attente : ajoutez --max-time.

Ce que veut dire chaque paramètre :

• curl : l’outil de transfert, qui sait parler HTTP, FTP, SMTP et d’autres protocoles.
• -v (verbose) : affiche les étapes de la connexion (résolution DNS, tentative de connexion, résultat). C’est ce qui permet de lire si le port est ouvert.
• telnet:// : indique à curl de ne pas parler HTTP. Il ouvre une connexion TCP vers l’hôte et le port, puis la laisse ouverte comme une session texte. Curl n’a donc pas besoin du client telnet, qui est souvent absent.
• hôte:port : utiliser une IP ou un domaine. Par exemple scanme.nmap.org:3389.

telnet

Le client est absent par défaut. Sous Windows, activez-le avec la commande dism /online /Enable-Feature /FeatureName:TelnetClient (invite administrateur). Sous Linux, installez le paquet telnet.

Exemple :

telnet scanme.nmap.org 80

Sortie commentée : sous Linux, Connected to scanme.nmap.org. suivi de Escape character is '^]'. signale un port ouvert. Sous Windows, l'écran se vide, sans message. Un refus affiche Connection refused (Linux) ou Could not open connection to the host, on port 80: Connect failed (Windows).

nmap

C'est l'outil de référence pour le scan d'un port ou d'une plage.

Exemple :

nmap -Pn -p 22,80 --reason scanme.nmap.org

-Pn évite la phase de découverte, souvent bloquée par les pare-feu.

Sortie commentée (schématique) :

PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack
80/tcp open  http    syn-ack

STATE donne l'état, REASON la preuve réseau : syn-ack (ouvert), reset ou conn-refused (fermé), no-response (filtré).

Interprétation : nmap est le seul outil de la liste qui distingue explicitement open, closed et filtered. Avec les droits root, il utilise par défaut un scan SYN, qui n'achève pas la poignée de main ; sans ces droits, il établit une connexion complète (-sT).

Cas d'usage : audit de vos propres serveurs, plages de ports et, avec -sU, scan UDP.

Quelle commande choisir selon la situation ?

Ma recommandation : Test-NetConnection sous Windows, nc -zv sous Linux dans la plupart des cas, nmap pour des états précis ou plusieurs ports.

Comment tester un port UDP sous Windows ?

UDP n'a pas de poignée de main (handshake): l'état d'un port se déduit uniquement de ce qui revient après l'envoi d'un datagramme.

• Une réponse du service : le port est ouvert.
• Un message ICMP « port unreachable » : le port est fermé.
• Rien : le port est ouvert ou filtré, sans moyen de trancher.

Un service qui ignore les datagrammes vides ou mal formés reste muet même ouvert, et un pare-feu qui supprime l'ICMP masque les ports fermés. C'est pourquoi nc -zvu annonce un succès dès qu'aucune erreur ICMP ne revient, ports filtrés compris, et pourquoi nmap affiche open|filtered.

Sous Linux, envoyez une vraie requête applicative, ou laissez nmap interpréter les réponses :

dig @8.8.8.8 example.com +time=3 +tries=1
sudo nmap -sU -sV -Pn -p 53 

-sV envoie des sondes propres à chaque service et peut lever l'ambiguïté open|filtered. Côté serveur, ss -ulnp liste les sockets UDP en écoute.

Sous Windows, Test-NetConnection ne gère que TCP. Il reste le .NET depuis PowerShell : la fonction suivante envoie un datagramme et interprète le résultat.

Le script exploite le comportement de la pile réseau face à un datagramme UDP. UDP n’ayant ni connexion ni accusé de réception, l’état du port se déduit uniquement de ce qui revient (ou non) après l’envoi.

Déroulement d’un test

1. Création du socket : un UdpClient est ouvert, avec un port source éphémère ou imposé par -PortSource.
2. Connect : en UDP, cet appel ne génère aucun trafic. Il associe simplement le socket à l’hôte et au port cibles. Cette association est indispensable : sans elle, Windows ne remonte pas les erreurs ICMP au programme.
3. Envoi : le datagramme part avec la charge utile choisie (requête DNS, NTP, SNMP ou texte).
4. Attente : Receive bloque jusqu’à TimeoutMs.
5. Analyse : trois issues possibles.

Les trois issues

• Un datagramme revient : un service écoute et a répondu. État Ouvert.
• L’hôte renvoie un ICMP « port unreachable » : le noyau de la cible n’a aucun service sur ce port. Windows convertit ce message en exception SocketException (ConnectionReset) à l’appel suivant sur le socket. État Fermé.
• Rien ne revient avant le timeout : l’exception est TimedOut, et le script réessaie. Après la dernière tentative, l’état est Ouvert|Filtré.

Pourquoi plusieurs tentatives

L’ICMP est remonté de façon asynchrone : l’erreur apparaît sur l’opération suivante du socket, pas toujours sur le premier Receive. Renvoyer le datagramme augmente donc les chances de détecter un port fermé. Cela compense aussi la perte éventuelle d’un paquet UDP.

Pourquoi une charge utile valide

Un service UDP ignore silencieusement un paquet qui ne respecte pas son protocole. Un résolveur DNS ne répondra pas à test. Envoyer une vraie requête transforme un port ouvert mais muet (état indéterminé) en port ouvert avec réponse (état certain).

Limites du mécanisme

• Un pare-feu qui élimine les paquets (drop) ou bloque l’ICMP rend « Fermé » invisible : le résultat sera « Ouvert|Filtré ».
• Un service qui reçoit un paquet qu’il ne comprend pas ne répond pas : « Ouvert|Filtré » également.
• Seule une capture côté serveur (Wireshark, tcpdump) lève le doute.

Le scan d'un port est-il légal ?

Tester un port de vos propres systèmes, ou avec l'autorisation écrite du propriétaire, ne pose pas de difficulté. Sur un système tiers, la situation est plus délicate : en France, les articles 323-1 à 323-3 du Code pénal sanctionnent l'accès ou le maintien frauduleux dans un système de traitement automatisé de données.

Un simple test de connexion n'est pas en soi un accès, mais le contexte et l'intention comptent. Ce point relève de l'interprétation juridique, pas d'un avis de juriste : en cas de doute, obtenez une autorisation écrite. Le projet nmap détaille ces enjeux et met scanme.nmap.org à disposition pour s'entraîner.

timeout 3 bash -c '</dev/tcp/scanme.nmap.org/80' && echo ouvert || echo fermé_ou_filtré

Conclusion : prouver où la connexion échoue

Avant d'accuser le réseau, prouvez où la connexion échoue : c'est l'ordre des vérifications, plus que la commande, qui fait gagner du temps.

1. Résolution DNS : l'hôte pointe-t-il vers la bonne adresse ?
2. Écoute locale : le service écoute-t-il sur la bonne interface ?
3. Refus ou silence : un refus désigne l'hôte, un silence le chemin réseau.
4. Test applicatif : une fois le port ouvert, validez le protocole.