Analizando la Red Con WinDump / TCPDump. (IV Parte). Avanzando en los Filtros

Introducción.

Vimos en los capítulos capítulo I y capítulo II los filtros avanzados de Windump / TCPDump y el uso del formato: proto[x:y] = valor para leer datos en cabeceras de protocolos a monitorizar. Por ejemplo:

C:\scan>windump icmp[0] = 8

En este capítulo vamos a seguir avanzando en ello y complicando los ejemplos y casos prácticos. Por ejemplo:

C:\scan>windump -qn “ip[0] & 0x0f > 5”

Formato de los filtros.

Antes que nada comentar que los filtros aquí explicados son válidos para aplicaciones como WireShark (antes Ethereal).

El formato genérico de los filtros es:

expresión relación expresión

relación puede ser >,= <=, = y !=

expresión puede ser el protocolo, una expresión aritmética, operadores binarios, etc,

De esta manera, si estudiamos el filtro del ejemplo de arriba:

C:\scan>windump icmp[0] = 8

  • vemos que la expresión es la palabra reservada icmp (protocolo) junto a un valor 0

  • la relación que es = y otra expresión cuyo valor es 8

Veamos otro ejemplo:

udp[0:2] < 1024

  • expresión udp[0:2]

  • relación <

  • expresión 1024

En la expresión udp[0:2], vemos el protocolo udp y unos valores, dentro de la misma expresión , [0:2]. Esto significa que se sitúe en el comienzo del octeto 0 o primer octeto de la cabecera udp y a partir de ahí lea 2 octeos, es decir, que lea el campo de “Puerto de origen”.

Estos dos octetos serían, según el gráfico de más abajo, los bits 0 al 15.

Filtros UDP

Filtros para protocolo UDP

Paquetes udp cuyo puerto de origen sean menor de 1024

C:\scan>windump “udp[0:2] < 1024"

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

11:02:51.453841 IP CCZ.137 > ABANCE-2.137: udp 68

11:02:51.928483 IP INFOGRAFIA3.137 > ABANCE-2.137: udp 50

11:02:51.928770 IP ABANCE-2.137 > INFOGRAFIA3.137: udp 337

11:02:51.931468 IP INFOGRAFIA3.137 > CCZ.137: udp 50

11:02:51.931630 IP INFOGRAFIA3.137 > CCZ.137: udp 50

11:02:51.931987 IP CCZ.137 > INFOGRAFIA3.137: udp 229

11:02:51.932133 IP CCZ.137 > INFOGRAFIA3.137: udp 229

11:02:52.956160 IP CCZ.137 > ABANCE-2.137: udp 68

11:02:54.458536 IP CCZ.137 > ABANCE-2.137: udp 68

11:02:59.421242 IP 192.168.5.6.137 > 192.168.5.255.137: udp 68

11:02:59.940882 IP INFOGRAFIA3.137 > 192.168.5.6.137: udp 50

11:03:00.168203 IP 192.168.5.6.137 > 192.168.5.255.137: udp 68

11:03:00.919331 IP 192.168.5.6.137 > 192.168.5.255.137: udp 68

11:03:01.440681 IP INFOGRAFIA3.137 > 192.168.5.6.137: udp 50

11:03:01.495085 IP SERVIMP.137 > 192.168.1.20.137: udp 68

11:03:01.670454 IP 192.168.5.6.137 > 192.168.5.255.137: udp 68

 

Paquetes udp cuyo puerto de destino sea mayor de 4000

C:\scan>windump “udp[2:2] > 4000”

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

11:08:49.417548 IP INFOGRAFIA5.1035 > 213.54.231.54.4665: udp 18

11:08:50.424627 IP INFOGRAFIA5.1035 > 213.54.231.54.4665: udp 18

11:08:51.417438 IP INFOGRAFIA5.1035 > 213.54.231.54.4665: udp 18

11:08:52.422087 IP INFOGRAFIA5.1035 > 213.54.231.54.4665: udp 18

11:08:53.423175 IP INFOGRAFIA5.1035 > 213.54.231.54.4665: udp 18

11:08:54.429816 IP INFOGRAFIA5.1035 > 213.54.231.54.4665: udp 18

11:08:56.427773 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:08:57.434055 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:08:58.462111 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:08:59.458277 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:00.469781 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:01.476682 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:02.463961 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:03.472875 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:04.465988 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:05.470583 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:06.477664 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:07.472918 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

