Ya vimos en la primera parte de esta serie dedicada a Herramientas para la interpretación de capturas de red, el uso de Windump y TCPDump y la primera parte de la creación y establecimiento de filtros .pcap.
En este segunda parte veremos el resto de la parte dedicada a filtros y comenzaremos con la interpretación de las capturas.
Filtros.
Seguimos con la aplicación de filtros pcap que comenzamos en la primera parte. Recordamos lo último que vimos sobre expresiones en formato hexadecimal y seguimos.
Expresiones en formato Hexadecimal.
Para especificar una dirección IP, TCPdump / Windump, etc, trabaja mejor con el formato hexadecimal.
Para una dirección 192.168.1.5, su equivalente en hexadecimal sería:
192 > C0
168 > A8
1 > 01
5 > 05
es decir: C0A80405
Para Windump, añadimos el indicativo de que se trata de formato hexadecimal: 0x
y nos quedaría: 0xC0A80105
Apliquemos esto a nuestros ejemplos de filtros y a lo ya visto hasta ahora en la primera parte:
- Datagramas IP cuyo IP de origen sea 0xC0A80105 o 192.168.1.5
windump -i1 -qtn "ip[12:4] = 0xC0A80105"
IP 192.168.1.5.26495 > 192.168.1.245.53: UDP, length 30
IP 192.168.1.5.5879 > 192.168.1.245.53: UDP, length 31
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 621
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12567 > 209.85.229.102.80: tcp 0
IP 192.168.1.5.12567 > 209.85.229.102.80: tcp 0
IP 192.168.1.5.12567 > 209.85.229.102.80: tcp 640
- Datagramas IP cuyo IP de origen sea mayor que 192.168.1.5
windump -i1 -qtn "ip[12:4] > 0xC0A80105"
IP 192.168.1.200 > 224.0.0.251: igmp
IP 192.168.1.11 > 239.255.255.250: igmp
IP 192.168.1.202 > 224.0.0.251: igmp
IP 192.168.1.201 > 224.0.1.60: igmp
IP 209.85.229.99.80 > 192.168.1.5.12565: tcp 0
IP 209.85.229.99.80 > 192.168.1.5.12565: tcp 0
- Datagramas IP cuyo valor TTL sea mayor que 5
windump -i1 -qnt "ip[8]> 5"
IP 192.168.1.239.138 > 192.168.1.255.138: UDP, length 201
IP 192.168.1.30.138 > 192.168.1.255.138: UDP, length 201
Sobre datagramas IP, TTL, etc. más información en Seguridad y Redes:
http://seguridadyredes.nireblog.com/post/2009/11/05/wireshark-windump-analisis-capturas-trafico-red-interpretacian-datagrama-ip-actualizacian.
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.
Lo vemos con un ejemplo:
Observad el primer byte (8 bits primeros) de una cabecera datagrama IP:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Versión| IHL | Tipo Servicio | Longitud Total | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificación |Flags| Posición | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Tiempo de Vida | Protocolo | Suma de Control de Cabecera | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección de Origen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección de Destino | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones | Relleno | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Observad que consta de dos partes:
- la Versión
- 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 dos grupos de 4 bits.
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 y Tamaño encabezamiento IP (en binario):
0 1 0 0 0 1 0 1
vemos de forma clara el 0100 (4 en decimal) y 0101 (5 en decimal).
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 (como hemos visto este el el valor del primer byte completo) 0 0 0 0 1 1 1 1 (para manterner los valores) --------------- 0 0 0 0 0 1 0 1 (nos quedamos con la parte de tamaño encabez. como resultado)
Vamos a razonar el resultado antendiendo a 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, como hemos visto más arriba, expresión relación expresión. Hemos visto también filtros como este:
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:
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)
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:
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 filtro aplicado a la captura anterior es «tcp[13] & 0x02 != 0»
Como ya sabemos de donde viene la expresión tcp[13], lo hemos visto más arriba, 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 que ejmplo que vimos más arriba: «tcp[13] = 2»
Ambos filtros son lo mismo. Nos devuelven el mismo resultado. Es decir «tcp[13] = 2» y «tcp[13] & 0x02 != 0» son lo mismo
Otras formas de creación de filtros
Observad, de nuevo la cabecera del datagrama IP:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Versión| IHL | Tipo Servicio | Longitud Total | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificación |Flags| Posición | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Tiempo de Vida | Protocolo | Suma de Control de Cabecera | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección de Origen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección de Destino | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones | Relleno | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Y esta captura de un datagrama IP:
Observamos (reseñado con círculo rojo) que en la posición del byte 9 y con longitud de 1 byte tenemos la identificación del protocolo, en este caso 06 (tcp). De esta manera el filtro quedaría:
windump -qtn -X -s 0 ip[9:1] = 6
ó
windump -qtn -X -s 0 ip[9] = 6
NOTA: se elimina el :1 al ser de longitud 1 byte
De esta forma y siguiendo la misma técnica, para filtrar por el protocolo UDP:
windump -qtn -X -s 0 ip[9:1] = 17
también:
windump -qtn -X -s 0 ip[9:1] & 0x11 != 0
Esta última notación de debe al uso de máscaras que ya hemos estudiado. Veámoslo:
0x11 es la notación hexadecimal del binario 00010001 y decimal 17. Sabemos que la longitud del campo protocolo es de 1 byte, es decir 8 bites. Así pues, la notación quiere decir:
Filtrar según si en la posición ip[9:1] con mascara 00010001 es distinto de 0 ó no activo.
Si quisieramos filtrar por el protocolo tcp, la mascara sería 00000110 al ser el tipo 6 o hexadecimal 0x06. El tipo de protocolo nos lo dice las RFCs.
Otro ejemplo.
Según el mismo datagrama la dirección IP de destino se situa en el byte 16 y tiene una longitud de 32 bits ó 4 bytes. Si queremos filtrar por dirección de destino 192.168.1.3 el filtro quedaría:
windump -qtn -X -s 0 ip[16:4] = 0xc0a80103
NOTA: ponemos 0x antes para indicar que es una notación hexadecimal. el dato de IP destino lo sacamos de (0x0010 c0a8 0103) del datagrama.
Otro ejemplo para dejar esto bien atado. Vamos ahora a filtrar por número de secuencia de un segmento TCP. Según vemos en la cabecera se un segmento TCP:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puerto de origen | Puerto de destino | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Número de secuencia | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Número de acuse de recibo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Posic | |U|A|P|R|S|F| | | de los| Reservado |R|C|S|S|Y|I| Ventana | | datos | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suma de control | Puntero urgente | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones | Relleno | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datos | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
observamos de forma clara que el número se secuencia se situa en el octeto ó byte 4 y tiene una longitud de 4 bytes. El filtro quedaría entonces:
tcp[4:4]
Otro ejemplo. Ahora con ICMP.
He marcado de color azul desde el comienzo de la cabecera icmp y lo que nos interesa.
ICMP se transmite como datagramas de IP con una cabecera normal de IP, con el campo IP de Protocolo con el valor 1.
El campo que determina dentro de icmp el tipo de que se trata tiene una longitud de 8 bits ó 1 byte situado al comienzo. En las trazas del ejemplo tenemos un echo request y un echo reply con valores 08 en el primero y 00 en el segundo.
De esta forma para filtrar los icmp de tipo echo request pondríamos:
windump -qtn -X -i2 -s 0 icmp[0:1] = 08
Como nota informativa: Algunos tipos de icmp que nos servirán para la creación de nuestros filtros icmp: ( Esta documentado aquí: http://www.rfc-es.org/rfc/rfc0792-es.txt )
- 0 Respuesta de ECO
- 3 Destino inaccesible
- 4 Disminución de origen (source quench)
- 5 Redireccionar (cambiar una ruta)
- 8 Solicitud de ECO
- 11 Tiempo excedido para un datagrama
- 12 Problema de parámetros de un datagrama
- 13 Solicitud de TIMESTAMP
- 14 Respuesta de TIMESTAMP
- 15 Solicitud de Información (obsoleto)
- 16 Respuesta de Información (obsoleto)
- 17 Solicitud de Máscara de dirección
- 18 Respuesta de máscara de dirección
Seguimos. complicamos un poco más ya que algunos de anteriores filtros pueden ser obviados debido a que windump/tcpdump tienen, como hemos visto al principio, una serie de primitivas para ciertos filtros:
para solo filtrar por el protocolo tcp:
windump -qtn tcp
igualmente para filtrar por el protocolo udp
windump -qtn tcp
Sin embargo sacar información de otros campos del datagrama IP o de segmentos TCP, etc. es más complicado al no proveer la herramienta de las primitivas necesarias. Veamos un ejemplo:
Filtrar los paquetes que tengan el bit de no Fragmentar (DF):
windump -qtn "ip[6] & 64 != 0"
Explicación:
ip[6] & 64 es lo mismo que ip[6] & 0x40 la mascara sería 01000000.
Sabemos que el primer bit que compone los tres que forman el campo Flag de IP es siempre 0, los otros dos son DF y MF de verificación que el datagrama llega a su destino.
El resto forma parte del siguiente campo de 13 bits que forman el Fragment Offset. Como las máscaras las aplicamos como octetos o conjuntos de 8 bits, para saber si el bit de DF está activado la máscara sería 01000000 (el segundo bit activado). Para saber si el activado es el MF entonces la máscara sería 00100000.
Para filtrar por el bit activado de (MF) sería:
windump -qtn "ip[6] & 32 != 0"
ó
windump -qtn "ip[6] & 0x20 != 0" (hexadecimal)
Lo vemos en este ejemplo:
windump -qtn "ip[6] & 32 != 0"
windump: listening on\Device\Packet_{52BFAEB8-D80F-4700-AC56-9C97BC7083B5}
10.164.138.11 > 192.168.1.33: icmp: echo request (frag 34819:552@0+)
10.209.1.224.16 > 192.168.1.33.2222: FP 1585299871:1585301027(1156) ack 39..276 win 8460 (frag 93...@0+)
10.193.250.165 > 192.168.1.33: icmp: echo request (frag 45828:552@0+)
10.193.250.165 > 192.168.1.33: icmp: echo request (frag 3333:552@0+)
Aplicando los filtros a la realidad
Bien, es el momento de aplicar todo lo que hemos aprendido a la realidad. Vamos, pues, a situarnos en una serie de escenarios para filtrar según nuestras necesidades. Algunos ya los hemos visto en ejemplos anteriores, nos servirá como chuleta. Estos filtros, como ya hemos comentados son validos para Wireshark, Tshark, Snort, etc,.
Establecer un filtro para la función sniffer de Snort sería tan facil como esto:
snort -v "tcp[13] & 64 != 0"
Otros ejemplo de filtros:
Mostrar todos paquetes con el flag URG activado:
windump "tcp[13] & 32 != 0"
Mostrar todos paquetes con el flag ACK activado:
windump "tcp[13] & 16 != 0"
Mostrar todos paquetes con el flag PSH activado:
windump "tcp[13] & 8 != 0"
Mostrar todos paquetes con el flag RST activado:
windump "tcp[13] & 4 != 0"
Mostrar todos paquetes con el flag SYN activado:
windump "tcp[13] & 2 != 0"
Mostrar todos paquetes con el flag FIN activado:
windump "tcp[13] & 1 != 0"
Mostrar todos paquetes con el flag SYN-ACK activado:
windump "tcp[13] = 18"
ICMP petición y respuesta de Echo. Echo Request y Echo Reply:
windump "(icmp[0:1]=0)" or "(icmp[0:1]=8)"
Filtro por campo TTL:
windump ip and "ip[8]<2"
Filtro por campo TOS:
windump ip and "ip[1]!=0"
Ping de la muerte. Ping of Death:
windump icmp and "((ip[2:2]-((ip[0:1]&0x0f)*4)+((ip[6:2]&0x1fff)*8))>65535)"
Ataque Smurf:
windump "(ip[19]=0xff)" or "(ip[19]=0x00)"
Filtrar por tamaño del paquete (Length):
windump ip and "(ip[2:2]<60)" (si es menor de 60)
Otra forma de captura banderas tcp (flags) SYN+ACK:
windump "tcp[tcpflags] & (tcp-syn|tcp-ack) ==(tcp-syn|tcp-ack)"
Puch activado:
windump "tcp[tcpflags] & tcp-push == tcp-push"
Interpretación de las capturas.
Comenzamos aquí la parte de interpretación de capturas usando Windump / TCPDump. como primer ejemplo vamos a descifrar, a partir del resultado de una captura, la cabecera de un datagrama IP.
Como siempre, y como estamos hablando de IP:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Versión| IHL | Tipo Servicio | Longitud Total | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificación |Flags| Posición | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Tiempo de Vida | Protocolo | Suma de Control de Cabecera | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección de Origen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección de Destino | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones | Relleno | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Usamos para capturar:
windump -i2 -qtn -x -s 0 tcp
Ahora el resultado de nuestra captura:
IP 192.168.1.5.4984 > 82.159.204.86.80: tcp 182 0x0000: 4500 00de c554 4000 8006 5422 c0a8 0105 0x0010: 529f cc56 1378 0050 0e48 e5d6 fec8 7feb 0x0020: 5018 fc00 e173 0000 2d25 3242 2d25 3242 0x0030: 2d25 3242 2d25 3242 2d25 3242 2d25 3242
Ahora interpretamos:
VERSION: 4 Tiene una longitud de 4 bits. En este caso 4 (0100 en binario) Se trata de la versión del formato de la cabecera IP. Vemos que 4 corresponde a la versión ipv4. si el valor fuera 6, se trataría de la versión ipv6.
IHL: 5 ó longitud de la cabecera en palabras de 32 bits. En este caso: 5*32=160 bits. El valor mínimo es 5. Este campo indica en que punto o bit termina la cabecera del datagrama. Esto es así porque al ser el datagrama de longitud variable devido a las opciones, también de tamaño variable, se necesita saber donde comenzará la parte de datos del paquete.
TOS: 00 Tipo de servicio respecto a la fiabilidad, velocidad, retardo, seguridad, etc deseados. Tiene un tamaño de 8 bits, en este caso 00000000. Hay que tener en cuenta que algunas redes ofrecen prioridad de servicio para dar mayor importancia a este tipo de tráfico.
Tabla de valores para TOS
- Bits 0-2 Prioridad.
- Bit 3 0 = Demora Normal, 1 = Baja Demora.
- Bit 4 0 = Rendimiento Normal, 1 = Alto rendimiento.
- Bit 5 0 = Fiabilidad Normal, 1 = Alta fiabilidad.
- Bits 6-7 Reservado para uso futuro.
En este caso:
prioridad 0 y demora, rendimiento y fiabilidad: normal
TOTAL LENGTH: 00de Longitud total del datagrama medida en octetos. Se incluyen los datos encapsulados, cabecera y datos.
La longitud del campo es de 16 bits. De esta manera la longitud máxima es (1111111111111111) = 65535 bytes. En este caso 100 bytes.
ID: c554 Número de identificación único por cada datagrama que permitirá el reensamblaje posterior al ser dividido en fragmentos más pequeños. Longitud 16 bits. En este caso Id=50516. Lo asigna el remitente en la conexión. El valor de este campo junto a la información de Source IP y Destination IP, resuelve la identificación única del paquete al que hace referencia.
FLAGS: 4 Bandera (Flag) Campo de 3 bits.Indicadores de control. Usado en caso de defragmentación.
- El primer bit esta reservado y es siempre 0.
- El segundo es el el bit de indicación de no fragmentación (DF). (010)
- El tercero (MF) es de verificación que el datagrama llega a su destino (001) completo, está activo en todos los datagramas enviados excepto en el último para informar que ya no hay más fragmentos.
FRAGMENT OFFSET: 000 Posición. Longitud de 13 bits. Posición del fragmento dentro del datagrama en caso de fragmentación.
TTL: 80 Tiempo de vida. Longitud 8 bits. Impide que un paquete esté indefinidamente viajando por la red. En este caso 128 indica que cada vez que un datagrama atraviese un router este numero se decrementa en 1. cuando el TTL llege a 0 el datagrama se descarta y se informa de ello al origen con un mensaje de tiempo excedido.
PROTOCOL: 06 Protocolo. Se refiere al protocolo de siguiente nivel que se usa en la parte de datos. Longitud 8 bits. En este caso hex(06) (00000110) = TCP en decimal sería 6.
Valores para los protocolos
1 ICMP, 2 IGMP, 6 TCP, 9 IGRP, 17 UDP, 47 GRE, 50 ESP, 51 AH, 88 EIGRP, 89 OSPF, 115 L2TP.
HEADER CHEKSUM: 5422 (CRC) o Suma de Control de la Cabecera. Longitud 16 bits. Es la suma de comprobación de errores de la cabecera del datagrama. Este número se calcula nuevamente en cada salto del datagrama a través de los routers.
SOURCE ADDRESS: c0.a8 01.05 dirección origen: 192.168.1.5 longitud 32 bits.
DESTINATION ADDRESS: 52.9f.cc.56 dirección destino: 82.159.204.86 longitud 32 bits.
Tenemos otro campo que es Options (Opciones) de longitud variable con información opcional para el datagrama. Puede tener 0 o más opciones. Y Padding (Relleno) también de longitud variable. Asegura que la cabecera IP termine en múltiplo de 32 bits.
Según el RFC0791 Las opciones Options pueden o no aparecer en los datagramas. Deben ser implementadas por todos los módulos IP (host y pasarelas). Lo que es opcional es su transmisión en cualquier datagrama en particular, no su implementación.
NOTA: Este campo de opciones lo veremos de forma más detallada en otro artículo.
El último campo es Data, de longitud variable, conteniendo los datos a enviar. La longitud máxima es 64 Kbytes y comienza con el contenido de la cabecera del protocolo de siguiente nivel, es decir TCP o UDP. Los datos y encabezamiento del segmento TCP van dentro del campo Data del datagrama IP, es lo que llamamos encapsulación.
En este caso el campo Data comienza con con los campos de la cabecera del segmento TCP puerto origen y puerto destino:
1378 0050
es decir puerto origen 4984 (1378 en hexadecinal) y puerto destino 80 (0050 en hexadecimal).
Identificación de protocolos.
Podemos identifucar los protocolos observando el resultado de nuestras capturas:
UDP
16:33:59.501208 192.168.4.1.520 > 192.168.4.255.520: udp 24
16:34:27.131434 192.168.4.1.137 > 192.168.4.2.137: udp 62
16:34:29.503733 192.168.4.1.520 > 192.168.4.255.520: udp 24
16:34:59.506694 192.168.4.1.520 > 192.168.4.255.520: udp 24
16:35:29.509226 192.168.4.1.520 > 192.168.4.255.520: udp 24
TCP
16:37:34.672005 192.168.4.15.4036 > 192.168.4.1.139: tcp 280
16:37:34.674529 192.168.4.1.139 > 192.168.4.15.4036: tcp 131 (DF)
16:37:34.674949 192.168.4.15.4036 > 192.168.4.1.139: tcp 43
16:37:34.675151 192.168.4.1.139 > 192.168.4.15.4036: tcp 43 (DF)
16:37:34.680743 192.168.4.15.4036 > 192.168.4.1.139: tcp 280
ICMP
16:45:29.386197 192.168.4.1 > 192.168.4.10: icmp: host 192.168.1.150 unreachable
16:45:29.386430 192.168.4.1 > 192.168.4.10: icmp: host 205.134.xxx.xxx unreachable
16:45:35.160914 192.168.4.1 > 192.168.4.10: icmp: host 192.168.1.151 unreachable
16:45:40.910035 192.168.4.10 > 192.168.4.1: icmp: echo request
16:45:40.910160 192.168.4.1 > 192.168.4.10: icmp: echo reply
ARP
16:51:21.227113 arp who-has 192.168.2.86 tell 192.168.2.60
16:51:21.538845 arp who-has 192.168.2.64 tell 192.168.2.60
16:51:21.850790 arp who-has 192.168.2.76 tell 192.168.2.60
16:51:21.851784 arp who-has 192.168.2.197 tell 192.168.2.60
16:51:21.851863 arp who-has 192.168.2.200 tell 192.168.2.60
16:51:21.857060 arp reply 192.168.2.197 is-at 0:a0:c9:1c:c1:f5
POP3
16:53:43.824474 192.168.2.90.2040 > 192.168.4.15.110: S 1607781:1607781(0) win 8192 (DF)
16:53:43.824575 192.168.4.15.110 > 192.168.2.90.2040: S 4064642994:4064642994(0) ack 1607782
win 64240 60>
16:53:43.824920 192.168.2.90.2040 > 192.168.4.15.110: . ack 1 win 8760 (DF)
16:53:43.863694 192.168.4.15.110 > 192.168.2.90.2040: P 1:89(88) ack 1 win 64240
16:53:43.864264 192.168.2.90.2040 > 192.168.4.15.110: P 1:17(16) ack 89 win 8672 (DF)
16:53:43.962939 192.168.4.15.110 > 192.168.2.90.2040: P 89:120(31) ack 17 win 64224
16:53:43.963439 192.168.2.90.2040 > 192.168.4.15.110: P 17:33(16) ack 120 win 8641 (DF)
16:53:44.009535 192.168.4.15.110 > 192.168.2.90.2040: P 120:188(68) ack 33 win 64208
SMTP
192.168.4.3.2605 > 192.168.4.15.25: S 3369617405:3369617405(0) win 64240 (DF)
192.168.4.15.25 > 192.168.4.3.2605: S 138683007:138683007(0) ack 3369617406 win 64240>
192.168.4.3.2605 > 192.168.4.15.25: . ack 1 win 64240 (DF)
192.168.4.15.25 > 192.168.4.3.2605: P 1:42(41) ack 1 win 64240
Establecimiento conexión TCP.
Una conexión TCP se realiza en tres pasos. Es lo que técnicamente se llama three-way handshake:
- En el sistema / host que inicia la conexión o cliente (192.168.1.5), envía un paquete de SYN con un número de secuencia inicial asociado a esta conexión al sistema / host destinatario o servidor (66.249.92.104).
- Este responde con un paquete SYN-ACK (acuse de recibo) confirmando la recepción del SYN inicial enviado por (192.168.1.5) y enviándole a su vez su propio número de secuencia.
- Para finalizar, el cliente (192.168.1.5) reconoce la recepción del SYN del servidor (66.249.92.104) mediante el envío de un ACK. Este es el momento en que queda establecida la conexión. Ya se puede iniciar la transferencia de datos entre (192.168.1.5) y (66.249.92.104).
Lo vemos en la captura:
windump -i2 -tn tcp
- IP 192.168.1.5.6152 > 66.249.92.104.80: S 3937062632:3937062632(0) win 64512 <mss 1460,nop,nop,sackOK>
- IP 66.249.92.104.80 > 192.168.1.5.6152: S 3210226575:3210226575(0) ack 3937062633 win 65535 <mss 1460,nop,nop,sackOK>
- IP 192.168.1.5.6152 > 66.249.92.104.80: . ack 1 win 64512
.
Bien, hasta aquí por hoy. Para el próximo capítulo comenzaremos con Tshark, interpretación usando Tshark, formas de filtros, esdtadísticas, etc.
