Cálculo del RTT en Nmap

Teniendo que auditar un activo, durante la fase de reconocimiento quise hacer un escaneo de todos los puertos, del 1 al 65535, para que no hubiera nada raro que no debiera estar accesible. Como esto llevaría un tiempo que no me apetecía invertir, recordé el artículo de mi compañero José Luis sobre la optimización de Nmap. Ya sabéis, básicamente lancé un ping para calcular el RTT mínimo y medio y utilicé esos valores para definir los parámetros --initial-rtt-timout y --max-rtt-timeout.

mbelda@pc:~$ ping -c4 192.168.XXX.XXX 
PING 192.168.XXX.XXX (192.168.XXX.XXX) 56(84) bytes of data. 
64 bytes from 192.168.XXX.XXX: icmp_req=1 ttl=58 time=7.88 ms 
64 bytes from 192.168.XXX.XXX: icmp_req=2 ttl=58 time=2.55 ms 
64 bytes from 192.168.XXX.XXX: icmp_req=3 ttl=58 time=2.97 ms 
64 bytes from 192.168.XXX.XXX: icmp_req=4 ttl=58 time=3.16 ms 

--- 192.168.XXX.XXX ping statistics --- 
4 packets transmitted, 4 received, 0% packet loss, time 3004ms 
rtt min/avg/max/mdev = 2.553/4.146/7.886/2.171 ms 
mbelda@pc:~$ nmap -PN -T4 -p1-65535 --max-retries 1 --min-parallelism 70 \
     --initial-rtt-timeout 5 192.168.XXX.XXX 

[...]

La primera vez que lo ejecuté tuve un resultado peor del esperado, ya que conocía qué puertos tenían que estar abiertos en el sistema auditado, así que comencé a investigar por qué aparecían menos puertos. Volví a lanzar el escaneo pero mostrando mayor información sobre el proceso, aumentando el nivel de debugging y de verbosity, pulsando las teclas d y v.

mbelda@pc:~$ nmap -PN -T4 -p1-65535 --max-retries 1 --min-parallelism 70 \
     --initial-rtt-timeout 5 192.168.XXX.XXX 

Starting Nmap 5.20 ( http://nmap.org ) at 2012-03-23 08:35 CET 
Verbosity Increased to 1. 
Verbosity Increased to 2. 
Verbosity Increased to 3. 
Initiating Connect Scan at 08:35 
Scanning 192.168.XXX.XXX (192.168.XXX.XXX) [65535 ports] 
Discovered open port 22/tcp on 192.168.XXX.XXX 
Verbosity Increased to 4. 
Verbosity Decreased to 3. 
Debugging Increased to 1. 
Debugging Increased to 2. 
Ultrascan PING SENT to 192.168.XXX.XXX [connect to port 113] 
Ultrascan DROPPED PING probe packet to 192.168.XXX.XXX detected 
Ultrascan PING SENT to 192.168.XXX.XXX [connect to port 113] 
Ultrascan DROPPED PING probe packet to 192.168.XXX.XXX detected 
Ultrascan PING SENT to 192.168.XXX.XXX [connect to port 113] 
Ultrascan DROPPED PING probe packet to 192.168.XXX.XXX detected 
Increasing send delay for 192.168.XXX.XXX from 0 to 5 due to 11 out of 13 dropped 
     probes since last increase. 
Ultrascan PING SENT to 192.168.XXX.XXX [connect to port 113] 
Ultrascan DROPPED PING probe packet to 192.168.XXX.XXX detected 
Ultrascan PING SENT to 192.168.XXX.XXX [connect to port 113] 
Ultrascan DROPPED PING probe packet to 192.168.XXX.XXX detected 

Entre los paquetes que se enviaban a los diferentes puertos para determinar si éstos estaban abiertos o no, advertí que se repetía periódicamente un paquete un servicio concreto. Repasando la documentación de Nmap (gracias José Luis), descubrí que este paquete formaba parte del proceso de cálculo dinámico del RTT, el tiempo de espera estimado en el que un paquete tardaría en ir y llegar su respuesta.

Nmap tiene un sistema que calcula dinámicamente este valor RTT tendiendo en cuenta los valores por defecto o los que hayamos definido como inicial o máximo, como se comenta al inicio del artículo. Básicamente, el sistema comienza con un tiempo inicial; una vez ha detectado un servicio ­abierto o cerrado­ realiza sondeos periódicos cada 1.25 segundos para ajustar el valor del RTT. Si ocurre una congestión en la red o baja el ancho de banda ocupado, este valor se puede ajustar a la situación de la red de manera dinámica. En la captura anterior se observa cómo se aumenta el tiempo “de 0 a 5” debido a no recibir 11 de las 13 últimas pruebas.

Volviendo al caso que nos ocupa, ocurría una cosa curiosa que provocaba que los puertos detectados no fueran los correctos. El puerto que detectaba como filtrado y, por tanto, que tomaba como referencia, era el 113/tcp, un puerto bloqueado habitualmente por la mayoría de cortafuegos (o al menos por el que había delante de nuestro objetivo). De esta forma, el dispositivo que respondía a este servicio era un firewall que estaba por delante del activo auditado y, por tanto, a una distancia menor que el segundo. Como se configuraba el tiempo de espera de forma automática a un valor menor del que era de esperar todos los tiempos expiraban antes de que llegara la respuesta de los servicios abiertos en el activo auditado.

Este puerto que se toma de referencia no se puede fijar por el usuario por lo que, tras varios intentos, siempre utilizaba el mismo y siempre daba el mismo resultado. Una solución era evitar este puerto, excluyéndolo del rango auditado, para que tomase otro puerto como referencia del RTT.

Otra solución que propongo, de la que no tengo constancia de que se haya tratado anteriormente, es poder definir qué puerto queremos tomar como referencia. En este caso, cuando conocíamos ya un servicio abierto en el puerto 22, poder decirle con un parámetro del estilo --rtt-reference-port 22 que lo coja como referencia para el cálculo del RTT.

Si alguien se ha encontrado en una situación similar o se le ocurre otra solución, que lo comente.