Logo de NAUTOPIA y de la Comunidad Nautópata    NAUTOPIA: Privacidad, Seguridad y Libertades Civiles    Foro Local de Tarragona

  

ANILLO     CONTACTAR    CULTURALIA     DOWNLOADS    KIOSKO    FORO         HOME
 

 Translate 
 

 

contacto de Alfon

 

TALLER de TcpDump / WinDump.

Analizando la Red

 

CAPÍTULO I: INTRODUCCION / EMPEZANDO CON WINDUMP

 

1. INTRODUCCION

Una de las actividades más comunes en la administación de una red o administración de seguridad, es la del análisis de tráfico de dicha red. No sólo el tráfico que fluye a través de nuestra LAN, sino que también debemos analizar el tráfico entrante y saliente hacia INTERNET a tráves de los servicios que tengamos instalados, proxies, etc. Esto es así, porque, como ya sabéis, es necesario para la detección de problemas y, sobre todo, para detectar tráfico no esperado, presencia de puertas traseras, escaneos y cualquier otra intrusión.

Existen muchas herramientas que pueden sernos muy últiles dependiendo del S.O. y tipo de red, por ejemplo. Una de estas herramientas es un sniffer de red, basada en la librería de captura de paquetes (pcap) y que además funciona en plataformas tanto Windows como GNU/Linux-UNIX es TCPDump (GNU/Linux) / Windump (Windows), ésta última hace uso de la librería Winpcap.

Estas dos librerías son usadas por otras herramientas como Ethereal o Snort, e incluyen un lenguaje de filtros común para todos. Quizás Windump/TCPDump no sea la herramienta perfecta atendiendo a la interpretación fácil de los datos reportados, pero sí que es de las mejores en cuanto a su potencia y cantidad de datos de que nos provee.

 

Una vez instalada la librería y el programa en sí, tan sólo debemos introducir en la línea de comandos (haremos referencia a Windump, para windows, aunque casi todo es válido para su versión GNU/Linux):

C:\scan>windump
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A
17:18:16.375082 FIERY.138 > 192.168.4.255.138:
>>> NBT UDP PACKET(138) Res=0x1102 ID=0xE IP=192 (0xc0
0xeb) Port=138 (0x8a) Length=187 (0xbb) Res2=0x0
SourceName=FIERY X2E NameType=0x00 (Workstation)
DestName=
WARNING: Short packet. Try increasing the snap length

17:18:16.679312 INFO2.1027 > INFO8.3233: udp 256
17:18:16.792878 arp who-has FIERY tell INFOGRAFIA3
17:18:16.793204 arp reply FIERY is-at 0:c0:85:27:39:15
17:18:16.793217 INFOGRAFIA3.137 > FIERY.137:
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:18:16.793729 FIERY.137 > INFOGRAFIA3.137:
>>> NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
17:18:16.898314 INFO8.3233 > INFO2.3234: udp 256
17:18:17.185571 0:a0:c9:1c:c1:f5 > Broadcast sap e0 ui/C
>>> Unknown IPX Data: (43 bytes)

Vaya, aparte de unas peticiones ARP, parece que no nos enteramos de casi nada. Windump capturará TODOS los datos de tráfico de nuestra red, pudiendo ser que los datos a través de la consola vayan tan rápidos y de tal cantidad, que nos sea imposible descifrar o simplemente entender algo.Veamos entonces cómo funciona Windump, cómo interpretar sus datos y cómo sacar el máximo partido de él.

 

 

2. EMPEZANDO CON WINDUMP

Hay que decir que Windump interpreta los datos dependiendo del protocolo involucrado en la captura, esto es obvio, ya que no es lo mismo una captura de consulta DNS que un inicio de sesión o establecimiento de conexión TCP, o una captura icmp, aunque las diferencias, en algunos casos, son pocas. En una captura icmp aparece la palabra icmp, sin embargo en una captura tcp no aparece esta palabra.

 

Establecimiento de una conexión TCP

9:24:00.494825 INFOGRAFIA3.1087 > ABANCECOMU.8080: S 2740385268:2740385268(0) w
in 64240 <mss 1460,nop,nop,sackOK> (DF)

09:24:00.495018 ABANCECOMU.8080 > INFOGRAFIA3.1087: S 4260015886:4260015886(0) a
ck 2740385269 win 64240 <mss 1460,nop,nop,sackOK> (DF)

09:24:00.495039 INFOGRAFIA3.1087 > ABANCECOMU.8080: . ack 1 win 64240 (DF)

Estas tres trazas se refieren a un inicio de sesión de TCP. En este caso INFOGRAFIA3 (que soy yo mismo) quiere iniciar una sesión con ABANCECOMU al proxy establecido en él para consultar una determinda página web usando http. Vemos el modelo de establecimiento de conexión a tres bandas de forma muy clara.

 

