Skip to content

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

Dans cet article et ceux qui suivront, nous allons aborder les techniques et méthodes de scan de port au sein des réseaux. Il existe en effet plusieurs techniques permettant de scanner les IP d’un réseau et les ports des machines, que l’on passe par ICMP, ARP, TCP ou UDP…

L’idée est donc d’expliquer certaines de ces méthodes afin de comprendre comment il est possible de savoir quelle machine est sur le réseau et quels sont les ports ouverts (avec les services associés bien sûr).

Un petit mot sur le scanning

Il faut savoir que le scanning fait partie des toutes premières étapes lors d’une intrusion. En effet, après avoir cherché des informations sur l’entreprise de manière plus ou moins active, la première vraie démarche d’attaque va être de scanner le réseau (que l’on parle de réseau interne ou externe) et les machines de la cible.

En partant du principe que les machines dans vos réseaux sont les cibles, il est intéressant de connaitre en détail les procédés utilisés par les attaquants. Cela permettra de retracer plus facilement une attaque par exemple, mais aussi d’ouvrir des réflexions sur la manière de s’en protéger préventivement. L’idée de cet ensemble de tutoriels est donc de vous faire dire « Ah oui, on peut détecter mon service sensible sur cette machine de telle manière, si je réfléchissais à comment rendre ce service un peu plus discret ? « .

Je passerai ici outre les notions basiques du réseau comme ce qu’est le TCP, l’UDP ou l’adressage IP, il est néanmoins requis pour suivre a minima les articles de connaitre leur fonctionnement général. Tout au long des articles, je mettrai les lignes de commande correspondant à chaque scan en utilisant l’outil nmap principalement. Nmap présente de nombreuses options et est l’outil le plus efficace et complet pour effectuer des scans réseaux, il fonctionne en ligne de commande et GUI sous Linux et en GUI également sous Windows. Néanmoins, de nombreux autres outils comme les scripts intégrés à Metasploit peuvent également être utilisés.

Nous commençons donc avec les scans de ports TCP, comme son nom l’indique, le scan de port TCP va avoir pour but de détecter sur une machine ciblée les ports TCP ouverts et donc d’éventuels services utilisant ces ports. La détection de ports peut être particulièrement riche en informations pour l’attaquant, car elle s’accompagne de technique de détection de service et de version, que ce soit par la stimulation des ports en question, la lecture des bannières (banner grabbing) ou alors par la détection de services tournant sur les well-known ports, ces ports entre 0 et 1023 sur lesquels sont assignés des services standards. Par exemple, une détection d’un port TCP 22 ouvert nous amènera à fortement envisager la présence d’un service SSH ouvert sur la machine en question.

Dans tous les cas, les différents scans passent par une analyse comportementale du serveur visé en rapport à la description du protocole TCP dans le RFC 793, « Transmission Control Protocol » lors de l’envoi de différents paquets. Plus simplement, on va envoyer des paquets TCP forgés spécifiquement pour que le serveur réponde d’une façon précise (la façon décrite dans le RFC 793) et ainsi interpréter la réponse du serveur pour savoir si le port est ouvert ou fermé.

Trêve de blabla, commençons !

Le TCP SYN scan ou « Half Open scan »

Le premier type de scan TCP que nous allons voir est le TCP Syn scan ou Half Open scan (Half Open voulant dire « à moitié ouvert »), 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). En temps normal (si le port est ouvert sur le serveur avec un service tournant derrière), le serveur va renvoyer un SYN\ACK permettant de valider la SYN du client et d’initialiser la connexion TCP, c’est-à-dire un paquet TCP avec les flags SYN et ACK a 1, on pourra alors dire que le port est ouvert et détecter 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 :

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

Pour voir un aspect un peu plus concret du Half Open scan, j’ai effectué un scan du port 80 vers une machine qui avait un serveur web actif sur ce port. En effectuant une analyse réseau avec Wireshark entre mon serveur ma machine de scan, je vois le flux suivant :

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

