Después de mucho tiempo, Nmap esta sumando payloads UDP a sus últimas versiones, y finalmente el port scanning de puertos UDP sirve para algo.
El scanning de puertos UDP siempre fue considerado un "scanning negativo", ya que solo podíamos estar seguros de los puertos que se encontraban en estado cerrado.
Como UDP no es un protocolo orientado a conexión como TCP, la única respuesta que podíamos recibir del puerto objetivo, era un mensaje de ICMP Port Unreacheable, cuando este se encontraba en estado cerrado, "closed".
Cuando el puerto se encontraba en estado abierto o filtrado, "open|filtered" en Nmap, no recibiríamos ninguna respuesta, porque el paquete UDP enviado no tenía ningún contenido, no tenía payload. En el caso de que existiera un firewall, que por su política descarte el paquete, tampoco recibiríamos ninguna respuesta.
Pero eso era hasta hace poco, cuando todavía no se habían incorporado payloads. Ahora en cambio, es mas factible que podamos identificar puertos UDP abiertos, ya que al enviarle datos de la aplicación, esta debería responder, y allí lograríamos detectar que el puerto se encuentra abierto:
El scanning de puertos UDP siempre fue considerado un "scanning negativo", ya que solo podíamos estar seguros de los puertos que se encontraban en estado cerrado.
Como UDP no es un protocolo orientado a conexión como TCP, la única respuesta que podíamos recibir del puerto objetivo, era un mensaje de ICMP Port Unreacheable, cuando este se encontraba en estado cerrado, "closed".
Cuando el puerto se encontraba en estado abierto o filtrado, "open|filtered" en Nmap, no recibiríamos ninguna respuesta, porque el paquete UDP enviado no tenía ningún contenido, no tenía payload. En el caso de que existiera un firewall, que por su política descarte el paquete, tampoco recibiríamos ninguna respuesta.
Pero eso era hasta hace poco, cuando todavía no se habían incorporado payloads. Ahora en cambio, es mas factible que podamos identificar puertos UDP abiertos, ya que al enviarle datos de la aplicación, esta debería responder, y allí lograríamos detectar que el puerto se encuentra abierto:
root@base4:~# nmap -sU -p 161,5353,31337 10.168.0.245 Starting Nmap 5.20 ( http://nmap.org ) at 2010-01-26 04:21 ARST Nmap scan report for 10.168.0.245 Host is up (0.0049s latency). PORT STATE SERVICE 161/udp open|filtered snmp 5353/udp open zeroconf 31337/udp closed BackOrifice MAC Address: 18:A9:05:FC:B5:09 (Hewlett Packard) Nmap done: 1 IP address (1 host up) scanned in 1.30 seconds root@base4:~#
En este ejemplo, realizamos el scanning a los puertos 161, 5353 y 31337 de UDP. Nmap reconoce los puertos, y envía un payload de SNMP al puerto 161 y de MDNS al puerto 5353, al puerto 31337 envía el paquete UDP vacío ya que desconoce cual es la aplicación. Veamos las respuestas:
En las respuestas, podemos identificar un ICMP Port Unreachable del puerto 31337, lo que nos indica que el puerto esta cerrado, una respuesta de MDNS, que nos indica que el puerto esta abierto, y ninguna respuesta del paquete SNMP, por eso Nmap nos muestra a ese puerto en estado "open|filtered".
Enviar un payload a un puerto no necesariamente nos dirá si este se encuentra abierto, en el caso de SNMP por ejemplo, en donde no recibimos ninguna respuesta, no sabemos si un firewall descarto el paquete, o si el payload no era correcto. Tal vez SNMP estaba corriendo, pero la community enviada por Nmap no era válida, o la versión de SNMP utilizada era otra.
POSTS RELACIONADOS:
- Nmap actualiza su PING
- Cómo Optimizar el Host Discovery en Nmap
- Nunca Confíes En Tus Herramientas
- ¿ Porque Nmap es Lento con Redes Muy Filtradas ?
- PortBunny y la Guerra de los Port Scanners
POSTS RELACIONADOS:
- Nmap actualiza su PING
- Cómo Optimizar el Host Discovery en Nmap
- Nunca Confíes En Tus Herramientas
- ¿ Porque Nmap es Lento con Redes Muy Filtradas ?
- PortBunny y la Guerra de los Port Scanners
Publicado por Leonardo Pigñer en KungFooSion.blogspot.com
No hay comentarios.:
Publicar un comentario