Le scan de ports avec Nmap, dans un laboratoire autorisé

Une machine connectée est comparable à un immeuble doté de milliers de portes numérotées. Certaines sont ouvertes et mènent à un service : site web, partage de fichiers, accès à distance. Le scan de ports consiste à frapper à chaque porte pour savoir laquelle répond. Nmap est l'outil de référence pour le faire, et cette leçon vous en apprend les principes dans votre labo.

Ce que fait un scan de ports

Chaque service réseau écoute sur un port, un numéro entre 0 et 65535, associé à un protocole (TCP ou UDP). Un site web non chiffré écoute habituellement sur le port 80, un site chiffré sur le 443, un accès distant sécurisé sur le 22. Un scanner envoie des paquets vers ces ports et classe les réponses en trois états principaux :

• Ouvert : un service accepte la connexion ;
• Fermé : la machine répond qu'aucun service n'écoute (elle est donc bien là) ;
• Filtré : aucune réponse exploitable, souvent à cause d'un pare-feu qui ignore ou bloque les paquets.

La liste des ports ouverts est la surface d'attaque réseau de la machine : chaque service est un point d'entrée potentiel.

La découverte d'hôtes avant le scan

Dans un réseau, il faut d'abord savoir quelles machines sont actives. Nmap propose une phase de découverte dans laquelle il envoie différents types de paquets pour détecter les hôtes vivants. Dans votre labo, la commande suivante liste simplement les hôtes qui répondent, sans scanner leurs ports :

nmap -sn 192.168.56.0/24

Notez les adresses obtenues dans votre carnet et comparez-les à la liste du périmètre. Si une machine inattendue apparaît (par exemple une machine du réseau domestique), arrêtez : votre isolation est défaillante.

Un premier scan de ports

Sur une machine de votre labo, un scan simple vérifie les ports les plus courants :

nmap 192.168.56.20

La sortie ressemble à ceci (exemple illustratif) :

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
3306/tcp open mysql

Lecture : trois services sont à l'écoute. Un accès distant, un serveur web, et une base de données. Cette dernière ligne est intéressante : une base de données directement joignable depuis le réseau est rarement souhaitable. C'est une observation pour votre carnet et une piste à vérifier plus tard.

Les options qui comptent

Option	Effet	Quand l'utiliser
-p-	Scanne les 65535 ports TCP	Quand on veut être exhaustif (plus long)
-p 22,80,443	Scanne seulement les ports listés	Pour une vérification ciblée
-sV	Tente d'identifier le service et sa version	Pour préparer l'analyse de vulnérabilités
-sU	Scanne des ports UDP	Plus lent, mais certains services importants utilisent UDP
-O	Tente de deviner le système d'exploitation	Pour orienter la suite
-oN fichier	Enregistre le résultat dans un fichier	Toujours, pour vos preuves
-T2 à -T4	Ajuste la vitesse	Plus lent = plus discret et moins risqué pour une cible fragile

Une commande complète pour votre labo ressemblerait à :

nmap -sV -p- -T3 -oN 01-reconnaissance/scan-web.txt 192.168.56.20

Elle scanne tous les ports TCP, tente d'identifier les versions, adopte une vitesse modérée et sauvegarde le résultat dans le dossier de la mission.

Comprendre les types de scan

Nmap sait établir une connexion TCP complète (« connect scan ») ou n'envoyer que le premier paquet de la négociation (« SYN scan ») et observer la réponse sans terminer la connexion. Le second est plus rapide et laisse moins de traces dans certains journaux applicatifs, mais il nécessite des privilèges plus élevés sur votre machine d'attaque. Peu importe pour le débutant : l'important est de comprendre ce que l'on envoie et ce que l'on déduit de la réponse.

Il faut aussi savoir lire le contexte : un port « filtré » ne veut pas dire « vide ». Un pare-feu peut simplement avoir ignoré votre scan. Et un port « fermé » prouve que la machine est présente : c'est parfois suffisant pour savoir qu'elle existe.

Scanner avec discernement

Un scan est une activité bruyante : il génère des centaines de paquets que les systèmes de détection d'intrusion et les journaux enregistrent. En mission réelle :

• Le client sait que vous scannez et à quelle période ; les équipes de supervision peuvent aussi être prévenues ou non, selon ce qui a été convenu ;
• Vous adaptez la vitesse à la fragilité des systèmes (équipements industriels, anciens serveurs) ;
• Vous ne scannez que les adresses listées ;
• Vous conservez le journal complet de ce qui a été envoyé.

Dans votre labo, ces contraintes sont moindres, mais gardez les mêmes réflexes. Cela fait partie de l'apprentissage : on ne s'improvise pas professionnel le jour de la première mission.

Un mot sur les scans UDP et sur la vitesse

Le protocole UDP n'établit pas de connexion : il n'y a pas de « poignée de main » qui prouve qu'un service écoute. Un scan UDP est donc beaucoup plus lent et plus ambigu : l'absence de réponse peut signifier « ouvert » comme « filtré ». C'est pourtant sur UDP que fonctionnent des services importants (résolution de noms, supervision, synchronisation de l'heure). En pratique, on commence par TCP, puis on cible quelques ports UDP bien choisis plutôt que de tout scanner.

Quant à la vitesse, retenez un principe : plus vite n'est pas mieux. Un scan trop rapide peut saturer un petit équipement, déclencher des blocages automatiques ou produire des résultats faux (des paquets perdus font croire à des ports fermés). Mieux vaut un scan modéré, reproductible et bien documenté qu'un scan éclair dont vous ne pouvez pas garantir l'exactitude.

Interpréter les résultats

Un résultat de scan n'est qu'un point de départ. Posez-vous ces questions pour chaque port ouvert :

1. Ce service est-il attendu sur cette machine ? (Un serveur web qui expose aussi un partage de fichiers est suspect.)
2. Doit-il être accessible depuis ce point du réseau ? (Une base de données ouverte vers tous est rarement légitime.)
3. Le protocole est-il chiffré ? (Un service qui transmet des identifiants en clair est une faiblesse.)
4. Quelle version tourne ? (Nous y reviendrons dans la leçon suivante.)

À vous de jouer : le premier inventaire du labo

Dans votre labo isolé, avec une machine cible volontairement vulnérable démarrée, effectuez : (1) une découverte d'hôtes sur le réseau privé ; (2) un scan simple de la machine cible ; (3) un scan complet de ses ports TCP enregistré dans un fichier. Remplissez ensuite la fiche de la machine dans votre carnet : adresse, ports ouverts, services probables, et pour chaque port une phrase indiquant si sa présence est normale.

Voir une solution

Un enchaînement possible : nmap -sn 192.168.56.0/24, puis nmap 192.168.56.20, puis nmap -p- -oN 01-reconnaissance/scan-web.txt 192.168.56.20. La fiche indique par exemple : « 22/tcp ssh, normal pour l'administration ; 80/tcp http, attendu pour un serveur web ; 3306/tcp base de données, à vérifier car ne devrait pas être joignable depuis tout le réseau ».

Si le scan complet a révélé plus de ports que le scan simple, notez-le : cela illustre pourquoi un scan par défaut ne suffit pas.

La leçon suivante va un cran plus loin : une fois les ports ouverts identifiés, comment savoir précisément quel service et quelle version s'y trouvent ?