El formato para la salida de los datos es el siguiente:

  • fecha src > dst: flags data-sqno ack window urgent options

  • fecha nos da la hora en que se produjo el evento en formato hora:minutos:segundos.microsegundos o milisegundos

  • src y dst son las direcciones IP y puertos TCP/UDP de las conexiones fuente y destino.

  • > dirección del flujo de los datos

  • flags son una combinación de los posibles banderas de un segmento/datagrama TCP/UDP: S (SYN), F (FIN), P (PUSH), R (RST) y "." (no hay flags).

  • data-sqno describe el número de secuencia de la porción de datos.

  • ack es el número de secuencia del próximo byte que espera recibir el otro extremo TCP/UDP.

  • window es el tamaño de la ventana que advierte el receptor al transmisor.

  • urgent indica que hay datos urgentes en ese segmento/datagrama.

  • options son las opciones TCP que suelen estar entre corchetes del tipo < >, por ejemplo, el tamaño máximo del segmento (ej. <mss 1460,nop,nop,sackOK> ).

NOTA: En algunas salidas de Windump veremos una notación más: (DF). Este símbolo es el indicador de no fragmentación (Don't Fragment).

 

Hemos dicho que el ejemplo anterior trata de una conexión TCP. Pero ¿cómo se realiza esta?:

Una conexión TCP se realiza en tres pasos. Es lo que técnicamente se llama three-way handshake:

  1. En el sistema / host que inicia la conexión o cliente (INFOGRAFIA3.1087), envía un paquete de SYN con un número de secuencia inicial (740385268) y final (740385268) asociado a esta conexión al sistema / host destinatario o servidor (ABANCECOMU.8080). Como no se transmiten datos, el número de secuencia inicial y final son los mismos y los datos 0 (0).

  2. Este responde con un paquete SYN-ACK (acuse de recibo) confirmando la recepción del SYN inicial enviado por (INFOGRAFIA3.1087) y enviándole a su vez su propio número de secuencia inicial (4260015886) y final (4260015886) y ACK+1 (2740385269). Estos números de secuencias son absolutos. Windump / TCPDump, para evitar mostrar números demasiado grandes, muestra números de secuencia relativos. En el paso siguiente sucede lo mismo.

  3. Para finalizar, el cliente (INFOGRAFIA3.1087) reconoce la recepción del SYN del servidor (ABANCECOMU.8080) mediante el envío de un ACK (1). Vemos que hay un ".", con lo que deducimos que no hay flag (en este caso SYN). Este es el momento en que queda establecida la conexión. Ya se puede iniciar la transferencia de datos entre (INFOGRAFIA3.1087) y (ABANCECOMU.8080).

*Veremos más adelante, capturas de consultas DNS, UDP, escaneos de puertos, troyanos, etc.

 

Algunas opciones de Windump

  • Para ver las interfaces de que disponemos:
C:\scan>windump -D
1.\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF} (3Com EtherLink PCI)
2.\Device\Packet_NdisWanIp (NdisWan Adapter)
  • Si queremos usar la interface 1:
C:\scan>windump -i 1
  • No quiero que me resuelva los nombres de host.
C:\scan>windump -n
  • Cantidad de información que nos devuelve.
C:\scan>windump -v o -vv

 

Clarificando los resultados

Windump incluye opciones para resumir, clarificar que sean más entendibles los datos de salida. Por ejemplo, podemos:

  • eliminar las marcas de tiempo -t (como comentamos antes)
  • podemos usar -n para no resolver los nombres de host
  • -q estableceremos el indicador de salida rápida que hará que nos devuelva menos información y que las líneas sean más cortas
C:\scan>windump -qnt host INFOGRAFIA5
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
192.168.4.5.2073 > 192.168.4.15.110: tcp 0 (DF)
192.168.4.15.110 > 192.168.4.5.2073: tcp 0
192.168.4.5.2073 > 192.168.4.15.110: tcp 0 (DF)
192.168.4.15.110 > 192.168.4.5.2073: tcp 88
192.168.4.5.2073 > 192.168.4.15.110: tcp 14 (DF)
192.168.4.15.110 > 192.168.4.5.2073: tcp 29
192.168.4.5.2073 > 192.168.4.15.110: tcp 14 (DF)
192.168.4.15.110 > 192.168.4.5.2073: tcp 0
192.168.4.15.110 > 192.168.4.5.2073: tcp 66
192.168.4.5.2073 > 192.168.4.15.110: tcp 6 (DF)
192.168.4.15.110 > 192.168.4.5.2073: tcp 9
192.168.4.5.2073 > 192.168.4.15.110: tcp 6 (DF)
192.168.4.15.110 > 192.168.4.5.2073: tcp 72
192.168.4.5.2073 > 192.168.4.15.110: tcp 0 (DF)
192.168.4.15.110 > 192.168.4.5.2073: tcp 0
192.168.4.15.110 > 192.168.4.5.2073: tcp 0
192.168.4.5.2073 > 192.168.4.15.110: tcp 0 (DF)

20551 packets received by filter
0 packets dropped by kernel

 

Filtros de Windump

Puede ser que no nos interese ver todo el tráfico, sino sólo un determinado protocolo o un sólo host, etc.

  • Captura el tráfico de origen y destino sólo en el host INFOGRAFIA3 (se puede poner también la IP)
