15/11/2024

Les scans de port via TCP : SYN, Connect et FIN

I. Présentation

Dans ce chapitre et le suivant , nous allons étudier plus en profondeur les différents types de scan TCP qui sont disponibles dans Nmap, en commençant par les plus utilisés qui sont les scans SYN, Connect et FIN.

Vous l’aurez peut-être remarqué, mais Nmap propose plusieurs options en ce qui concerne les scans TCP :

Techniques de scan disponibles dans Nmap.
Techniques de scan disponibles dans Nmap.

L'idée est donc d'expliquer certaines de ces méthodes afin de comprendre leur différence, leur intérêt et leur limite. Ainsi, vous verrez qu’en fonction des contextes ou de ce que l’on souhaite savoir, il vaut mieux opter pour une option ou pour un autre.

II. Le TCP SYN scan ou "Half Open scan"

Le premier type de scan TCP que nous allons voir est le TCP SYN Scan,aussi appelé Half Open Scan (signifiant "à moitié ouvert"). Si vous vous rappelez des analyses réseau faites à la suite de nos premiers scans de port dans le chapitre 2 du module 2, il s’agit du type de scan utilisé par défaut par Nmap lorsqu’il est exécuté avec les droits root”.

La traduction aide bien à comprendre le fonctionnement de ce scan. En effet, un TCP SYN scan va envoyer sur chaque port ciblé un paquet TCP SYN, qui est donc le premier paquet qu'envoie un client (celui qui demande à établir une connexion) dans le cadre du fameux Three way handshake TCP. En temps normal, si le port est ouvert sur le serveur cible avec un service tournant derrière, celui-ci va renvoyer un paquet TCP SYN/ACK permettant de valider la SYN du client et d'initialiser la connexion TCP. Cette réponse prend la forme d’un paquet TCP avec les flags SYN et ACK à 1, on pourra alors affirmer que le port est ouvert et mène à un service.

En revanche, si le port est fermé, le serveur nous renverra un paquet TCP avec les flags RST et ACK à 1 pour mettre fin à la demande de connexion, on saura alors qu'aucun service ne semble être actif derrière ce port :

Schéma des comportements lors d'un TCP SYN Scan pour un port ouvert et fermé.
Schéma des comportements lors d'un TCP SYN Scan pour un port ouvert et fermé.

Pour avoir une vue plus concrète du TCP SYN Scan, j'ai effectué un scan du port TCP/80 vers un hôte qui avait un serveur web actif sur ce port. En effectuant une analyse réseau avec Wireshark, nous pouvons voir le flux suivant (source de scan : “10.10.14.84”) :

Capture réseau lors d'un TCP SYN scan pour un port ouvert.
Capture réseau lors d'un TCP SYN scan pour un port ouvert.

Nous voyons sur la première ligne que la source du scan envoie un paquet TCP à l’hôte 10.10.10.203” sur le port TCP/80. Dans ce paquet TCP, le flag SYN est à 1 pour signifier qu’il s’agit d’une demande d’initialisation de connexion TCP.

Nous voyons ensuite sur la deuxième ligne que la cible répond avec un TCP SYN/ACK, ce qui veut dire qu'il accepte d'initialiser une connexion et donc de recevoir des flux sur le port TCP/80. On peut donc en déduire que le port TCP/80 est ouvert et qu'un serveur web est bien présent sur le serveur scanné.

Notre hôte renvoie ensuite un paquet RST pour fermer la connexion, cela permet à l’hôte scanné de ne pas maintenir une connexion TCP ouverte en attente de réponse. Dans le cas d’un scan sur de nombreux ports, ne pas fermer les connexions TCP pourrait mener à un déni de service, saturant le nombre de connexion en attente de réponse que le serveur peut maintenir (voir Wikipedia – Syn flood)

Vous pourrez voir plus précisément dans Wireshark, pour chaque test que nous allons faire, l’état des flags TCP. Cela afin de savoir s’il s’agit d’un paquet SYN, SYN/ACK, ACK, etc :

Visualisation des flags TCP d’un paquet dans Wireshark (TCP SYN ici).
Visualisation des flags TCP d’un paquet dans Wireshark (TCP SYN ici).

À l'inverse, j'ai effectué le même test entre les deux machines, mais cette fois-ci en scannant un port TCP/81 sur lequel aucun service n'est actif (source de scan : “10.10.14.84”) :

Capture réseau lors d'un TCP SYN scan pour un port fermé.
Capture réseau lors d'un TCP SYN scan pour un port fermé.

L’hôte scanné renvoie un TCP RST/ACK en réponse à mon TCP SYN lorsque le port n'est pas ouvert.