11:09:08.474136 IP INFOGRAFIA5.1035 > 213.23.141.69.4665: udp 18

1161 packets received by filter

0 packets dropped by kernel

Otros filtros para udp:

udp[0:2] puerto origen

udp[2:2] puerto destino

udp[4:2] longitud datagrama

udp[6:2] Suma de comprobación

Filtros para IP

Para especificar una dirección IP tcpdump / windump trabaja mejor con el formato hexadecimal.

Para una dirección 192.168.4.15, su equivalente en hexadecimal sería:

192 > C0

168 > A8

4 > 04

15 > 0F

es decir:

C0A8040F

Para windump añadimos el indicativo de que se trata de formato hexadecimal:

0x

y nos quedaría:

0xC0A8040F

Apliquemos esto a nuestros ejemplos de filtros:

Datagramas IP cuyo IP de origen sea 0xC0A8040F o 192.168.4.15

C:\scan>windump “ip[12:4] = 0xC0A8040F”

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

11:58:18.330623 IP 192.168.4.15.1080 > INFOGRAFIA5.4288: P 1718835398:1718836858(1460)

ack 110490685 win 63972

11:58:18.470208 IP 192.168.4.15.1080 > INFOGRAFIA5.4288: P 1460:2600(1140) ack 1 win 63972

11:58:18.614849 IP 192.168.4.15.1080 > INFOGRAFIA5.2376: . ack 3733417890 win 64240

11:58:18.614857 IP 192.168.4.15.1080 > INFOGRAFIA5.4233: . ack 80965400 win 64240

11:58:19.415469 IP 192.168.4.15.1080 > INFOGRAFIA5.4288: P 2600:3900(1300) ack 1 win 63972

11:58:19.419619 IP 192.168.4.15.1080 > INFOGRAFIA5.2376: . ack 1301 win 62940

11:58:19.520221 IP 192.168.4.15.1080 > INFOGRAFIA5.4233: . ack 1301 win 62940

11:58:19.632523 IP 192.168.4.15.1080 > INFOGRAFIA5.4288: P 3900:5360(1460) ack 1 win 63972

11:58:19.774521 IP 192.168.4.15.1080 > INFOGRAFIA5.4288: P 5360:6500(1140) ack 1 win 63972

11:58:19.942664 IP 192.168.4.15.1080 > INFOGRAFIA5.4288: P 6500:7960(1460) ack 1 win 63972

11:58:19.966413 IP 192.168.4.15.8080 > INFOGRAFIA5.4509: S 1794965924:1794965924(0)

ack 169718740 win 64240

ss 1460,nop,nop,sackOK>

 

Datagramas IP cuyo IP de origen sea mayor que 192.168.4.15

C:\scan>windump -n “ip[12:4] > 0xC0A8040F”

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

12:02:18.737917 IP 192.168.5.241.3584 > 192.168.5.240.445: P 1920852500:1920852553(53)

ack 3198424692 win 6328

2 (DF)

12:02:18.738023 IP 192.168.5.240.445 > 192.168.5.241.3584: P 1:54(53) ack 53 win 63364 (DF)

12:02:18.874284 IP 192.168.5.241.3584 > 192.168.5.240.445: . ack 54 win 63229 (DF)

12:02:20.820682 IP 192.168.4.20.139 > 192.168.4.3.1030: P 9249826:9249869(43)

ack 3736451662 win 8083 (DF)

12:02:20.821064 IP 192.168.4.20.139 > 192.168.4.3.1030: P 43:166(123) ack 64 win 8020 (DF)

12:02:20.821274 IP 192.168.4.20.139 > 192.168.4.3.1030: P 166:238(72) ack 127 win 7957 (DF)

12:02:20.821482 IP 192.168.4.20.139 > 192.168.4.3.1030: P 238:326(88) ack 190 win 7894 (DF)

12:02:20.821717 IP 192.168.4.20.139 > 192.168.4.3.1030: P 326:377(51) ack 311 win 7773 (DF)

12:02:20.829142 IP 192.168.4.20.139 > 192.168.4.3.1030: P 377:420(43) ack 386 win 7698 (DF)

12:02:20.849320 IP 192.168.4.20.139 > 192.168.4.3.1030: P 420:463(43) ack 461 win 7623 (DF)

