Scans des ports TCP et UDP avec Nmap

I. Présentation

Dans ce chapitre, nous apprendrons à faire nos premiers scans de port grâce à l’outil de scan réseau Nmap. Nous verrons comment l’utiliser pour dresser une liste des services réseau exposés sur un hôte, qu’ils utilisent les protocoles TCP ou UDP.

N’oubliez pas, à partir d’ici, de ne scanner que des hôtes dans un environnement maîtrisé et pour lequel vous disposez d’une autorisation explicite.

• Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

Si vous n’en avez pas sous la main, je vous oriente vers les solutions gratuites suivantes, qui sont faites pour !

• Hack The Box : Plateforme d’entraînement au hacking, Hack The Box met constamment à disposition des systèmes vulnérables que vous pourrez attaquer comme bon vous semble. Plusieurs centaines de systèmes sont disponibles, mais un pool renouvelé de 20 machines est proposé gratuitement toute l’année, l’accès se fait via un VPN OpenVPN.
• Vulnhub : Cette plateforme propose en téléchargement de nombreux systèmes intentionnellement vulnérables qu’il est possible d’utiliser via VirtualBox (solution gratuite elle aussi) ou autre. Une fois téléchargé, pas besoin de VPN, tout est en local.

Également, vous êtes libre de vous créer une machine virtuelle sur votre système d’exploitation préféré et d’y installer divers services afin qu’ils vous servent de cibles de test. L’avantage ici sera que vous pourrez également voir ce qu’il se passe côté serveur lors d’un scan, notamment avec Wireshark, et aurez la main sur le pare-feu local quand nous ferons des tests plus avancés.

Place à la pratique !

II. Scanner les ports TCP d'un hôte via Nmap

A. Premier scan de port TCP avec Nmap

Nous allons maintenant effectuer nos premiers scans via Nmap. Notre objectif ici est simple, nous souhaitons découvrir quels sont les services exposés par le serveur web que nous venons de déployer, histoire de voir s’il n’y a rien d’inattendu, à tout hasard un service d’administration qui ne devrait pas être accessible, ou l’exposition d’un port d’une application qui nous pensions décomissionnée.

Dans mon exemple suivant, l’hôte à scanner possède l’adresse IP “192.168.1.18” :

nmap 192.168.1.18

Voici un résultat possible, nous y voyons un retour tout à fait classique de Nmap avec de nombreuses informations :

En jetant un œil rapide à ce résultat, nous comprenons que les ports TCP/22 et TCP/80 sont accessibles sur cet hôte.

Par défaut et si on ne lui dit rien à ce sujet, Nmap va effectuer uniquement des scans sur les ports TCP.

B. Comprendre le résultat d’un scan Nmap simple

Allons néanmoins plus loin sur la compréhension de cette sortie, chaque ligne à son importance, déjà pour savoir ce qui vient d’être fait, et ensuite pour bien interpréter les résultats du scan en lui-même.

La première ligne est essentiellement un rappel de la version et date du scan (utiles pour les traces et l’archivage tout de même !) :

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-04-29 21:59 CEST

La seconde ligne nous indique le début des résultats de scan concernant l’hôte “debian.home (192.168.1.19)”. Information qui nous sera utile lorsque l’on commencera à scanner plusieurs hôtes en même temps :

Nmap scan report for debian.home (192.168.1.19)

La troisième ligne nous indique que l’hôte en question en bien “Up”, c’est-à-dire actif :

Host is up (0.00022s latency).

Enfin, Nmap nous informe que 998 ports TCP identifiés comme fermés ne sont pas affichés dans la sortie :

Not shown: 998 closed tcp ports (conn-refused)

Il nous évite ainsi près de 1000 lignes de résultat ressemblant à :

1/tcp closed
2/tcp closed
3/tcp closed
…

Merci à lui de nous épargner cela !