Comme indiqué, lorsque vous exécutez Nmap depuis un terminal privilégié, le TCP SYN Scan est le mode par défaut, il peut être forcé via l’option "-sS" (scan SYN) :

# Exécution d’un TCP Syn Scan
nmap -sS 192.168.1.15

Le TCP SYN Scan est le scan le plus couramment utilisé pour des questions de rapidité. En revanche, l’absence de finalisation du Three Way Handshake par un client (pas d’envoi du ACK après le SYN/ACK serveur) peut paraître suspecte si elle est observée trop de fois sur un serveur ou depuis une même source sur le réseau. En effet, le comportement normal d'un client après réception d’un paquet TCP SYN/ACK en réponse à un TCP SYN est d’envoyer un acknowledgement (ACK) pour ensuite commencer l'échange.

Néanmoins, cela permet d'avoir un scan un peu plus rapide, car il ne s'encombre pas à envoyer un ACK à chaque réponse positive. L'avantage du SYN Scan est donc sa rapidité, car un seul paquet est envoyé par port à scanner, cela au détriment d’une plus grande chance de détection.

De plus, le TCP SYN scan est capable de détecter si un port est filtré (protégé) par un pare-feu. En effet, un pare-feu devant l'hôte visé peut être détecté via le comportement qu'il a lorsqu'il reçoit un paquet TCP SYN sur un port qu'il est censé protéger. Celui-ci ne va tout simplement pas répondre. Or nous avons vu que dans les deux cas (port ouvert ou port fermé), il y a une réponse de l'hôte. Ce troisième comportement va alors révéler la présence d'un pare-feu entre l'hôte scanné et la machine qui lance le scan. Voici le résultat que Nmap peut nous retourner lorsqu'un port scanné est filtré par un pare-feu :

Affichage Nmap lors du scan d'un port filtré.
Affichage Nmap lors du scan d'un port filtré.

Lorsque l'on effectue une capture réseau au moment du scan, nous pouvons effectivement voir qu'aucune réponse n'est donnée :

Capture réseau lors d'un TCP SYN scan pour un port filtré par un pare-feu.

La différence entre un port fermé et un port filtré est la suivante : un port filtré est un port protégé par un pare-feu alors qu'un port fermé est un port sur lequel aucun service ne tourne et qui est donc incapable de traiter nos paquets TCP. Certains types de scan TCP comme le TCP SYN scan sont capables de détecter si un port est filtré alors que d'autres types de scan ne le peuvent pas.

III. Le TCP Connect scan ou "Full Open scan"

Le second type de scan TCP est le TCP Connect scan, aussi nommé Full Open Scan. Il reprend le même fonctionnement que le TCP SYN scan, mais cette fois-ci en renvoyant un TCP ACK après une réponse positive du serveur (un SYN/ACK). C'est pourquoi il est nommé "Full Open", car l'on ouvre et initie complètement la connexion sur chaque port ouvert lors du scan, respectant ainsi le Three Way Handshake TCP :

Schéma des comportements lors d'un TCP Connect Scan pour un port ouvert et fermé.
Schéma des comportements lors d'un TCP Connect Scan pour un port ouvert et fermé.

Voici ce que l'on peut voir transiter sur le réseau lors d'un TCP Connect scan ciblant un port ouvert :

Sniff réseau lors d’un TCP Connect scan pour un port ouvert.
Sniff réseau lors d’un TCP Connect scan pour un port ouvert.

Nous voyons que le premier paquet TCP envoyé est un TCP SYN envoyé par le client, le serveur va ensuite répondre par un TCP SYN/ACK ce qui nous indiquera que le port est ouvert et héberge un service actif. Pour simuler un client légitime jusqu'au bout, Nmap va ensuite renvoyer un TCP ACK au serveur. À l'inverse, lors d'un scan sur un port fermé :

Capture réseau lors d’un TCP Connect scan pour un port fermé.
Capture réseau lors d’un TCP Connect scan pour un port fermé.

On remarque que la réponse du serveur à notre paquet SYN est une fois encore un paquet  TCP RST/ACK, nous pouvons donc en déduire que le port est fermé et qu'aucun service ne tourne sur celui-ci.

En utilisant Nmap, c'est l'option "-sT" (scan Connect) qui permet d'effectuer  un TCP Connect Scan. Sachez également que lorsque Nmap est utilisé depuis une session non privilégiée, c’est le mode de scan TCP utilisé par défaut :

# Exécution d’un TCP Connect Scan
nmap -sT 192.168.1.15

