Technique de scan de port UDP
Sommaire
I. Présentation
Dans la suite des tutoriels sur le scan de port, nous allons aujourd'hui étudier l'intérêt, le fonctionnement, mais aussi les limites du scan de port via le protocole de transport UDP, aussi appelé "protocole sans connexion".
II. UDP, dit protocole « connection-less »
Contrairement au protocole TCP (Transmission Control Protocol), le protocole UDP (User Datagramme Protocol) est un protocole dit "connection-less" ou "sans connexion" et cela pose une difficulté supplémentaire dans la détection et le scan de port. Le fait qu'un protocole de transport soit sans connexion implique en effet que les paquets ne sont pas sûrs d'arriver à destination et que nous ne soyons pas averties de leur arrivée. Cela peut alors fausser le scan. Pour plus d'information, le protocole UDP est décrit dans le RFC 768, "User Datagram Protocol"
De plus, nous avons vu dans nos précédents billets sur les scans de port TCP que les réponses à nos paquets aidaient fortement à déterminer l'état des ports scannés, or en UDP, aucun retour n'est fait.
III. Fonctionnement d'un scan de port UDP
Du fait de la simplicité des échanges entre les machines utilisant le protocole de transport UDP, le scan des ports UDP n'est pas complexe à mettre en œuvre. En effet, il n'est possible de déterminer que deux états d'un port. Soit il est filtré ou ouvert, soit il est fermé. Dans le cas où le port est ouvert, aucun retour ne sera fait à notre machine de scan par le serveur ciblé. En effet, c'est le comportement normal des machines communiquant via UDP de ne pas renvoyer de paquet de bonne réception (ACK ou "acknowledgement"). À l'inverse, si aucune application n'est prête à recevoir notre paquet sur le port UDP visé, alors c'est un paquet ICMP qui nous est renvoyé avec le code d'erreur correspondant, soit le message "ICMP_Port_Unreach_Error". En ayant une différence entre la réaction d'un port ouvert et celle d'un port fermé, nous pouvons effectuer un scan de l'ensemble des ports UDP :
Il est important de savoir qu'un scan UDP n'est pas capable de détecter la présence d'un pare-feu ou d'un système de filtrage entre la machine de scan et la cible scannée, ce qui peut fausser les résultats obtenus. En effet, un pare-feu entre les deux machines aura pour effet qu'aucun paquet ne soit renvoyé à la machine émettant le scan que le port soit ouvert ou non. Cela est gênant car quand le port UDP visé est ouvert, aucun paquet ne nous est renvoyé non plus. Ainsi quand un port apparait ouvert, il se peut qu'il soit en réalité filtré, et inversement.
Sur l’outil nmap, c'est l'option "-sU" (scan UDP) qu'il faut utiliser pour effectuer un scan de port UDP :
nmap -sU 192.168.1.17
Pour que l'article soit plus parlant et plus clair, j'ai effectué un scan UDP sur deux ports d'une machine cible, l'un des ports était ouvert, l'autre fermé. J'ai également effectué une écoute au niveau du réseau pendant ces deux scans pour observer les différences de comportement étudiées plus haut. Voici par exemple la vue sur nmap lors du scan d'un port ouvert ou filtré :
Nous voyons donc qu'nmap nous informe que le port visé "991" peut être ou ouvert, ou filtré. On peut alors essayer d'investiguer plus en profondeur sur le port en question. Sur le réseau, voici ce que l'on peut observer :
On voit donc que les deux paquets UDP envoyés sur le port donné "991" sont sans réponse de l'hôte distant. Nmap choisit d'envoyer deux paquets de par le risque qu'UDP représente. En effet, si un paquet est perdu, on pourrait ne pas avoir de réponse et croire que le port est ouvert alors qu'il n'a jamais atteint la cible, c'est pourquoi deux paquets sont envoyés.
À l'inverse, lors du scan nmap d'un port fermé, voici ce que l'on pourra avoir comme retour :
Nous voyons donc que le port est clairement identifié comme fermé ("closed"). Sur le réseau, voici ce que l'on pourra voir lors d'une écoute réseau :
Nous voyons donc clairement après notre paquet UDP envoyé sur le port "990" qu'une réponse de l'hôte scanné nous est faite. Il s'agit donc du paquet ICMP comportant le message "Port unreachable". Nous voyons bien que le port est ici fermé.
Les logiciels et outils de scan UDP utilisent tous ce fonctionnement. En réceptionnant tous les paquets ICMP, ils dressent une liste des paquets fermés et savent donc que tous les autres paquets sur lesquels ont été envoyés des paquets UDP sont, soient filtrés par un pare-feu, soit ouverts. Libre ensuite à vous d'investiguer plus en profondeur sur chacun d'eux pour savoir ce qui se cache derrière ces ports.
IV. Les limites du scan de port UDP
Le scan via le protocole de transport UDP est aussi important que le scan TCP de par les informations qu'il peut procurer à un attaquant, il trahira bien souvent la présence d'un service pouvant être utilisé et exploité. Cependant, il comporte quelques limites qu'il est important de connaitre :
- Le fait que le protocole n'ait pas de système de validation de bonne réception entre les hôtes fait naitre le risque que les paquets perdus faussent les résultats du scan. En effet, la non-réponse d'un hôte à la stimulation d'un port pourra nous faire penser qu'il s'agit d'un port potentiellement ouvert alors que le paquet UDP n'est tout simplement pas arrivé à sa destination, c'est pour cela que certains outils comme nmap envoient deux paquets UDP.
- Le scan UDP est généralement plus lent que les scans TCP. En effet, il s'agit d'un protocole qui utilise généralement moins de ressources réseau que le protocole TCP et qui est également moins utilisé en terme de volume de paquet. La taille des mémoires tampons (tampons stockant les paquets réseau en attente de leurs traitements par le système) est plus petite que ceux pour les paquets TCP. Cela conduit donc à des lenteurs supplémentaires lors du scan.
- Lors d'un scan UDP, vous remarquerez que les paquets sont formatés en fonction du port ciblé. Voici par exemple le cas d'un scan UDP fait sur le port 53 qui correspond au port DNS généralement utilisé par les clients lors de leurs requêtes :
On voit donc que le paquet UDP envoyé pour sonder le port 53 comporte automatiquement une requête DNS sur le statut du serveur. Ainsi, un serveur standard mis sur un port autre que celui habituel (ou inversement) pourra fausser le résultat du scan.
Enfin, il existe une parade efficace contre les scans UDP que nous allons étudier dans le point suivant et qui constitue une limite forte aux scans UDP faits dans certains contextes.
V. Protection contre le scan de port UDP
Après avoir expliqué la façon par laquelle les attaquants pouvaient détecter des services actifs via UDP sur les systèmes, il convient maintenant de proposer des pistes de protection et de prévention contre ces scans qui, même s'ils paraissent anodins, peuvent conduire à la détection de services vulnérables et sensibles. Il existe en effet quelques astuces pour détecter des scans de ports et pour les bloquer :
- La mise en place de services de détection d'intrusion ou de prévention d'intrusion, appelés plus communément IDS ou IPS, permet en effet de détecter des scans UDP. En recevant le trafic réseau en temps réel, il peut être simple de détecter que des centaines de paquets UDP sont envoyés sur une même IP en peu de temps et ainsi lever une alerte à ce sujet. Cela peut néanmoins être contourné lorsque l'attaquant met plusieurs jours à effectuer son scan en espaçant les envois de paquet UDP pour passer sous les radars IPS/IDS. Un attaquant peut également viser uniquement quelques ports stratégiquement choisis et connus comme étant des ports souvent ouverts et sensibles (DNS & SNMP par exemple).
- Une autre protection souvent mise en avant contre les scans UDP est la mise en place d'un filtrage du trafic réseau interdisant les paquets ICMP de types "ICMP_Port_Unreachable_Error" de sortir. Cela empêchera l'attaquant de recevoir les paquets indiquant qu'un port est fermé, faussant ainsi les résultats de son scan qui affichera tous les ports comme soit ouverts, soit filtrés. Cela implique bien sûr que la machine scannée ait un système de filtrage intégré tel qu'iptables ou alors un système de filtrage de type routeur, mais il faut pour cela que le scan s'effectue au travers ce routeur et non pas à l'intérieur même du réseau local de la machine visée.
Autres articles sur le sujet :
Une petite vidéo sur les ports ?