12:02:20.869278 IP 192.168.4.20.139 > 192.168.4.3.1030: P 463:586(123) ack 524 win 7560 (DF)

12:02:20.909565 IP 192.168.4.20.139 > 192.168.4.3.1030: P 586:658(72) ack 587 win 7497 (DF)

12:02:20.929615 IP 192.168.4.20.139 > 192.168.4.3.1030: P 658:709(51) ack 679 win 7405 (DF)

12:02:20.989665 IP 192.168.4.20.139 > 192.168.4.3.1030: P 709:760(51) ack 867 win 8760 (DF)

12:02:21.009875 IP 192.168.4.20.139 > 192.168.4.3.1030: P 760:811(51) ack 988 win 8639 (DF)

12:02:21.029763 IP 192.168.4.20.139 > 192.168.4.3.1030: P 811:854(43) ack 1063 win 8564 (DF)

12:02:21.653488 IP 192.168.4.20.139 > 192.168.4.5.1030: P 110179275:110179314(39)

ack 560248901 win 8450 (DF)

12:02:21.665478 IP 192.168.4.20.139 > 192.168.4.5.1030: P 39:78(39) ack 115 win 8336 (DF)

 

Datagramas IP cuyo valor TTL sea mayor que 5

C:\scan>windump -nt “ip[8] > 5”

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

IP 192.168.5.241 > 192.168.5.3: icmp 58: echo request seq 37706

IP 192.168.5.3 > 192.168.5.241: icmp 58: echo reply seq 37706

IP 192.168.4.10 > 192.168.4.14: icmp 58: echo request seq 8022

IP 192.168.4.14 > 192.168.4.10: icmp 58: echo reply seq 8022

IP 192.168.5.241 > 192.168.5.5: icmp 58: echo request seq 37962

IP 192.168.5.5 > 192.168.5.241: icmp 58: echo reply seq 37962

IP 192.168.5.241 > 192.168.5.6: icmp 58: echo request seq 38218

IP 192.168.5.6 > 192.168.5.241: icmp 58: echo reply seq 38218

IP 192.168.5.241 > 192.168.5.7: icmp 58: echo request seq 38474

IP 192.168.5.7 > 192.168.5.241: icmp 58: echo reply seq 38474

IP 192.168.2.4.1025 > 192.168.2.1.139: P 5539816:5539880(64) ack 34107477 win 8760 (DF)

IP 192.168.2.1.139 > 192.168.2.4.1025: . 1:1461(1460) ack 64 win 8568 (DF)

IP 192.168.2.1.139 > 192.168.2.4.1025: P 1461:2113(652) ack 64 win 8568 (DF)

IP 192.168.2.4.1025 > 192.168.2.1.139: . ack 2113 win 8760 (DF)

IP 192.168.2.4.1025 > 192.168.2.1.139: P 64:128(64) ack 2113 win 8760 (DF)

IP 192.168.2.1.139 > 192.168.2.4.1025: . 2113:3573(1460) ack 128 win 8504 (DF)

IP 192.168.2.1.139 > 192.168.2.4.1025: P 3573:4225(652) ack 128 win 8504 (DF)

IP 192.168.2.4.1025 > 192.168.2.1.139: . ack 4225 win 8760 (DF)

IP 192.168.5.241 > 192.168.5.12: icmp 58: echo request seq 39754

IP 192.168.5.12 > 192.168.5.241: icmp 58: echo reply seq 39754

IP 192.168.2.2 > 192.168.2.10: icmp 58: echo request seq 17671

IP 192.168.2.10 > 192.168.2.2: icmp 58: echo reply seq 17671

IP 192.168.2.2 > 192.168.2.11: icmp 58: echo request seq 17927

IP 192.168.2.11 > 192.168.2.2: icmp 58: echo reply seq 17927

CREACIÓN DE MÁSCARAS PARA FILTROS

Ocurre que en ocasiones nos encontramos con un byte que está dividido en dos partes, es decir, en dos campos de 4 bits cada uno.

Todo lo comentado anteriormente referente a filtros para extraer datos de las cabeceras, sólo es válido para un byte completo. Así que nos encontraremos con un problema cuando tengamos que descartar en un byte una parte de éste.

Ejemplo

Observemos el primer byte (8 bits primeros) de una cabecera IP.

Datagrama IP

Vemos que consta de dos partes:

  1. la versión

  2. el tamaño del encabezamiento (IHL)

 

Entonces queremos descartar los 4 bits de la versión IP y filtrar el tamaño del encabezamiento. ¿Cómo hacemos esto?.

La respuesta está en la creación de máscaras. Es decir, enmascarar unos bits para dejar “ver” el resto, y estas máscaras la hacemos usando operaciones booleanas. Lo vemos, como siempre, con un ejemplo:

Nos centramos en el primer byte de un encabezamiento IP. Tenemos los grupos de 4 bits. Vamos a explicar esto usando la misma técnica que en capítulos anteriores.

Dado que la versión de IP actualmente es la 4 y el tamaño del encabecamiento es 20 bytes … vaya, pero ¿cómo puede ser que tenga 20 bytes? si los bits destinados a este campo son sólo 4. La razón está en que la medida de este campo se hace representándolo en palabras de 32 bits, o sea, en 4 bytes. Así que el valor real almacenado es de 5. Este 5 lo multiplicamos por 4 bytes y nos dá como resultado 20 bytes.

Representamos en binario abajo los dos valores; el 4 de la versión y el 5 del tamaño (con una calculadora podemos ver su valor en binario).

Versión IP Tamaño encabezamiento IP

0 1 0 0 0 1 0 1 (101: “4”)

como queremos descartar la versión IP, vamos a realizar una operación booleana. Esta operación es un AND con 0 0 0 0 1 1 1 1

0 1 0 0 0 1 0 1

0 0 0 0 1 1 1 1

0 0 0 0 0 1 0 1

Razonemos este resultado. Si recordamos las operaciones booleanas:

0 AND 0 = 0

1 AND 0 = 0

1 AND 1 = 1

0 AND 1 = 0

Sólo en el caso de que los dos bits estén a 1 el resultado será 1.

 

Esta es la técnica que usa TCPdump / Windump para enmascarar bits. Pero ¿cómo traducimos esto a un filtro?

Recordemos que para crear un filtro de extración de datos de una cabecera se usa la expresión proto[x:y] = valor, en general expresión relación expresión. Veíamos en otros capítulos filtros como este:

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

expresión: tcp[13]

relación: =

expresión: 2

pues bien, como ahora hablamos de encabezamiento IP y el primer byte, el filtro sería de esta forma:

expresión: ip[0]

Vamos ahora con el resto de la expresión. Como realizamos una operación boolena de AND (&):

expresión: ip[0] &

como el valor binario, la máscara que vamos a aplicar es 0000 1111 en hexadecimal es 0F e indicamos que es un valor hexadecimal con el valor 0x, entonces:

expresión: ip[0] & 0x0F

y ahora la relación. Vamos a filtrar los valores de longitud de encabecamiento IP mayores que 5:

expresión: ip[0] & 0x0F > 5

Este filtro sería un caso de comportamiento anormal. Para probrarlo usaremos otro valor:

expresión: ip[0] & 0x0F = 5

que sería el normal en una cabecera Ip sin datos. Lo probamos:

C:\scan>windump -qn “ip[0] & 0x0f > 5”

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

779 packets received by filter

0 packets dropped by kernel

 

C:\scan>windump -qn “ip[0] & 0x0f = 5”

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

18:40:02.766513 IP 192.168.4.15.8080 > 192.168.4.5.4261: tcp 1460

18:40:02.876720 IP 192.168.4.5.4261 > 192.168.4.15.8080: tcp 0 (DF)

18:40:02.891493 IP 192.168.2.70.1025 > 192.168.2.60.139: tcp 88 (DF)

18:40:02.891720 IP 192.168.2.60.139 > 192.168.2.70.1025: tcp 80 (DF)

18:40:02.896319 IP 192.168.2.70.1025 > 192.168.2.60.139: tcp 176 (DF)

18:40:02.896540 IP 192.168.2.60.139 > 192.168.2.70.1025: tcp 39 (DF)

18:40:02.901594 IP 192.168.4.15.8080 > 192.168.4.5.4261: tcp 1140

18:40:02.946950 IP 192.168.2.70.1025 > 192.168.2.60.139: tcp 64 (DF)

18:40:02.947377 IP 192.168.2.60.139 > 192.168.2.70.1025: tcp 1460 (DF)

18:40:02.947442 IP 192.168.2.60.139 > 192.168.2.70.1025: tcp 1460 (DF)

18:40:02.947543 IP 192.168.2.60.139 > 192.168.2.70.1025: tcp 1240 (DF)

