¿ Porque Nmap es Lento con Redes Muy Filtradas ?

Hace unos meses tuve que realizar un PenTest a una red GPRS y me encontré con un verdadero problema al momento de realizar el escaneo de puertos, todo era muy lento!

No solamente tenia una conexión bastante lenta, ya que para acceder a la red GPRS debía utilizar un celular que conectaba a mi laptop a través de bluetooth, sino que también la mayoría de las redes que debía auditar estaban filtradas, y un gran problema que tiene Nmap, es que se vuelve sumamente lento cuando se encuentra con redes muy filtradas.

Entonces, ¿ Porque Nmap es Lento con Redes Muy Filtradas ?

Básicamente, Nmap utiliza un algoritmo con el cual va ajustando el RTT Timeout con cada respuesta que recibe de los host que están siendo escaneados. Cuando Nmap se encuentra con un puerto filtrado y no recibe ninguna respuesta, debe esperar a que se cumpla el RTT Timeout, y luego volver a enviar el paquete, para estar seguro de que no se llego al Timeout debido a perdidas de paquetes en la red.

A causa de esto, mientras que Nmap recibe respuestas de los hosts puede ir ajustando el RTT Timeout a un valor optimo y el escaneo será muy rápido. Pero cuando se encuentra con hosts que no proveen ninguna respuesta, se llega al peor escenario en donde por cada paquete enviado hay que esperar a que se cumpla el Timeout máximo por default de 10 segundos, y luego volver a retransmitir ese mismo paquete 10 veces mas para confirmar que efectivamente se trata de un puerto filtrado y no de perdida de paquetes.

Nmap posee varias políticas para manejar el Timing de nuestro escaneo, la política utilizada por default es la T3 (Normal):

Una de las técnicas que utiliza PortBunny para evitar este problema con redes muy filtradas es el uso de Triggers. Nmap también utiliza el concepto de Triggers, que básicamente consiste en enviar paquetes para poder medir el RTT de la respuesta, pero la diferencia es que PortBunny utiliza Triggers con hosts de los que ya se conoce de antemano que van a proveer una respuesta. Entonces durante toda la duración del escaneo constantemente se le envían paquetes a estos hosts, y cuando se deja de recibir una respuesta sabemos efectivamente que hay perdidas de paquetes y no que se trata de un puerto filtrado.

Obviamente al utilizar Triggers, PortBunny genera un 10% mas de paquetes durante el escaneo, pero según los autores igualmente se logran tiempos muchos mejores que los de Nmap.

Hay muchos otros factores de importancia durante un escaneo de puertos, como ser el control de congestión, el ancho de banda, estimar correctamente el RTT, encontrar Triggers efectivos para nuestro escaneo, pero lo vamos a dejar para otro post... ;)

Les dejo algunos links interesantes sobre este tema:

- Candado Digital: Optimizando escaneos de puertos con Nmap
- Nmap: Timing and Performance
- Secrets of Network Cartography: Timing Options
- KungFooSion: PortBunny y la Guerra de los Port Scanners