nmap es exponencialmente lento al escanear más puertos

nmap es exponencialmente lento al escanear más puertos

A veces uso nmap para comprobar mis hosts. Por ejemplo: nmap -sS -p- example.com
Pero este comando nunca termina.

Así que divido el escaneo en partes pequeñas: nmap -sS -p 0-999 example.com(12 segundos para finalizar)
y luego nmap -sS -p 1000-1999 example.com(14 segundos para finalizar), etc. Esto es tedioso.

Si utiliza piezas más anchas: nmap -sS -p 0-3999 example.com
tarda más de 3 minutos en terminar.

Y con nmap -sS -p 0-7999 example.comello no se termina después de 30 minutos.

Entonces:
1000 puertos -> 12 segundos
4000 puertos -> 3 minutos
9000 puertos -> 30 minutos

¿Cuál es el problema?
¿Cómo puedo encontrar puertos TCP abiertos para un host con nmap?

Respuesta1

Nmap hace todo lo posible para encontrar la velocidad a la que puede encontrar con precisión el estado (abierto, cerrado o filtrado) de cada puerto. El sistema de cronometraje es complejo y tiene algunos de los peores escenarios que pueden provocar escaneos muy lentos. Uno de estos casos es cuando el objetivo son los restablecimientos de conexión TCP (RST) que limitan la velocidad, que son las respuestas que recibe Nmap cuando se cierra un puerto. La mayoría de los puertos de un sistema suelen estar cerrados y, para ahorrar recursos o quizás obstaculizar los intentos de escaneo, el sistema operativo del objetivo puede optar por emitir solo un RST una vez por segundo.

Cuando Nmap detecta una limitación de la velocidad de RST, debe reducir la velocidad de sus sondas para igualar esa velocidad; de lo contrario, un puerto cerrado puede marcarse como "filtrado" porque no se recibió respuesta, lo que es consistente con un firewall que descarta el tráfico a ese puerto. Este comportamiento de desaceleración ocurre gradualmente, por lo que los primeros puertos no se ven tan afectados como los posteriores. Además, solo afecta a los puertos cerrados, por lo que es menos probable que los puertos comúnmente utilizados entre 1 y 1000 contribuyan a la lentitud.

Existe una solución para este problema, pero conlleva una pérdida de precisión. Si no le interesa conocer la diferencia entre puertos filtrados y cerrados, puede usar la --defeat-rst-ratelimitopción para no permitir que los RST de velocidad limitada afecten la sincronización de Nmap. Nmap continuará enviando a una velocidad adecuada para la red, detectando paquetes perdidos y ralentizándolos cuando sea necesario, pero estando perfectamente contento marcando los puertos cerrados como filtrados. El conjunto de puertos abiertos debería ser exactamente el mismo, que es todo lo que la mayoría de la gente quiere. De hecho, incluso puede agregar --openpara evitar imprimir información sobre puertos cerrados y filtrados.

Respuesta2

Puede agregar la -T5opción para aumentar la velocidad de escaneo. De acuerdo anmap Temporización y rendimientose recomienda utilizar -T4la opción:

Recomendaría usar siempre -T4. A algunas personas les encanta -T5, aunque es demasiado agresivo para mi gusto. A veces las personas especifican -T2 porque piensan que es menos probable que los hosts fallen o porque se consideran educados en general. A menudo no se dan cuenta de lo lento que es en realidad -T cortés. Su análisis puede tardar diez veces más que un análisis predeterminado. Los fallos de la máquina y los problemas de ancho de banda son raros con las opciones de sincronización predeterminadas (-T3), por lo que normalmente lo recomiendo para escáneres cautelosos. Omitir la detección de versiones es mucho más eficaz que jugar con los valores de tiempo para reducir estos problemas.

Respuesta3

Intente ejecutar nmap con -v(detallado) para ayudarle a descubrir por qué hay una desaceleración.

Al ejecutarlo nmap -sS -Pn -v -p 1-9999 myserver.comen uno de mis propios servidores, se obtiene lo siguiente en algún lugar después de 3000 puertos:

Increasing send delay for (ip address) from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for (ip address) from 5 to 10 due to 17 out of 55 dropped probes since last increase.
[...]
Increasing send delay for (ip address) from 160 to 320 due to 11 out of 31 dropped probes since last increase.
SYN Stealth Scan Timing: About 17.08% done; ETC: 13:17 (0:02:30 remaining)

Estos mensajes no parecen aparecer debajo del puerto 1024.

información relacionada