4 abr 2011

Udp scan

Buenas, en el post de hoy vamos a hablar sobre escaneo Udp, un tipo de Scan que no se suele usar tanto como los SYN, TCP connect..Usaremos las herramientas Nmap y UnicornScan, para capturar la salida usaremos Tcpdump y una opción de Nmap.

Antes de nada vamos a ver algunas características de UDP:

  • No orientado a conexión, por lo tanto menos confiable.
  • Más rápido y eficiente que TCP.
  • Confía en la aplicación para que se encargue de la correcta trasmisión de los datos
  • Usado en protocolos como SNMP, TFTP, DCHP, DNS, streaming de voz y audio, VoIP.
 

CABECERA UDP:

 

 

Cómo podemos ver es mucho más simple que la cabecera TCP. Al no tener Flags los Scans van a ser mucho más limitados en opciones. Al ser un protocolo no orientado a conexión el scan no va a ser tan fiable como TCP.En determinados S.O un Scaneo completo llegaría a tardar más de 18 horas ya que están limitados a mandar un paquete ICMP por segundo.

Durante toda la fase vamos a escanear el Host Windows (192.168.1.80) desde Backtrack4 R2 en VMWare (192.168.1.2)En nmap he usado las siguientes opciones:

 

--reason: nos indica la respuesta del Host, Syn-Ack, RST, no response..--packet-trace: para ver cada paquete que enviamos  y recibimos

 

Para que la salida no tenga mucha "basura" he usado:

 

-n: no resolver nombres--send-ip: mandar PING ICMP y TCP ACK al puerto 80 (por defecto en LAN Nmap usa PING ARP)-PN: no mandar ping

 

Vamos con las pruebas!!

Puerto 137 UDP abierto :

La aplicación nos responde correctamente a través del puerto 137, Netbios-Ns.

RCVD (0.0570s) UDP 192.168.1.80:137 > 192.168.1.2:45351 ttl=128 id=32697 iplen=239

 

Puerto 137 UDP abierto firewalled:

 

No obtenemos respuesta alguna, sin embargo Nmap lo indica como open|filtered ya que no conoce su estado real.

 

Puerto abierto TFTP 69:

 

En ésta captura podemos ver cómo Nmap no consigue detectar el estado real, en cambio Unicornscan si, hemos obtenido la respuesta al puerto 52388 UDP.

06:09:59.998373 IP 192.168.1.80.63962 > 192.168.1.2.7989: UDP, length 20

 

Vamos a ver ahora por qué Nmap no obtiene respuesta estando el puerto 69 abierto:

 

 

Cómo vemos en Wireshark, el paquete que manda Nmap no ha sido entendido por la aplicación, por lo tanto no nos contesta.

 

Puerto SNMP 161 cerrado :

 

 

Ésta vez obtenemos la respuesta normal de un puerto cerrado, ICMP Destination UnreacheableType 3 Code 3.

RCVD (0.0570s) ICMP 192.168.1.80 > 192.168.1.2 Port 161 unreachable (type=3/code=3) ttl=128 id=32729 iplen=116

 

Podéis ver todos los tipos y códigos de ICMP más detallados aquí: http://www.iana.org/assignments/icmp-parameters

 

Puerto SNMP 161 cerrado firewalled :

 

 

El Firewall bloquea todas las peticiones por lo tanto no obtenemos respuesta.

 

Conclusiones:

  • Hemos visto que los puertos abiertos no responden siempre, por lo tanto podríamos pensar que están filtrados; es más complicado conocer el estado real.
  • Un puerto cerrado siempre nos mandará un ICMP Destination Unreacheable.
  • Un puerto filtrado nos puede devolver códigos ICMP Type 3 Code 1/2/9/10/13.
 saludos! @Jos3_4ngel

2 comentarios: