Distinguer les ports UDP ouverts des ports UDP filtrés
Dans le cas du scan Felix, tous les ports sauf les troisopen|filtered étaient closed.Donc le scan a quand même réussi à réduire les ports potentiellement ouverts à une poignée. Ce n’est pas toujours le cas. L’exemple 5.5 montre un scan UDP contre le site fortement filtré Scanme.
Exemple 5.5. Exemple de scan UDP
krad# Starting Nmap ( http://nmap.org )All 1000 scanned ports on scanme.nmap.org (64.13.134.52) are open|filteredNmap done: 1 IP address (1 host up) scanned in 5.50 seconds
Dans ce cas, le scan n’a pas du tout réduit les ports ouverts.Tous les 1000 sont open|filtered. Une nouvelle stratégie s’impose.
Le tableau 5.3, « Comment Nmap interprète les réponses à une sonde UDP » montre que l’état open|filtered se produit lorsque Nmap ne reçoit pas de réponses de ses sondes UDP sur un port particulier. Pourtant, il montre aussi que, dans de rares occasions, le service UDP à l’écoute sur un port répondra en nature, prouvant que le port est ouvert. La raison pour laquelle ces services ne répondent pas souvent est que les paquets vides envoyés par Nmap sont considérés comme invalides. Malheureusement, les services UDP définissent généralement leur propre structure de paquets plutôt que d’adhérer à un format général commun que Nmap pourrait toujours envoyer. Un paquet SNMP a une apparence complètement différente d’un paquet de requête SunRPC, DHCP ou DNS.
Pour envoyer le paquet approprié pour chaque service UDP populaire, Nmapaurait besoin d’une grande base de données définissant leurs formats de sonde.Heureusement, Nmap dispose de cela sous la forme denmap-service-probes,qui fait partie du sous-système de détection de service et de version décrit au chapitre 7, Détection de version de service et d’application.
Lorsque le scan de version est activé avec -sV (ou-A), il enverra des sondes UDP à chaque portopen|filtered (ainsi qu’aux ports connusopen). Si l’une des sondes obtient une réponse d’un port open|filtered, l’état est changé en open. Les résultats de l’ajout de-sV à l’analyse de Felix sont présentés dans l’exemple 5.6.
Exemple 5.6. Amélioration des résultats de l’analyse UDP de Felix avec la détection de version
krad# Starting Nmap ( http://nmap.org )Nmap scan report for felix.nmap.org (192.168.0.42)Not shown: 997 closed portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.2.167/udp open|filtered dhcpserver111/udp open rpcbind 2 (rpc #100000)MAC Address: 00:02:E3:14:11:02 (Lite-on Communications)Nmap done: 1 IP address (1 host up) scanned in 1037.57 seconds
Cette nouvelle analyse montre que les ports 111 et 53 sont définitivement ouverts.Le système n’est cependant pas parfait- le port 67 est toujoursopen|filtered. Dans ce cas particulier, le port est ouvert mais Nmap ne dispose pas d’une version opérationnelle de la sonde pour DHCP.Un autre service difficile est SNMP, qui ne répond généralement que lorsque la chaîne de communauté correcte est donnée. De nombreux appareils sont configurés avec la chaîne de communauté public, mais pas tous.Bien que ces résultats ne soient pas parfaits, apprendre le véritable état de deux des trois ports testés est tout de même utile.
Après avoir réussi à désambiguïser les résultats de Felix, Ere retourne son attention sur Scanme, qui listait tous les ports comme open|filtered la dernière fois. Il essaie à nouveau de détecter la version, comme le montre l’exemple 5.7.
Exemple 5.7. Amélioration des résultats du scan UDP de Scanme avec la détection de version
krad# Starting Nmap ( http://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)Not shown: 999 open|filtered portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.3.4Nmap done: 1 IP address (1 host up) scanned in 3691.89 seconds
Bien qu’Ereet ait finalement trouvé le port ouvert, il a commis une erreur en ne mettant pas d’abord à jour sa version de Nmap. Les versions 5.10BETA1 et plus récentes de Nmap ont un système de charge utile qui envoie des requêtes au protocole de service approprié à plus de trois douzaines de ports UDP bien connus s’ils sont sélectionnés pour un balayage de port ou une découverte d’hôte. Bien qu’il ne soit pas aussi complet que la détection de version, il aurait rapidement identifié le port 53 ouvert dans l’exemple 5.5.
Ce résultat a pris une heure, contre cinq secondes pour le scanScanme précédent, mais ces résultats sont réellement utiles. Le sourire d’Ereet s’élargit et ses yeux brillent devant cette preuve d’un serveur de noms BIND ISC ouvert sur une machine qu’il veut compromettre. Ce logiciel a une longue histoire de failles de sécurité, alors peut-être pourra-t-il trouver une faille dans cette version récente.
Ereet concentrera ses attaques UDP sur le port 53 puisqu’il estconfirmé ouvert, mais il n’oublie pas les 999 autres ports listés commeopen|filtered. Comme nous l’avons vu avec le port dhcpserver de Felix, certains services UDP ouverts peuvent même échapper à la détection de la version de Nmap. Il n’a également scanné que les ports par défaut jusqu’à présent, il y a 64529 autres ports qui pourraient être ouverts. Pour mémoire, 53 est le seul port UDP ouvert sur Scanme.
Bien que cette technique de détection de version soit la seule façon pour Nmap de désambiguïser automatiquement les ports open|filtered, il y a quelques astuces qui peuvent être essayées manuellement. Parfois, un traceroute spécialisé peut aider. Vous pouvez faire un traceroute contre un port TCP ou UDP ouvert connu avec Nmap ou un outil tel que Nping, puis essayer de faire de même avec le port UDP douteux. Les différences dans le nombre de sauts peuvent différencier les ports ouverts des ports filtrés. Ereet tente ceci contre Scanme dans l’Exemple 5.8. La première commande effectue un traceroute UDP contre le port 53 connu et ouvert. La deuxième commande fait la même chose contre le port 54 présumé fermé. Les premiers sauts ont été omis pour gagner de la place.
Exemple 5.8. Tentative de désambiguïsation des ports UDP avec des divergences TTL
krad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=8 id=4826 iplen=28RCVD (7.1010s) ICMP 4.69.134.222 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=38454 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=9 id=38166 iplen=28RCVD (8.1050s) ICMP 4.68.18.204 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=39583 iplen=56SENT (9.0420s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=10 id=6788 iplen=28RCVD (9.1080s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=59897 iplen=56SENT (10.0440s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=11 id=366 iplen=28RCVD (10.1100s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=42710 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=12 id=63478 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=13 id=56653 iplen=28Max rtt: 73.003ms | Min rtt: 0.540ms | Avg rtt: 48.731msRaw packets sent: 13 (364B) | Rcvd: 10 (560B) | Lost: 3 (23.08%)Tx time: 12.02836s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.02994s | Rx bytes/s: 42.98 | Rx pkts/s: 0.77Nping done: 1 IP address pinged in 13.05 secondskrad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=8 id=56481 iplen=28RCVD (7.1130s) ICMP 4.69.134.214 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=22437 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=9 id=23264 iplen=28RCVD (8.1060s) ICMP 4.68.18.76 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=50214 iplen=56SENT (9.0430s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=10 id=9101 iplen=28RCVD (9.1070s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=880 iplen=56SENT (10.0450s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=11 id=35344 iplen=28RCVD (10.1110s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=44617 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=12 id=53857 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=13 id=986 iplen=28Max rtt: 76.488ms | Min rtt: 0.546ms | Avg rtt: 48.480msRaw packets sent: 13 (364B) | Rcvd: 11 (616B) | Lost: 2 (15.38%)Tx time: 12.02908s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.03165s | Rx bytes/s: 47.27 | Rx pkts/s: 0.84Nping done: 1 IP address pinged in 13.05 seconds
Dans cet exemple, Ereet n’a pu atteindre que le onzième saut des ports ouverts et fermés. Ces résultats ne peuvent donc pas être utilisés pour distinguer les états des ports sur cet hôte. Cela valait la peine d’essayer, et cela fonctionne dans un nombre significatif de cas. Il est plus probable que cela fonctionne dans des situations où le pare-feu de filtrage est au moins un ou deux sauts avant l’hôte cible. Scanme, quant à lui, utilise son propre pare-feu basé sur Linuxiptableshost. Il n’y a donc aucune différence dans le nombre de sauts entre les ports filtrés et ouverts.
Une autre technique consiste à essayer des outils spécifiques à une application contre des ports communs. Par exemple, un craqueur de chaîne de communauté SNMP par force brute pourrait être essayé contre le port 161. Au fur et à mesure que la base de données des sondes de détection de version de Nmap s’agrandit, le besoin d’augmenter ses résultats avec des outils externes spécialisés est réduit. Ils seront toujours utiles pour des cas particuliers, comme les périphériques SNMP avec une chaîne de communauté personnalisée.