Les scans de port via TCP : XMAS, Null et ACK

I. Présentation

J'ai récemment écrit un article qui expliquait l'intérêt et les enjeux du scanning de port et dans lequel je détaillais le fonctionnement des scans TCP SYN, Connect et FIN. Dans cet article nous verrons trois autres techniques de scan de port via TCP.

Nous allons ici étudier les méthodes XMAS, Null et ACK qui permettent, via des spécificités propres à TCP, de récupérer des informations sur les ports et services ouverts sur une cible donnée.

II. Le TCP XMAS scan

Le TCP XMAS scan est un peu particulier, car il ne simule pas un comportement normal d'utilisateur ou de machine au sein d'un réseau. En effet, le TCP XMAS scan va envoyer des paquets TCP avec les flags URG, PUSH et FIN à 1 dans le but de déjouer certains pare-feu ou mécanismes de filtrage. Sans détailler le rôle de ces flags ici, il faut savoir que lors d'un envoi de paquet avec ces trois flags activés, un service actif derrière le port visé ne renverra aucun paquet. En revanche, si le port est fermé, nous recevrons un paquet TCP RST/ACK. On saura alors différencier le comportement d'un port ouvert et d'un port fermé pour lister les ports sur une machine :

Schématisation des comportements lors d’un TCP XMAS scan pour un port ouvert et fermé

Comme lors de mon précédent billet sur le sujet, j'ai effectué un scan réseau sur le port 80 d'une machine qui avait un serveur web actif sur celui-ci, voici le comportement que l'on peut donc observer lors de la détection d'un port ouvert :

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

On voit donc que ma machine de scan ayant l'IP 192.168.1.18 envoie deux paquets TCP de type XMAS (avec les flags FIN, PSH et URG à 1) à la machine web (192.168.1.15) et nous n'avons tout simplement aucun retour de la cible, on sait donc que le port est ouvert. À l'inverse, lorsque que l'on effectue un TCP XMAS scan sur un port fermé, voici ce que l'on peut voir :

Sniff réseau lors d'un TCP XMAS scan pour un port fermé.

Nous voyons donc que la réponse à notre paquet TCP est un TCP RST/ACK, le port est donc fermé. Sur l’outil nmap, l'option suivante permet d'effectuer un TCP XMAS scan :

nmap -sX 192.168.1.15

Il est important de signaler que le TCP XMAS scan n'est pas capable de détecter les pare-feu qui pourraient se trouver entre la cible et la machine de scan à l'inverse de certains autres types de scan comme le TCP SYN ou Connect. En effet, un pare-feu qui serait actif entre les deux hôtes ferait en sorte qu'aucun retour TCP ne soit fait si le port visé est filtré (c'est à dire protégé par le pare-feu). On est alors dans l'impossibilité, lors d'une non-réponse, de savoir s'il s'agit d'un port protégé par le pare-feu ou alors d'un port ouvert et actif. Il faut également savoir que, comme le TCP FIN scan décrit dans le précédent billet sur le sujet, certaines applications ou OS comme les OS Windows peuvent fausser les résultats de ce type de scan.

III. Le TCP Null scan

À l'inverse du TCP XMAS scan, le TCP Null scan va envoyer des paquets TCP scan avec tous les flags à 0. Il s'agit là aussi d'un comportement que l'on ne trouvera jamais dans un échange normal entre des machines, car l'envoi d'un paquet TCP sans flag n'est pas spécifié dans le RFC décrivant le protocole TCP, c'est pourquoi il peut être détecté plus facilement. L'utilisation de ce scan peut, comme le TCP XMAS scan, perturber certains firewalls ou modules de filtrage et alors laisser passer les paquets :

Schématisation des comportements lors d’un TCP Null scan pour un port ouvert et fermé

Voici ce que l'on peut observer sur le réseau lorsque l'on effectue un TCP Null scan sur un port ouvert :

Sniff réseau lors d'un TCP Null scan pour un port ouvert.

