Analizando la Red con WinDump / TCPDump. (I Parte)

Introducción

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.

Introducción

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 de 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, a parte de unas peticiones ARP, parece que no nos enteramos de casi nada. A aparte de esto Windump capturará TODOS los datos de tráfico de nuestra red, y puede ser que los datos a través de la consola vayan tan rápido y de tal cantidad, que nos sea imposible descifrar o simplemente entender algo.Veamos entonces cómo funciona Windump, como interpretar sus datos y cómo sacar el máximo partido de él.

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 CONEXION TCP:

9:24:00.494825 INFOGRAFIA3.1087 > ABANCECOMU.8080: S 2740385268:2740385268(0) w
in 64240 (DF)

09:24:00.495018 ABANCECOMU.8080 > INFOGRAFIA3.1087: S 4260015886:4260015886(0) a
ck 2740385269 win 64240 (DF)

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

Estas tres trazan 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 la siguiente:

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

* fecha nos da la hora en que se produjo el evento en formatohora:minutos:segundos.microsegundos o milisegundos
* src y dst son las direcciones IP y puertos TCP/UDP de las conexiones fuente ydestino.
* > dirección de 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. )

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 pasa esto 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 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 (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

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
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

Avanzando con los filtros

Ya comenté en el primer capítulo que Windump / TCPDump tiene filtros para su mejor manejo. Estos filtros pueden llegar a ser tan sofisticados como queramos y extraer cualquier tipo de datos de los datagramas, paquetes, etc que circulen a través de nuestra red.

Como la mejor manera de explicar el funcionamiento de los filtros es la práctica, vamos a analizar una combinación y encadenamiento de filtros con un ejemplo muy simple.

Ejemplo

Tenemos el servidor de correos un tanto colapsado, este servidor no aguanta demasiadas conexiones, o el tráfico es mayor de lo previsto. Analicemos entonces qué es lo que pasa. Vamos a crear un filtro para averiguar las conexiones al puerto 110 de nuestro servidor de correos.

C:\scan>windump -qn -X -s 0 tcp[13] = 2 and port 110

Aquí vemos algunas opciones ya comentadas y otras nuevas:

• –q establecemos el indicador de salida rápida que hará que nos devuelva menos información y que las líneas sean más cortas. Esto es así, porque, en realidad, sólo nos interesa los host/IP y las marcas de tiempo, ya que, como veremos más adelante, estamos filtrando establecimientos de conexión TCP al puerto 110.
• -n no resolver nombres de host
• -X vuelca en la consola los datos.
• -s 0 es el snaplen. A cero estamos cogiendo los paquetes completos. Si hubiéramos puesto -s 512 se capturarían sólo los primeros 512 bytes del paquete tcp.
• tcp[13] = 2 esta es la parte interesante. Con este filtro estamos diciendo a windump que queremos escoger los paquetes TCP cuyo indicador, bandera o flag sea SYN «S». Para entender esto hay que tener en cuenta cómo es el formato de una cabecera TCP, que los indicadores o flags se encuentran en el octeto 13.
• and port 110, unido a lo anterior, analizará el puerto 110. Podriamos añadir que lo hiciera sólo para un determinado host:and port 110 and host ALFON.

Vamos a echarle un ojo al octeto 13 y simulemos que el flag SYN está activo, pero antes, recordemos el Formato de la cabecera del TCP.

¿Qué significa realmente tcp[13] = 2?

En el flag SYN, que es utilizado para la sincronización de los números de la secuencia tendremos:

….U A P R S F
——————
0 0 0 0 0 0 1 0 (en binario)
——————
7 6 5 4 3 2 1 0

vemos que el byte 7 y 6 están reservados, el 5 es para URGENT, el 4 es para ACK, el 3 es para PUSH, el 2 es para RESET y el byte 0 para FIN. Tenemos entonces el octeto completo.

En binario quedaría como acabamos de ver: 0 0 0 0 0 0 1 0, que pasado a base decimal, vemos que es el 2, de ahí viene tcp[13] = 2.

*Es fácil deducir entonces que para detectar un SYN/ACK: 0 0 0 1 0 0 1 0, el 18 en base decimal, entonces tcp[13] = 18.

Lo vemos más claramente en las siguientes líneas.

La teoría

Antes que nada, decir que TCPDump usa el formato: proto[x:y] = valor para leer datos en cabeceras del os protocolos involucrados.

• proto (protocolo) puede ser ip, arp, rarp, tcp, udp, icmp, etc
• [x:y] x es el octeto ó byte de comienzo e y significa: «leer» y bytes a partir del byte x
• Si sólo aparece [x] es lo mismo que decir [x:1], es decir leer sólo el byte x, esto lo hace TCPDump por defecto.

Ya sabemos que significa cada uno de los valores. Vamos entonces a averiguar de dónde sacamos el 13 de la expresión tcp[13] = 2

Vamos a analizar la cabecera TCP del gráfico anterior por filas:

• puerto origen = 2 bytes u octetos o 16 bits
• puerto destino = 2 bytes u octetos. La cuenta siempre empieza por el 0, con lo cual los octetos van del 0 al 3
• número secuencia = 4 bytes u octetos, es decir del 4 al 7
• número acuse recibo = 4 bytes u octetos del 8 al 11

OJO: Tenemos doce octetos (0,1, …11) Hemos de tener en cuenta que se empieza a contar desde cero, es decir, el primer byte es el octeto 0.

El siguiente octeto es el 12 (el décimo tercero) va desde el bits 0 al 7 que corresponden a posición de datos u offset (4 bits) y a Reservado (4+2); dos bits de Reservado pertenecen ya al siguiente octeto el 13, que tiene los 2 bits reservados anteriores y 6 que son los flags (UAPRSF). 6 + 2 = 8 bits que es el octeto o byte 13 (o décimo cuarto).

Vamos a analizar ahora de donde viene el valor 2 de la expresión tcp[13] = 2

Esta es la representación de octeto ó byte 13. Si ponemos el flag SYN activado y el resto NO activados, resulta que SYN lo ponemos a 1 y el resto a 0:

Queda entonces: 0 0 0 0 0 0 1 0 (los dos primeros bits dijimos que eran reservados y siempre están a 0)

….U A P R S F
——————
0 0 0 0 0 0 1 0 (en binario)
——————
7 6 5 4 3 2 1 0

Si pasamos este número (0 0 0 0 0 0 1 0 ), que es binario, a decimal nos queda el número decimal 2 (2 elevado a 1), que es el valor que debemos de introducir para que la expresión quede así:

tcp[13] = 2

Esto le dice a windump o TCPDump que busque en la cabecera TCP el valor 2 que se encuentra en el byte u octeto 13. Y ya sabemos que corresponde al flag SYN activado (y los otros flags/banderas estarán desactivados).

Usando esta técnica, con windump o tcpdump, podríamos detectar escaneos y otras intrusiones en nuestros sistemas.

Siguiendo con el ejemplo práctico y quitando la opción -X que ahora es irrelevante:

C:\scan>windump -qn -s 0 tcp[13] = 2 and port 110
windump: listening on\Device\Packet_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
19:11:20.914698 192.168.2.71.1117 > 192.168.4.15.110: tcp 0 (DF)
19:11:22.442635 192.168.4.10.3531 > 192.168.4.15.110: tcp 0 (DF)
19:11:29.321747 192.168.2.90.2310 > 192.168.4.15.110: tcp 0 (DF)
19:11:29.350083 192.168.4.9.1392 > 192.168.4.15.110: tcp 0 (DF)
19:11:30.167786 192.168.2.9.1118 > 192.168.4.15.110: tcp 0 (DF)
19:11:40.848757 192.168.2.90.2311 > 192.168.4.15.110: tcp 0 (DF)
19:11:47.603914 192.168.2.70.1400 > 192.168.4.15.110: tcp 0 (DF)
19:11:48.692990 192.168.4.2.2349 > 192.168.4.15.110: tcp 0 (DF)
19:11:48.946846 192.168.4.2.2350 > 192.168.4.15.110: tcp 0 (DF)
19:11:49.167414 192.168.4.2.2351 > 192.168.4.15.110: tcp 0 (DF)
19:11:53.689934 192.168.4.11.2360 > 192.168.4.15.110: tcp 0 (DF)
19:12:21.576147 192.168.2.71.1118 > 192.168.4.15.110: tcp 0 (DF)
19:12:22.885469 192.168.4.10.3532 > 192.168.4.15.110: tcp 0 (DF)
19:12:29.776688 192.168.2.90.2312 > 192.168.4.15.110: tcp 0 (DF)
19:12:29.799274 192.168.4.9.1393 > 192.168.4.15.110: tcp 0 (DF)
19:12:41.142773 192.168.2.90.2313 > 192.168.4.15.110: tcp 0 (DF)
19:12:42.594882 192.168.4.2.2352 > 192.168.4.15.110: tcp 0 (DF)
19:12:42.828622 192.168.4.2.2353 > 192.168.4.15.110: tcp 0 (DF)
19:12:43.060723 192.168.4.2.2354 > 192.168.4.15.110: tcp 0 (DF)
19:12:47.896352 192.168.2.70.1401 > 192.168.4.15.110: tcp 0 (DF)

faltan muchas líneas pero podemos observar en éstas que algunos host tenían sus clientes de correo configurados para «mirar» el correo cada minuto. En la realidad fueron casi todos, con lo cual tenían el servidor bastante atareadillo.

NOTA: Como nota final decir, para los que me comentan por mail, que el Ethereal es mejor en algunos aspectos por ser gráfico y más intuitivo, pero que tanto Ethereal como TCPDUMP / WINDUMP se basan en la misma librería de captura de paquetes y por tanto para filtrar usan la MISMA sintaxis. Es decir, todo esto que os escribo es válido también para Ethereal (ahora WireShark).