Pourquoi 998 ports “closed” ? Si l’on ajoute les 2 ports ouverts cela fait 1000, et c’est le nombre de ports que Nmap va scanner dans sa configuration par défaut, il ne scanne pas les 65535 ports TCP existants ! Nous verrons plus tard que cela est entièrement et facilement personnalisable. Mais si l’hôte ciblé possède un service en écoute sur un port un peu exotique, ce scan “par défaut” ne permettra pas de le découvrir.

À la suite de ces différentes informations, nous retrouvons ce qui est le plus intéressant, un tableau organisé selon les trois colonnes “PORT – STATE – SERVICE” :

• La première colonne “PORT” indique simplement le port/protocole ciblé, il est ici important de regarder s’il s’agit d’un port TCP (“<port>/tcp”) ou de l’UDP (“<port>/udp”).
• La colonne “STATE” indique le statut du service réseau découvert sur ce port et déterminé par Nmap en fonction de la réponse obtenue. Il peut bien sûr être “open” (ouvert), “closed” (fermé), mais aussi “filtered” (filtré) ou “unknown” (inconnu). Nous verrons notamment plus tard comment Nmap fait pour distinguer ces différents états.
• La colonne “SERVICE” indique le service exposé sur le port en question. Attention toutefois, nous n’avons ici pas utilisé d’options relatives à la découverte active des services. Nmap se base alors sur une référence locale entre un port/protocole et le service supposément assigné : le fichier “/etc/services”

Si l’on jette un oeil au fichier “/etc/services” sur un système Linux, on retrouve un lien “port/protocole – service” similaire à celui affiché par Nmap :

Il faut bien comprendre que, pour l’instant, Nmap n’a pas fait de découverte active de service. Ainsi, il aurait été incapable d’identifier le service SSH derrière un port TCP/80 si tel avait été le cas. D’où l’importance de savoir utiliser les bonnes options, cela va venir !

Savoir bien interpréter la sortie de Nmap est très important pour bien maîtriser l’outil. La bonne nouvelle, c’est que cette sortie sera en grande partie la même, quelles que soient les options utilisées.

C. Regardons sous le capot : analyse réseau via Wireshark

Si l’on regarde attentivement ce qu’il se passe sur l’interface réseau de l’hôte qui scanne le serveur ou sur celle du serveur lui -même, les actions de Nmap seront beaucoup plus claires. C’est ce que nous allons faire ici.

Ce que je peux vous montrer ici est une partie de ce qui est visible dans Wireshark. Pour aller plus loin, n’hésitez pas à faire vous-même une capture réseau lors d’un scan pour parcourir ensuite ce qui a été capturé.

Dans le cadre de ce test, mon hôte de scan (192.168.1.18) et mon hôte cible (192.168.1.19) sont sur le même réseau local.

Nmap commence par chercher à savoir si l’hôte cible est actif sur le réseau local en émettant une requête ARP. En cas de réponse, il sait alors que l’hôte est actif et commence son scan réseau :

Si l’hôte à scanner est sur un réseau distant, Nmap commence par émettre un ping request et tente de joindre quelques ports très fréquemment exposés (TCP/80, TCP/443) :

S’il obtient une réponse à l’un de ces différents essais, il considère la cible comme active.

Une fois que Nmap a déterminé que sa cible était belle et bien active, il va chercher à résoudre son nom de domaine auprès du serveur DNS configuré sur la carte réseau, c’est vrai que l’on ne lui a pas demandé de ne pas le faire :

Maintenant que Nmap a bien identifié sa cible et qu’il l’a sait active, il commence à faire son scan de port TCP :

Il va pour cela, sur chaque port TCP faisant partie de son range par défaut, envoyer des paquets TCP SYN et attendre une réponse. Sur la capture ci-dessus, il reçoit de la part du serveur scanné des paquets TCP RST/ACK signifiant “circulez, il n’y a rien à voir”, autrement dit, ces ports sont fermés. Ce sera, nous l’avons vu dans le résultat, le cas de la plupart des ports scannés. Ceci à l’exception de deux :

Sur la capture ci-dessus, nous voyons un paquet TCP SYN/ACK envoyé par l’hôte ciblé. Le port est actif et expose bien un service. Nmap acquiesce alors la réception de la réponse, puis met fin à la connexion (TCP RST/ACK). Voilà comment il a su que le port TCP/22 était actif.