On voit que la machine de scan envoie un paquet sans flag (qui se traduit par l'inscription [<None>] dans Wireshark) sans aucune réponse du serveur. À l'inverse, voici ce qu'il se passe lorsque le port visé est fermé :

Sniff réseau lors d'un TCP Null scan pour un port fermé.

Sur nmap, la ligne de commande suivante est à utiliser pour effectuer un TCP Null scan :

nmap -sN 192.168.1.15

Étant donné que la réponse quand un port est ouvert et quand un firewall est actif (c'est-à-dire aucun retour du serveur dans les deux cas), le TCP Null scan est incapable de détecter la présence d'un firewall. De plus, le firewall peut même fausser le résultat en faisant croire qu'un port est ouvert, car il ne répond pas aux paquets TCP sans flags alors que celui-ci est filtré et donc protégé. C'est une information à connaitre lorsque l'on emploie des scans qui sont incapables de différencier un port ouvert d'un port filtré (protégé par un pare-feu) comme les scans TCP Null, XMAS ou FIN afin de rester cohérent dans l'interprétation des résultats obtenus.

IV. Le TCP ACK scan

Le TCP ACK scan est utilisé pour détecter la présence d'un pare-feu sur la machine cible ou entre la machine cible et la machine de scan. En effet, contrairement aux autres scans, le TCP ACK scan ne va pas avoir pour objectif de voir quel port est ouvert sur la machine finale, mais plutôt de savoir si un système de filtrage est actif en répondant pour chaque port par "filtered" ou "unfiltered". Certains scans TCP comme les TCP SYN ou TCP Connect savent faire les deux en même temps alors que d'autres comme TCP FIN ou TCP XMAS ne permettent pas du tout de déterminer la présence d'un filtrage, c'est pourquoi le TCP ACK scan peut avoir un intérêt :

Schématisation des comportements lors d'un TCP ACK scan pour un port filtré et non filtré.

On utilisera l'option "-sA" de l’outil nmap pour effectuer ce type de scan, voici le résultat que nous pourrons avoir lors de l'exécution de ce TCP ACK scan dans le cas où le port est filtré, c'est-à-dire bloqué et protégé par un pare-feu :

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

On voit donc que nmap nous retourne un "filtered" sur le port 80, dans le cas où nous essayerions d'accéder à ce service web via un navigateur, nous n'aurions donc aucune réponse puisque le port est bloqué. Sur une analyse réseau via Wireshark, nous pourrions voir la chose suivante :

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

Étant donné que le port est bloqué, nous n'avons aucune réponse à nos paquets TCP ACK. Dans le cas où le port ne serait pas protégé par un pare-feu, nous pourrions voir le résultat suivant dans nmap :

Affichage nmap lors du scan d'un port non filtré.

On va donc voir que le port est non filtré et essayer ensuite de déterminer s'il est ouvert ou non avec d'autres types de scans.

Note : Dans le cas où nmap ou un autre outil effectuant un TCP ACK scan retourne la mention "unfiltered", cela ne signifie pas pour autant que le port est ouvert et qu'un service tourne sur celui-ci. Cela signifie seulement qu'aucun système de filtrage n'est présent entre la machine de scan et la machine cible. Il faut donc ensuite effectuer un autre type de scan comme un TCP SYN ou TCP Connect pour savoir si le port est bien ouvert.

Sur le réseau, on pourra observer les flux suivants :

Sniff réseau lors d'un TCP ACK scan pour un port non filtré par un pare-feu.

On voit donc que la machine cible nous renvoie un paquet TCP RST dans le cas où aucun pare-feu n'est présent.

Nous avons ici vu trois méthodes différentes de scan via TCP en plus de celles vues précédemment, dans le prochain billet, nous étudierons le fonctionnement du scan UDP.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Mickael Dorigny

Co-fondateur d'IT-Connect.fr. Auditeur en sécurité des systèmes d'information chez Amossys

    mickael has 502 posts and counting.See all posts by mickael

    Laisser un commentaire

    Votre adresse de messagerie 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.