Databases, Systems & Networks

Le scan SYN est celui par défaut et le plus populaire pour de bonnes raisons. Il peut être exécuté rapidement et scanner des milliers de ports par seconde sur un réseau rapide lorsqu’il n’est pas entravé par des pare-feux. Le scan SYN est relativement discret et furtif, vu qu’il ne termine jamais les connexions TCP. Il marche également contre toute pile respectant TCP, au lieu de dépendre des particularités environnementales spécifiques comme les scans Fin/Null/Xmas, Maimon ou Idle le sont. Il permet de plus une différentiation fiable entre les états ouvert, fermé et filtré.

Cette technique est souvent appelée le scan demi-ouvert (half-open scanning), car il n’établi pas pleinement la connexion TCP. Il envoie un paquet SYN et attend sa réponse, comme s’il voulait vraiment ouvrir une connexion. Une réponse SYN/ACK indique que le port est en écoute (ouvert), tandis qu’une RST (reset) indique le contraire. Si aucune réponse n’est reçue après plusieurs essais, le port est considéré comme étant filtré. Le port l’est également si un message d’erreur « unreachable ICMP (type 3, code 1,2, 3, 9, 10 ou 13) » est reçu.

Le scan TCP connect() est le type de scan par défaut quand le SYN n’est pas utilisable. Tel est le cas lorsque l’utilisateur n’a pas les privilèges pour les paquets bruts (raw packets) ou lors d’un scan de réseaux IPv6. Plutôt que d’écrire des paquets bruts comme le font la plupart des autres types de scan, Nmap demande au système d’exploitation qui l’exécute d’établir une connexion au port de la machine cible grâce à l’appel système connect(). C’est le même appel système haut-niveau qui est appelé par les navigateurs Web, les clients P2P et la plupart des applications réseaux qui veulent établir une connexion. Cet appel fait partie de l’interface d’application connue sous le nom de « Berkeley Sockets API ». Au lieu de lire les réponses brutes sur le support physique, Nmap utilise cette application API pour obtenir l’état de chaque tentative de connexion.

Si le scan SYN est disponible, il vaut mieux l’utiliser. Nmap a bien moins de contrôles sur l’appel système haut niveau   connect() que sur les paquets bruts, ce qui le rend moins efficace. L’appel système complète les connexions ouvertes sur les ports cibles au lieu de les annuler lorsque la connexion est à demie ouverte, comme le fait le scan SYN. Non seulement c’est plus long et demande plus de paquets pour obtenir la même information, mais de plus la probabilité que les cibles activent la connexion est plus grande. Un IDS décent le fera, mais la plupart des machines ne disposent pas de ce système d’alarme. De nombreux services sur les systèmes UNIX standards noteront cette connexion dans le journal, accompagné d’un message d’erreur sibyllin si Nmap ouvre puis referme la connexion sans n’envoyer aucune donnée. Les services réseaux les plus piteux risquent même de tomber en panne, mais c’est assez rare. Un administrateur qui verrait un tas de tentatives de connexions dans ses journaux en provenance d’une seule machine devrait se rendre compte qu’il a été scanné.

Même si les services les plus connus d’Internet son basés sur le protocole TCP, les services UDP sont aussi largement utilisés. DNS, SNMP ou DHCP (ports 53, 161/162 et 67/68) sont les trois exemples les plus courants. Comme le scan UDP est généralement plus lent et plus difficile que TCP, certains auditeurs de sécurité les ignorent. C’est une erreur, car les services UDP exploitables sont courants et les attaquants eux ne les ignoreront pas. Par chance, Nmap peut aider à répertorier les ports UDP.

Le scan UDP est activé avec l’option-sU. Il peut être combiné avec un scan TCP, comme le scan SYN (  -sS), pour vérifier les deux protocoles lors de la même exécution de Nmap.

Le scan UDP envoie un en-tête UDP (sans données) à chaque port visé. Si un message ICMP « port unreachable (type 3, code 3) » est renvoyé, le port est alors fermé. Les autres messages d’erreur « unreachable ICMP (type 3, codes 1, 2, 9, 10, or 13) » rendront le port filtré. À l’occasion, il arrive qu’un service répond par un paquet UDP, prouvant que le port est dans l’état ouvert. Si aucune réponse n’est renvoyée après plusieurs essais, le port est considéré comme étant ouvert|filtré. Cela signifie que le port peut être soit ouvert, soit qu’un dispositif de filtrage bloque les communications. Le scan de versions (  -sV) peut être utilisé pour différencier les ports ouverts de ceux filtrés.

Une des grandes difficultés avec le scan UDP est de l’exécuter rapidement. Les ports ouverts et filtrés ne renvoient que rarement des réponses, laissant Nmap expirer son délai de retransmission au cas où les paquets se soient perdus. Les ports fermés posent encore un plus grand problème: ils renvoient normalement une erreur ICMP « port unreachable ». Mais à la différence des paquets RST renvoyés par les ports TCP fermés en réponse à un scan SYN ou à un connect(), de nombreux hôtes limitent par défaut la cadence d’émission de ces messages. Linux et Solaris étant particulièrement stricts à ce sujet. Par exemple, le kernel 2.4.20 limite cette cadence des destinations inaccessibles (« destination unreachable ») à un par seconde (cf.net/ipv4/icmp.c).

Nmap détecte cette limitation de fréquence et s’y ralenti conformément afin d’éviter de saturer le réseau avec des paquets inutiles que la machine cible rejettera. Malheureusement, une limitation à la Linux d’un paquet par seconde fera qu’un scan des 65 536 ports prendra plus de 18 heures. Les idées pour accélérer les scans UDP incluent le scan des cibles en parallèle, ne scanner que les ports les plus courants en premier, scanner derrière le pare-feu et utiliser l’option --host-timeoutpour éviter les hôtes les plus lents.

Lire la suite…