C:\scan>windump host INFOGRAFIA3
  • Captura el tráfico de origen host INFOGRAFIA3
C:\scan>windump src host INFOGRAFIA3
  • Captura todo el tráfico cuyo puerto de destino sea 8080
C:\scan>windump dst port 8080
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
09:50:18.618057 INFOGRAFIA3.3039 > ABANCECOMU.8080: S 3194034207:3194034207(0) w
in 64240 <mss 1460,nop,nop,sackOK> (DF)
09:50:18.618224 INFOGRAFIA3.3039 > ABANCECOMU.8080: . ack 1114838386 win 64240 (DF)
09:50:18.643251 INFOGRAFIA3.3039 > ABANCECOMU.8080: P 0:611(611) ack 1 win 64240
(DF)
  • Captura todo el tráfico cuyo puerto de origen o destino sea 8080
C:\scan>windump port 8080
  • Captura todo el tráfico icmp
C:\scan>windump icmp
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
09:53:00.509648 SERVING > 192.168.2.75: icmp: echo request
09:53:00.509729 192.168.2.75 > SERVING: icmp: echo reply
09:53:00.811224 SERVING > INGEN12: icmp: echo request
09:53:00.811410 INGEN12 > SERVING: icmp: echo reply
  • Combinando filtros
C:\scan>windump tcp and port 8080 windump: listening on\Device\Packet_
{604C8AE3-5FAC-45A5-BFAA-8117
09:55:49.116908 ABANCECOMU.8080 > INFO8.3132: P 1224555679:122455 805272 win 63910
09:55:49.119780 ABANCECOMU.8080 > INFO8.3132: FP 348:802(454) ack
09:55:49.119872 INFO8.3132 > ABANCECOMU.8080: . ack 803 win 7958
09:55:49.211881 INFO8.3132 > ABANCECOMU.8080: F 1:1(0) ack 803 wi
09:55:49.211970 ABANCECOMU.8080 > INFO8.3132: . ack 2 win 63910

 

Caso práctico 1

Análisis de un scaneo -sT con nmap con puerto destino cerrado.

Se trata de un escaneo usando paquetes TCP. Tipo de escaneo TCP Conect(). El destino puede logear nuestra IP, ya que se realiza una conexión completa con la máquina destino.Permite saber rápidamente si el puerto está o no abierto en la máquina destino.

  • si recibe un RST/ACK el puerto está cerrado
  • si recibe un SYN/ACK el puerto está abierto --> envía un ACK estableciendo conexión

Lo vemos mejor con Windump:

08:24:18.393108 INFOGRAFIA3.1024 > ABANCECOMU.8021: S 2632227152:2632227152(0)
    win 16060 <mss 1460,sackOK,timestamp 232602[|tcp]> (DF)

08:24:18.393167 ABANCECOMU.8021 > INFOGRAFIA3.1024: R 0:0(0) ack 2632227153 win 0

Análisis posterior. Grabando los datos.

Windump puede grabar los datos para su posterior análisis. Utilizaremos para ello el comando -w para grabar y -r para abrirlos.

C:\scan>windump -r ficherosalida port 8080
C:\scan>windump -w ficherosalida port 8080

Podemos grabar todo el tráfico y extraer sólo lo que nos haga falta.

C:\scan>windump -r fichero_todoeltrafico
C:\scan>windump -w fichero_todoeltrafico host 192.168.4.5

 

Filtros de Windump. Filtros avanzados y concatenaciones lógicas

Para filtrar y clarificar nuestros resultados podemos hacer uso de filtros más avanzados y utilizar operadores lógicos.

C:\scan >windump not host INFOGRAFIA3 and not icmp
C:\>windump host INFOGRAFIA3 and not port 80

Vemos claramente que para unir operadores lógicos usamos and. Para negar not.

 

Uso de net para análisis de subredes

C:\scan>windump -q net 192.168.1.0/24
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
14:29:06.928153 TALLER > 192.168.1.150: icmp: echo request
14:29:07.007512 INFOGRAFIA3.137 > 192.168.1.150.137: udp 50
14:29:07.302233 TALLER > 192.168.1.151: icmp: echo request
14:29:08.508098 INFOGRAFIA3.137 > 192.168.1.150.137: udp 50
14:29:10.008880 INFOGRAFIA3.137 > 192.168.1.150.137: udp 50
14:29:12.681969 INFOGRAFIA3.137 > 192.168.1.151.137: udp 50
14:29:14.182186 INFOGRAFIA3.137 > 192.168.1.151.137: udp 50
14:29:15.682984 INFOGRAFIA3.137 > 192.168.1.151.137: udp 50
14:30:07.013599 TALLER > 192.168.1.150: icmp: echo request
14:30:07.386074 TALLER > 192.168.1.151: icmp: echo request
14:30:23.674162

13811 packets received by filter
0 packets dropped by kernel

 

 

- TALLER de: TcpDump / WinDump -

 
 

 
 
 

NAUTOPIA © 2003. Reservados todos los derechos.