Nous avons vu ici que Nmap respecte bien le “Three Way Handshake” lors de son scan réseau TCP. Pour des raisons de performance, il est possible de lui demander de ne pas répondre au retour du serveur, faisant alors l’économie de plusieurs milliers de paquets lors du scan d’un large réseau. Mais, nous verrons ces options et optimisations plus tard dans le cours.

Nous avons à présent une meilleure idée de comment faire un scan TCP et de ce qu’il se passe réellement quand il est opéré. Nous avons également vu que par défaut, Nmap effectue un scan de port TCP sur un nombre limité de ports.

III.Scanner les ports UDP avec Nmap

A. Premier scan de port UDP avec Nmap

À présent, nous allons voir comment réaliser un scan sur les ports UDP d’un hôte. Comme nous l’avons vu, Nmap va par défaut toujours effectuer des scans sur des ports TCP. Cela peut nous faire passer à côté de pas mal d’informations si nous ne le savons pas.

Pour rappel, dans le cadre de ce test, mon hôte de scan (192.168.1.18) et mon hôte cible (192.168.1.19) sont sur le même réseau local.

nmap -sU 192.168.1.19

Ici, le retour obtenu a le même format que pour un scan TCP, les services actifs affichés sont cependant en “<port>/UDP”, comme demandé !

C’est l’option “-sU” qui permet d’indiquer à Nmap que l’on veut travailler sur de l’UDP, et non du TCP comme c’est le cas par défaut.

Au passage, vous remarquerez sûrement que Nmap nécessite les droits “root” pour les scans UDP, comme mentionné précédemment dans le cours.

Les scans UDP peuvent être très longs (1100 secondes pour scanner 1000 ports dans mon exemple), cela en raison de l’absence du “Three Way Handshake” en UDP, qui fait que Nmap attendra un retour pour chaque paquet UDP envoyé et qu’il déterminera le port comme “closed” uniquement s’il n’a pas de retour au bout d’un certain temps (timeout). Cette réponse des hôtes scannés n’étant d’ailleurs pas systématique et souvent limitée en termes de nombre de réponses par seconde pour éviter certaines attaques par amplification. Cela au contraire du TCP où il y a une réponse immédiate de l’hôte scanné, que le port soit ouvert ou fermé. Nous verrons plus tard comment optimiser cela.

Une deuxième difficulté en UDP est que les services ne répondent pas systématiquement à la réception d’un paquet, tout simplement, car ce n’est pas toujours nécessaire et que c’est le principe de l’UDP. Lorsque c’est le cas et qu’aucun ICMP “port unreachable” n’est reçu, le service est marqué comme “open|filtered” par Nmap, comme présent dans la capture ci-dessus.

B. Regardons sous le capot : analyse réseau via Wireshark

Comme lors de notre scan TCP, regardons de plus près ce qu’il se passe au niveau réseau lors d’un scan UDP via une analyse Wireshark. Le comportement de Nmap pour déterminer si un hôte est actif est le même.

La seule vraie différence lors d’un scan UDP est que Nmap n’attendra pas un “Three Way Handshake”, puisque ce mécanisme n’existe pas en UDP (protocole sans état) :

Nous voyons sur la capture ci-dessus que Nmap va émettre un grand nombre de paquets UDP, et recevoir pour la plupart d’entre eux un paquet ICMP “Destination unreachable (Port unreachable)” en réponse. C’est normal, puisqu’il s’agit de la réponse appropriée et définie par le RFC 1122 lorsqu’un port UDP n’est pas joignable :

Regardons de plus près cette capture Wireshark, qui expose les trois cas de figure possibles en UDP :

Ces trois cas de figure sont les suivants :

