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:

Como 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 Unreacheable
Type 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.

Fuente: Flu Project

Share

This entry was posted in aprendizaje, protocolos, scanners. Bookmark the permalink.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

If you agree to these terms, please click here.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.