On voit donc sur la première ligne que la machine 192.168.1.18 (ma machine de scan) envoie un paquet TCP à mon serveur web (port 192.168.1.15) sur le port 80. Dans ce paquet TCP, le flag SYN est à 1 pour signifier que le paquet est une demande d’initialisation de connexion TCP. On voit ensuite sur la deuxième ligne que mon serveur web répond un SYN/ACK, ce qui veut dire qu’il accepte d’initialiser une connexion et donc de recevoir des flux sur le port 80. On peut donc en déduire que le port 80 est ouvert et qu’un serveur web est bien présent sur ma machine cible, voila comment opère un attaquant ou un auditeur réseau lors d’un scan de port. Le fait de faire ce genre de scan sur un ensemble de ports sur une machine permet d’avoir un inventaire plus ou moins complet des services qu’elle fait tourner.

À l’inverse, j’ai effectué le même test entre les deux machines, mais cette fois-ci vers le port 81 sur lequel aucun service n’est actif :

tcp syn scan
Sniff réseau lors d’un TCP SYN scan pour un port fermé.

On voit donc que mon serveur renvoie un RST/ACK en réponse à mon TCP SYN lorsque le port n’est pas ouvert. En utilisant nmap, c’est l’option « -sS » (scan SYN) qui permet d’effectuer  un TCP SYN scan :

nmap -sS 192.168.1.15

Le TCP SYN scan est le scan le plus couramment utilisé, car il simule une demande de connexion légitime. En revanche, la fin de la connexion si le SYN/ACK est bien renvoyé par le serveur peut être suspecte si elle est observée trop de fois sur un serveur. En effet, le comportement normal d’un client après un TCP SYN/ACK en réponse à un TCP SYN est qu’il envoie 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 qu’il est plutôt rapide, car un seul paquet est envoyé par port à scanner.

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é de par 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 l’on peut avoir sur nmap lorsqu’un port visé est filtré (ici par un iptables directement configuré sur la machine cible) par un pare-feu :

tcp syn scan
Affichage nmap lors du scan d’un port filtré.

 Lorsque l’on sniff le réseau au moment de ce scan, on voit effectivement qu’aucune réponse n’est donnée :

tcp syn scan
Sniff réseau lors d’un TCP SYN scan pour un port filtré par un pare-feu.

La différence entre un port bloqué et un port filtré est ici, un port filtré est un port protégé par un pare-feu alors qu’un port bloqué est un port sur la machine visée 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 non.

Le TCP Connect scan ou « Full Open scan »

Le second type de scan TCP est le TCP Connect scan ou Full Open scan. Il reprend le même fonctionnement que le TCP SYN scan, mais cette fois-ci en renvoyant un 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 l’on initie complètement la connexion sur chaque port ouvert  lors du scan :

tcp connect scan
Schématisation 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 :

On voit donc ici 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 sur celui-ci tourne un service actif. Pour simuler un client légitime jusqu’au bout, l’outil de scan va ensuite renvoyer un TCP ACK au serveur. À l’inverse, lors d’un scan sur 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 :

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.

Note : Un scan de ports sur 10 000 ports sera toujours facilement détectable si des services de protection et de détection des intrusions réseau (IPS/IDS) 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 25 (SMTP) 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 entre la machine visée et la machine qui scan.

Le TCP FIN scan ou « Stealth Scan »

Le TCP FIN Scan ou Stealth Scan utilise quant à lui le comportement d’un client mettant fin à une connexion TCP. 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. 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 TCP FIN à un ensemble de ports pour déterminer lequel est ouvert et lequel est fermé :

tcp fin scan
Schématisation des comportements lors d’un TCP FINscan 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 :

tcp fin scan
Sniff 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é :

tcp fin scan
Sniff réseau lors d’un TCP FIN scan pour un port fermé.

On voit que le serveur renvoie un paquet TCP RST/ACK, on établit 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 FIN. En utilisant nmap, c’est l’option « -sF » (scan FIN) qui permet d’effectuer  un TCP FIN scan :