Le TCP Connect Scan simule une demande de connexion plus légitime avec un comportement qui se rapproche le plus de celui d'un client lambda, il est donc plus difficile de repérer un scan sur un nombre réduit de ports. Il est toutefois plus lent, car il initialise complètement chaque connexion TCP sur les ports ouverts de la machine scannée.

Un scan Nmap sur 10 000 ports sera toujours facilement détectable si des services de protection et de détection des intrusions réseau (IDS, IPS, EDR) sont installés. Quand un attaquant souhaite se faire discret, il va plutôt orienter ses recherches vers des ports choisis stratégiquement et en nombre réduit comme le port 445 (SMB) ou 80 (HTTP) qui sont souvent ouverts sur les serveurs et qui présentent des failles généralement courantes.

Étant donné que dans les deux cas, le TCP Connect Scan attend une réponse, il est lui aussi capable de détecter la présence d'un pare-feu qui pourrait filtrer les ports sur l’hôte visé.

IV. Le TCP FIN scan ou "Stealth Scan"

Le TCP FIN Scan, aussi nommé Stealth Scan, utilise quant à lui le comportement d'un client mettant fin à une connexion TCP afin de détecter un port ouvert.

En effet, en TCP, une fin de session se traduit par l'envoi d'un paquet TCP avec le flag FIN à 1. Dans un échange habituel, le serveur cesse donc toute communication avec le client (aucune réponse). Si le serveur n'avait aucune connexion TCP active avec le client, il renverra en revanche un RST/ACK. On saura donc différencier un port ouvert d'un port fermé en envoyant des paquets TCP FIN à un ensemble de ports :

Schéma des comportements lors d'un TCP FIN scan pour un port ouvert et fermé.

Schéma des comportements lors d'un TCP FIN scan pour un port ouvert et fermé.

J'ai à nouveau effectué une capture du réseau lors d'un Stealth scan et voilà ce que l'on voit lorsque le port scanné est ouvert :

Capture réseau lors d’un TCP FIN scan pour un port ouvert.
Capture réseau lors d’un TCP FIN scan pour un port ouvert.

On voit donc que le client envoie un ou deux paquets pour mettre fin à une connexion TCP et que le serveur ne répond pas. Il accepte tout simplement la fin de connexion et arrête de communiquer.

Voici ce que l'on peut voir maintenant lorsque l'on scanne un port fermé :

Capture réseau lors d'un TCP FIN scan pour un port fermé.
Capture réseau lors d'un TCP FIN scan pour un port fermé.

Nous voyons que le serveur renvoie un paquet TCP RST/ACK, il y a donc bien une différence de comportement entre un port ouvert et un port fermé et nous sommes en mesure de lister les ports ouverts sur un serveur via l'envoi de paquet TCP FIN. En utilisant Nmap, c'est l'option "-sF" (scan FIN) qui permet d'effectuer  un TCP FIN Scan :

# Exécution d’un TCP Fin Scan
nmap -sF 192.168.1.15

Le TCP FIN Scan ne fonctionne pas sur les hôtes Windows, cela, car l’OS a tendance à ignorer les paquets TCP FIN lorsqu'ils sont envoyés sur des ports qui ne sont pas ouverts. Nous aurons donc l'impression que tous les ports sont fermés si l'on effectue un TCP FIN Scan sur un hôte Windows.

C'est là l'intérêt de connaître à la fois plusieurs méthodes de scan, mais aussi de comprendre la différence entre chacune d'entre elles.

Étant donné que dans un des deux cas, le TCP FIN n'attendra pas de réponse, celui-ci sera incapable de détecter la présence d'un pare-feu entre l’hôte cible et la source de scan.

Voici donc un exemple de résultat de scan TCP FIN par Nmap :

Résultat d’un scan TCP FIN par Nmap.
Résultat d’un scan TCP FIN par Nmap.

En effet, une non-réponse de l'hôte sur un port donné pourra à la fois signifier que le port est filtré, mais également qu'il est ouvert et actif.

Ce scan est qualifié de "stealth" (discret), car il ne produit pas beaucoup de trafic et ne provoque généralement pas de journalisation dans les systèmes ciblés. Il peut être utilisé pour découvrir discrètement les ports sur un réseau sans lever d’alerte. Cependant, comme mentionné précédemment, son efficacité peut varier en fonction du système cible, tout comme sa discrétion en fonction de la configuration des équipements de sécurité.

V. Conclusion

Voilà pour ce premier des deux chapitres concernant les différents types de scan TCP proposés par Nmap ! Nous avons vu ici les plus communs, dans le prochain chapitre, nous nous pencherons sur les types de scan TCP XMAS, Null et ACK qui opèrent de façon différente pour détecter les ports ouverts sur un hôte.

author avatar
Mickael Dorigny Co-founder
Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.