• Le premier échange est composé des paquets n°3, 4 et 8, 9. Nmap envoie des paquets UDP sur le port SNMP classique et construit donc à l’avance des paquets conformes à ce protocole. Il obtient ensuite une réponse du serveur (paquets n°8 et 9). Résultat : Nmap a eu une réponse, le service est bien actif (“open”).
• Le second échange est composé des paquets n°6 et 7. Nmap envoi un paquet UDP “vide” (sans structure relative à un protocole précis) à destination du port UDP/165 et reçoit en réponse un paquet ICMP “Destination unreachable (Port unreachable)”. Résultat : Nmap a eu une réponse (négative), l’hôte est bien up, mais le service qu’il a essayé de joindre n’est pas opérationnel sur ce port, celui-ci sera marqué en fermé (“closed”).
• Le dernier échange est composé du paquet n°12 : Nmap envoi un paquet UDP “vide” à destination du port UDP/1235. Il n’a aucune réponse, même pas un refus explicite de la part de l’hôte scanné. Résultat : Nmap marque le port en “open|filtered” car il est incapable de dire s’il s’agit d’une absence de réponse due à la présence d’un pare-feu, configuré pour ne rien répondre, ou à un service UDP actif qui ne renvoie aucune réponse de toute façon (non obligatoire en UDP).

Voici donc le résultat affiché par Nmap suite à ces trois cas de figure :

Nous avons à présent une meilleure idée de comment faire un scan UDP et de ce qu’il se passe réellement quand il est opéré. Pour l’instant nous n’avons fait qu’utiliser Nmap très simplement, sans vraiment d’options et sans vraiment décider des ports à scanner, mais cela va bientôt changer !

IV. Maitriser finement les ports scannés via Nmap

A. Rappel du comportement par défaut de Nmap

Comme nous l’avons vu, Nmap choisit lui-même le nombre et les ports à scanner si l’on ne lui spécifie pas d’options. Il s’agit là d’une configuration “par défaut” utilisée par Nmap lorsque l’on ne lui indique pas exactement quoi faire. Ces options par défaut sont faites pour avoir une idée des principaux ports exposés, ceux-ci étant sélectionnés par fréquence d’exposition (ports les plus communs ou fréquents) plutôt que dans un ordre numérique (port 1, 2, 3, etc.) et également pour éviter de partir sur un scan des 65535 ports possibles si l’on ne spécifie pas les options appropriées, ce qui serait trop long et verbeux pour un cas d’utilisation “par défaut”.

Comment sont choisis ces ports ?

Les 1000 ports scannés dans le mode par défaut sont choisis en fonction de leur fréquence d’apparition. Il s’agit de statistiques maintenues par Nmap et mises à jour au même titre que le binaire lui-même et de ses scripts (modules). Vous pouvez vous-même consulter ces statistiques dans le fichier “/usr/shares/nmap/nmap-services” :

Nous voyons ici dans la troisième colonne ce qui s’apparente à des probabilités (entre 0 et 1) ou une répartition en pourcentage. Il s’agit de la fréquence d’apparition de chaque couple port/protocole. Nous voyons alors que les ports les plus connus (FTP, SSH, TELNET et SMTP dans cet extrait) ont une valeur bien supérieure aux autres.

B. Spécifier précisément les ports cibles d’un scan Nmap

Néanmoins dans la réalité, nous pouvons avoir besoin de scanner uniquement un port précis, ou plusieurs, ou un range de port bien identifié. Cela tombe bien, Nmap nous permet très facilement de faire cela, de manière uniforme qu’il s’agisse d’un scan UDP ou TCP.

Scanner un port spécifique via Nmap

Si nous souhaitons scanner un seul port, et non pas 1000, nous pouvons spécifier ce port via l’option “-p” ou “--port” de Nmap :

# Scanner un seul port TCP via Nmap
nmap 192.168.1.19 -p 80

# Scanner un seul port UDP via Nmap
nmap -sU 192.168.1.19 -p 161

Dès lors, le scan sera naturellement beaucoup plus rapide et Nmap n’émettra que les paquets nécessaires pour détecter si l’hôte est actif, puis si le port spécifié est joignable. Voilà qui nous fera gagner du temps si l’on veut juste réaliser un test rapide, histoire de voir si le service web de notre site vitrine est toujours up.