nmap -sF 192.168.1.15

Note : Le TCP FIN scan ne fonctionne pas sur les machines Windows, nous aurons donc l’impression que tous les ports sont fermés si l’on effectue un TCP FIN scan sur une machine Windows. C’est là l’intérêt d’avoir à la fois plusieurs méthodes de scanne 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 la machine cible et la machine qui scanne. 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.

C’est tout pour ce premier article sur les scans TCP ! Dans le prochain article, nous nous pencherons sur les méthodes de scan TCP XMAS, Null et ACK qui opèrent de façon différente pour détecter les ports ouverts sur une machine.

Autres articles sur sujet :

Partager :
Published inArticlesOutils

3 Comments

  1. Octopus

    Bonjour Mickaël,
    Un grand bravo pour cette article avec un peu de retard 🙂
    Je vais porter ma modeste contribution en vous proposant une ligne de commande, mais avant de la poster je souhaite préciser l’environnement réseau et système sur lequel je planche actuellement (test).
    J’ai déployé une machine hôte (physique) tournant sous OS Windows 8.1 Pro équipée de VMWARE WORKSTATION 12 PRO. J’ai configuré OpenDSN sur la machine hôte (serveur DNS en LOCALHOST, aucune passerelle par défaut) protégée par un Client VPN. J’ai ensuite monté une VM (test) tournant sur une distribution « Tails Linux » installée sur clé USB bootable (CDLive). L’interface réseau VMWARE de cette VM est nattée, elle traverse donc le tunnel VPN via un circuit Tor (navigation Tor), et les requêtes DNS transitent en LOCALHOST (port 53). A noter que j’ai désactivé définitivement le Client DNS Windows (service) et le Cache DNS Windows sur la machine hôte (physique) ainsi que d’autres services inutiles style « planificateur de tâches »…
    Voici la ligne de commande que j’ai implémentée dans un script exécutable au démarrage de la VM « Tails Linux »:
    # permet de détecter l’envoi d’un trop gros volume de paquets TCP avec les flags SYN et/ou ACK et/ou FIN et/ou
    # RST
    iptables -A FORWARD -p tcp –tcp-flags SYN,ACK,FIN,RST RST -m limit –limit 1/s -j ACCEPT
    # création d’un « name » incluant les ports couramment scannés par les robots (ftp, telnet, smtp, SMB…)
    iptables -A INPUT -p tcp -m multiport –dports 20:21,23,25,465,587,137:139,194,9040,9050,9051,9052,9061,9062 -m recent –set –name SCANNERS –rsource -j DROP
    # Permet le blocage d’un robot scannant 2 ports (hitcount) de la liste SCANNERS en moins de 3600 secondes
    # l’IP détectée sera ainsi bloquée durant 3600 secondes !
    iptables -A INPUT -m recent –update –seconds 3600 –hitcount 2 –name SCANNERS –rsource –reap -j DROP
    PS: les n° de ports sont à configurer en fonction des besoins, les ports 9040,9050,9051,9052,9061 et 9062 sont ceux utilisés par Tails (Tor).
    Le souci avec cette technique est que le module ‘xt-recent’ utilisé ici est limité à 100 adresses IP. Pour l’instant cela me suffit pour réaliser mes tests d’isolation réseau.
    Avez-vous des suggestions ou compléments à faire au sujet de cette « technique » évoquée ci-dessus ?
    Mon idée ici est de trouver une solution relativement simple pour superviser en temps réel la détection des attaques réseau du genre ARP spoofing, Scans ports etc. à partir de la machine hôte (physique) à l’aide par exemple de « XARP » (Windows) et de la VM « Tails Linux » (XARP Ubuntu). Vous conviendrez que sur une distribution « Tails Linux » (CDLive) il est très compliqué de suivre en temps réel ce type d’attaques réseau ou sniffing, malgré un filtrage effectué en amont.
    Que pensez-vous de ce test et technique ?
    Cordialement.

Laisser un commentaire

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