18:40:02.947620 IP 192.168.2.70.1025 > 192.168.2.60.139: tcp 0 (DF)

18:40:03.010696 IP 192.168.4.15.8080 > 192.168.4.5.4227: tcp 190

18:40:03.069269 IP 192.168.2.70.1025 > 192.168.2.60.139: tcp 0 (DF)

*Hay que observar, como en ejemplos anteriores, que el filtro está entre comillas.

 

Es un tanto difícil de comprender el enmascaramiento pero lo vemos con otro ejemplo práctico.

Acabo de crear un filtro para TCP lo ejecuto y me da como respuesta:

C:\scan>windump -qn “tcp[13] & 0x02 != 0”

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

18:58:52.992949 IP 192.168.4.5.4483 > 192.168.4.15.8080: tcp 0 (DF)

18:58:52.993085 IP 192.168.4.15.8080 > 192.168.4.5.4483: tcp 0

18:58:55.909550 IP 192.168.2.5.3028 > 192.168.4.15.110: tcp 0 (DF)

18:58:55.909650 IP 192.168.2.5.3028 > 192.168.4.15.110: tcp 0 (DF)

18:58:55.909777 IP 192.168.4.15.110 > 192.168.2.5.3028: tcp 0

18:58:55.909879 IP 192.168.4.15.110 > 192.168.2.5.3028: tcp 0

18:58:56.130273 IP 192.168.2.5.3029 > 192.168.4.15.110: tcp 0 (DF)

18:58:56.130343 IP 192.168.2.5.3029 > 192.168.4.15.110: tcp 0 (DF)

18:58:56.130483 IP 192.168.4.15.110 > 192.168.2.5.3029: tcp 0

18:58:56.130560 IP 192.168.4.15.110 > 192.168.2.5.3029: tcp 0

18:58:56.348314 IP 192.168.2.5.3030 > 192.168.4.15.110: tcp 0 (DF)

18:58:56.348379 IP 192.168.2.5.3030 > 192.168.4.15.110: tcp 0 (DF)

18:58:56.348522 IP 192.168.4.15.110 > 192.168.2.5.3030: tcp 0

18:58:56.348598 IP 192.168.4.15.110 > 192.168.2.5.3030: tcp 0

18:58:58.003782 IP 192.168.4.5.4485 > 192.168.4.15.8080: tcp 0 (DF)

18:58:58.003924 IP 192.168.4.15.8080 > 192.168.4.5.4485: tcp 0

18:58:58.008186 IP 192.168.4.5.4487 > 192.168.4.15.8080: tcp 0 (DF)

 

El hecho de crear un filtro TCP del tipo tcp[13] tiene una razón: en parte está explicado en el capítulo I :

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

 

 

“tcp[13] & 0x02 != 0”

Como ya sabemos de donde biene la expresión tcp[13], seguimos con el resto. Vemos en la expresión que realizamos una operación booleana de tipo AND (&) y que la expresión 02 está expresada en hexadecimal (0x). El valor binario de la expresión 02 es 10. Si miramos el cuadro anterior:

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 se trata de la activación del flag SYN. Seguimos con el filtro y vemos que además tiene != 0, es decir, que sea distinto de 0. Realicemos la operación de enmascaramiento.

0 0 0 0 0 0 0 0

0 0 0 0 0 0 1 0

0 0 0 0 0 0 0 0

Según esto, si aplicamos la máscara 0x02, el resultado es 0, pero si nos dá como resultado algo distinto de 0 entonces no estaría activado el flag SYN.

Este filtro es por tanto para detectar el flag SYN activado en una conexión TCP. Es decir es el mismo filtro que el siguiente ejemplo:

C:\scan>windump -qn “tcp[13] = 2”

windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

19:26:29.583511 IP 192.168.4.5.4851 > 192.168.4.15.8080: tcp 0 (DF)

19:26:39.586494 IP 192.168.4.5.4853 > 192.168.4.15.8080: tcp 0 (DF)

19:26:50.602742 IP 192.168.4.5.4855 > 192.168.4.15.8080: tcp 0 (DF)

311 packets received by filter

0 packets dropped by kernel

Ambos filtros son lo mismo. Nos devuelven el mismo resultado.

Esta entrada fue publicada en Seguridad y redes, Windump. TCPDump y etiquetada , , , , , , , , , , , , , , , . Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s