Scanner plusieurs ports via Nmap

De la même manière, nous pouvons spécifier plusieurs ports à Nmap, cela à l’aide de la même option et en enchaînant les ports spécifiés par une virgule :

# Scanner plusieurs ports TCP via Nmap
nmap 192.168.1.19 -p 80,10999,22,23,1345

# Scanner plusieurs ports UDP via Nmap
nmap -sU 192.168.1.19 -p 161,23,69

Peu importe l’ordre, Nmap vérifiera tous ces ports, et uniquement ceux-ci sur l’hôte ciblé. Vous remarquerez dans le résultat affiché par Nmap que celui-ci nous indique explicitement tous les ports et leur état, même s’ils sont “closed”. À l’inverse du comportement par défaut où cette sortie complète aurait pris beaucoup trop de place :

Scanner un range de ports

Si le nombre de ports que l’on souhaite scanner est trop grand, il est possible de les spécifier par fourchette, par exemple :

# Scanner les ports TCP de 1000 à 2000 via Nmap
nmap 192.168.1.19 -p 1000-2000

# Scanner les ports UDP de 1000 à 2000 via Nmap
nmap -sU 192.168.1.19 -p 100-150

Il est bien sûr possible de mixer un peu tout cela comme bon vous semble, par exemple :

# Scanner les ports TCP 22,80, 3389 et de 1000 à 2000 via Nmap
nmap 192.168.1.19 -p 22,80,1000-2000,3389

Scanner de ports en TCP et UDP

Vous pouvez également très bien réaliser des scans en UDP et TCP en même temps, sur des ports bien choisis :

# Scanner liste des 1000 ports par défaut, en TCP et UDP
sudo nmap 192.168.1.19 -sT -sU

# Scanner les ports UDP/161 et TCP/22 uniquement
sudo nmap 192.168.1.19 -sT -sU -p U:161,T:22

Vous remarquerez dans ce dernier exemple la présence des “U:” pour indiquer un port UDP et “T:” pour indiquer un port TCP. Voici une sortie possible de ce type de scan :

Voilà qui commence à être intéressant en termes de personnalisation des scans !

Scanner tous les ports

Pour finir, il est possible d’indiquer à Nmap des ranges beaucoup plus grands, ou au contraire plus petits. Nous avons vu que la liste par défaut sélectionnée par Nmap contient 1000 ports. Nous pouvons très bien lui demander le top 100 des ports les plus fréquents, ou le top 200, cela en utilisant l’option “--top-ports” :

# Scanner les 100 ports les plus fréquents via Nmap
nmap 192.168.1.19 --top-ports 100

# Scanner les 200 ports les plus fréquents via Nmap
nmap 192.168.1.19 --top-ports 200

Et enfin, nous pouvons lui demander de scanner tous les ports possibles (les 65535), cela avec la notation “-p-” :

# Scanner les ports TCP 22,80, 3389 et de 1000 a 2000 via Nmap
nmap 192.168.1.19 -p-

Ce dernier cas de figure prendra certes plus de temps, notamment en UDP, mais vous serez alors certains de ne passer à côté d’aucun port ouvert.

Plus tard dans le cours, nous verrons comment optimiser la vitesse des scans Nmap en fonction de nos besoins, ce qui sera notamment utile aux scans sur l’intégralité des ports en TCP et UDP.

V. Conclusion

Dans ce chapitre, nous avons enfin fait un peu de pratique, nous savons à présent utiliser Nmap de façon basique pour scanner les ports TCP et UDP d’un hôte. Nous avons également regardé en détail ce qu’il se passe au niveau réseau et comment Nmap détermine si un port TCP ou UDP est actif ou non. Enfin, nous savons comment sélectionner finement les ports que nous souhaitons scanner et ce que font vraiment les options par défaut de Nmap. Dans le prochain chapitre, nous réutiliserons ces connaissances et les appliquerons au scan d’un réseau tout entier, notamment pour effectuer une cartographie globale et découverte d’un réseau.