Analisis Capturas Tráfico Red. Interpretación Datagrama IP. (Parte I)alfonn 17-01-2008 GTM 1 @ 17:45

NOTA: Este artículo se encuentra actualizado, ampliado los conceptos y con nuevos contenidos aquí:

Wireshark / Windump. Analisis capturas tráfico red. Interpretación Datagrama IP. (Actualización).

-------------------------------------------------------------------------------

Una de las tareas habituales de un administrador de red es el análisis de los logs de tráfico de la red. Análisis que puede ser de rendimiento o seguridad.

Tráfico de la LAN, entrante y saliente a través de cortafuegos, análisis de Sistemas de Detección de Intrusos, etc.

Para ello contamos con variadas herramientas. Entre ellas Snort, TCPDump/Windump, Ethereal (ahora WireShark), etc. Destaco esta tres últimas por

estar basadas en la librería libpcap.

En este artículo vamos a analizar las capturas en hexadecimal de estas herramientas para obtener todos los datos posibles de las cabeceras IP,

segmentos TCP, además de comprender de forma más visual los conceptos TCP/IP.

Una de las tareas habituales de un administrador de red es el análisis de los logs de tráfico de la red. Análisis que puede ser de rendimiento o seguridad.

Tráfico de la LAN, entrante y saliente a través de cortafuegos, análisis de Sistemas de Detección de Intrusos, etc.

Para ello contamos con variadas herramientas. Entre ellas Snort, TCPDump/Windump, Ethereal (ahora WireShark), etc. Destaco estas tres últimas por

estar basadas en la librería libpcap.

Libpcap es una librería de código abierto que ofrece al programador una interfaz desde la que capturar paquetes en la capa de red. La implementación para

windows es Winpcap. Entre las utilidades más importantes de los analizadores de tráfico de red está la que nos proporciona la salida en hexadecimal de las

capturas.

En este artículo vamos a analizar dichas capturas en hexadecimal para obtener todos los datos posibles de las cabeceras IP y segmentos TCP, además de

comprender de forma más visual los conceptos TCP/IP.

Para ello usaremos TCPDump (Linux/Unix) / Windump (Windows).

Antes que nada recordar un poco como funciona TCPDump / Windump:

Seguridad y Redes Analizando la Red con WinDump / TCPDump   (I Parte)

Seguridad y Redes Analizando la Red Con WinDump / TCPDump   (II Parte)

Seguridad y Redes Analizando la Red con WinDump/TCPDump   (Parte III)

Y recordar también los conceptos TCP/IP:

http://es.wikipedia.org/wiki/TCP/IP

http://www.saulo.net/pub/tcpip/

Para las salidas en hexadecimal usaremos la opción -x de tcpdump/windump que captura por defecto 68 bytes.

Para capturar toda la información usamos el snaplen (-s0). A cero estamos cogiendo los paquetes completos.

Si hubiéramos puesto -s 512 se capturarían sólo los primeros 512 bytes de un determinado paquete.

Comenzamos.

Interpretación de un Datagrama IP.

Esta es una salida en hexadecimal de cualquiera de los analizadores

de red mencionados más arriba, en este caso tcpdump:

IP 192.168.1.240.139 > 192.168.1.3.1098: tcp 60 (DF) 0x0000 4500 0064 8a01 4000 8006 ec4e c0a8 01f0 E..d..@....N.... 0x0010 c0a8 0103 008b 044a fcea 6aaf 60e5 ea5b .......J..j.`..[ 0x0020 5018 fd34 8917 0000 0000 0038 ff53 4d42 P..4.......8.SMB 0x0030 7500 0000 0098 07c8 0000 0000 0000 0000 u............... 0x0040 0000 0000 04b0 fffe 01a8 c000 07ff 0038 ...............8 0x0050 0001 00ff 0100 00ff 0100 0007 0049 5043 .............IPC 0x0060 0000 0000En la primera línea tenemos ya algunos datos (esto ya lo hemos visto en el artículo de tcpdump). Si embargo vamos a descifrar la cabecera para obtener los

mismos y otros datos importantes.

DATAGRAMA IP

4 ipv4. tiene una longitud de 4 bits. En este caso 4 (0100)

5 IHL o longitud de la cabecera en palabras de 32 bits. En este caso: 5*32=160 bits

00 (TOS) Tipo de servicio respecto a la fiabilidad, velocidad, retardo, seguridad... Tiene un tamaño de 8 bits, en este caso 00000000.

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

0064 Longitud total. Se incluyen los datos encapsulados.

La longitud del campo es de 16 bits. De esta manera la longitud máxima es (1111111111111111) = 65535 bytes. En este caso 100 bytes.

8a01 (ID) 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=35329.

4 Bandera (Flag) Campo de 3 bits.

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.

000 Fragment offset o Posición. Longitud de 13 bits. Posición del fragmento dentro del datagrama.

80 (TTL) 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.

06 Protocolo. 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.

ec4e Header Cheksum(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.

c0.a8 01.f0 dirección origen: 192.168.1.240 longitud 32 bits.

c0.a8 01.03 dirección destino: 192.168.1.3 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.

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:

008b Puerto origen 139

044a Puerto Destino 1098

Formato de la cabecera TCP (encapsulado en el Data del segmento IP)

El segmento TCP lo estudiaremos en otra entrega

Análisis Capturas Tráfico De Red. Interpretacion Segmento TCP (II). Establecimento Conexión TCP.alfonn 29-01-2008 GTM 1 @ 17:07

Ya vimos en la primera parte de este estudio sobre Análisis de capturas de tráfico de red la interpretación del datagrama IP, la interpretación de los valores

hexadecimales de la salida de TCPDump/WinDumpreferente al datagrama IP. Ahora vamos a estudiar e interpretar el segmento TCP. TCP es el protocolo

delnivel de transporte orientado a conexión. Veremos los mecanismos que implementa TCP para dar la mayor fiabilidad posible a dicha conexión.

Mecanismos como los números de secuencia y las confirmaciones de recepción. También veremos en modo de apéndice, para comprender mejor lo estudiado,

el establecimento de una conexión TCP.

A continuación una salida TCPDump/WinDump de una conexión cualquiera. En este caso un update de informacion a una tabla de BD mysql desde el

puesto STATION a traves del puerto 1472 hacia INFO01 donde se ubica la base de datos mysql a la escucha en puerto 3306.

Vamos a distinguir las partes que nos interesan.

Cabecera IP:

Segmento TCP:

Datos (incluye Opciones y Campo Relleno):

La cabecera IP ya fue tema de estudio en la primera parte de este artículo. Así pues nos centramos en elSegmento TCP.

La salida hexadecimal que vamos a analizar:

05c0 Puerto origen. En este caso 1472.

0cea Puerto destino. En este caso 3306.

27dd 44a3 Número de secuencia. (32 bits). Indica el número de secuencia del primer byte que trasporta el segmento. En este caso 1020517571.

6fad 253b Número de acuse de recibo. (32 bits). Indica el número de secuencia del siguiente byte que se espera recibir. Con este campo se indica al otro

extremo de la conexión que los bytes anteriores se han recibido correctamente. En este caso 1873618235.

5 Posición de los datos (Data Offset). (4 bits). Longitud de la cabecera medida en múltiplos de 32 bits(4 bytes). El valor mínimo de este campo es 5, que

corresponde a un segmento sin datos (20 bytes).

018 Campo reservado (para un posible uso futuro) + Bits de código o indicadores. (6 + 6 bits.)

Bits de código o indicadores. (6 bits). Los bits de código determinan el propósito y contenido del segmento. A continuación se explica el significado de cada uno de estos bits (mostrados de izquierda a derecha) si está a 1:

URG. El campo Puntero de urgencia contiene información válida.

ACK. El campo Número de acuse de recibo contiene información válida, es decir, el segmento actual lleva un ACK. Observemos que un mismo segmento

puede transportar los datos de un sentido y las confirmaciones del otro sentido de la comunicación.

PSH. La aplicación ha solicitado una operación push (enviar los datos existentes en la memoria temporal sin esperar a completar el segmento).

RST. Interrupción de la conexión actual.SYN. Sincronización de los números de secuencia. Se utiliza al crear una conexión para indicar al otro extremo cual va a ser el primer número de secuencia con el que va a comenzar a transmitir (veremos que no tiene porqué ser el cero).

FIN. Indica al otro extremo que la aplicación ya no tiene más datos para enviar. Se utiliza para solicitar el cierre de la conexión actual.

En este caso:

Si pasamos 018 (hex) a binario, obtenemos: 11000

Como ya hemos explicado en los artículos de TCPDump/windump:

....U A P R S F

------------------

0 0 0 1 1 0 0 0 (en binario)

------------------

7 6 5 4 3 2 1 0

los bytes 7 y 6 son los reservados. Vemos entonces que tenemos activados con 1 los indicadores A y P que corresponden a SYN +PSH

NOTA: Esto último ya los estudiamos en el capítulo de filtros TCPDump/ WinDump

fd59 Window (ventana). (16 bits). Número de bytes que el emisor del segmento está dispuesto a aceptar por parte del

destino. En este caso 64857.

2def Checksum o suma de vdrificación (16 bits). Suma de comprobación de errores del segmento actual. Para su cálculo se utiliza una pseudo-cabecera

que también incluye las direcciones IP origen y destino.

0000 Urgent Pointer o Puntero urgente (16 bits). Se utiliza cuando se están enviando datos urgentes que tienen preferencia sobre todos los demás e

indica el siguiente byte del campo Datos que sigue a los datos urgentes. Esto le permite al destino identificar donde terminan los datos urgentes.

Nos quedan dos campos. Options y Padding o relleno

Opciones (variable). Si está presente únicamente se define una opción: el tamaño máximo de segmento que será aceptado.

Relleno. Se utiliza para que la longitud de la cabecera sea múltiplo de 32 bits.

Inmediatamente después nos encontramos con los datos. En este caso vemos las información delupdate de la base de datos mysql.

Hasta aquí el estudio del segmento TCP. En posteriores entregas estudiatremos UDP e ICMP.

Apéndice complementario.Establecimiento de una conexión TCP.Un ejercicio interesante puede ser analizar la salida en hexadecimal ttratando de comprender un establecimiento de conexión TCP. Para comprender como se

realiza, a continuación una breve explicación ya publicada por mi Nautopía.

En los ejemplos veremos los campos del segmento TCP que acabamos de estudias de una forma más práctica.Veremos en este apéndice cómo se realiza una conexión TCP. Nos ayudará a interpretar logs, trazas ytécnicas de escaneo. Veremos también algunos componentes de los paquetes TCP aparte de los puertos de la máquina origen y destino. Estos componentes importantes son los números de secuencia y de confirmación (SEQ y ACK) que se utilizan para asegurar la integridad de la conexión y los flags o banderasque son los encargados de indicar la finalidad del paquete (para iniciar o finalizar una conexión, para transmitir datos, etc).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 (TCP A), envía un paquete de SYN con un número de secuencia inicial asociado a esta conexión al sistema / host destinatario o servidor (TCP B).

2. Este responde con un paquete SYN-ACK (acuse de recibo) confirmando la recepción del SYN inicial enviado por (TCP A) y enviándole a su vez su propio número de secuencia.

3. Para finalizar, el cliente (TCP A) reconoce la recepción del SYN del servidor (TCP B) 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 (TCP A) y (TCP B).

Vamos a avanzar un poco más ya que ocurren algunas otras cosas. Lo vemos gráficamente:

Sean dos hosts pretenden inciciar una conexión TCP. TCP A y TCP B, siguiendo la analogía de la explicación anterior.1. TCP A _SYN( SEQ=x ) -> y TCP B2. TCP B _SYN( SEQ=y, ACK=x+1 ) -> TCP A,3. TCP A _SYN( SEQ=x+1, ACK=y+1 ) -> TCP B.

Vemos como TCP A envía un paquete SYN con un número de secuencia inicial x que además es aleatorio aTCP B. El resto es fácil deducir.Las letras x e y son los números de secuencia (SEQ). Se utilizan números de secuencia distintos para cadasentido de la comunicación. El primer número para cada sentido se acuerda al establecer la comunicación. Cada extremo se inventa un número aleatorio y envía éste como inicio de secuencia.Un paso más para terminar de comprender la conexión TCP totalmente imprescindible para entender muchas técnicas de escaneo.Ejemplo:Sean dos hosts (TCP A) y (TCP B) que pretenden iniciar una conexión. Veremos también que pasa con los números de secuencia (SEQ):

Todo esto es lo que ocurre cuando realizamos un escaneado de puerto TCP conect ().

Si la opción elegida es TCP SYN no dejamos que se establezca totalmente la conexión, esto significaría el envío por parte de TCP A de un RST (reset) cerrando así la conexión.

Ejercicios y ejemplos1.- Como ejercicio podríamos descifrar esta traza capturada por Ethereal. Se trata de un escan Nmap TCP conect() al puerto 25.La orden para escanear sería:

C:\nmap –sT –v 192.168.4.15 –p25La traza resultante:INFOGRAFIA3 ABANCECOMU TCP 1125 > smtp [SYN] Seq=13766490 Ack=0 Win=16384 Len=0ABANCECOMU INFOGRAFIA3 TCP smtp > 1125 [SYN, ACK] Seq=472370892 Ack=13766491 Win=8736 Len=0INFOGRAFIA3 ABANCECOMU TCP 1125 > smtp [ACK] Seq=13766491 Ack=472370893 Win=17472 Len=0 

2.- Ahora vamos a ver un escaneo nmap tipo –sS al puerto 25 (smtp) desactivando el ping.La orden para escanear sería:

C:\nmap –sS –P0 IFOGRAFIA3 –p 25La traza resultante:ABANCECOMU INFOGRAFIA3 TCP 38428 > smtp [SYN] Seq=2093898103 Ack=0 Win=2048 Len=0INFOGRAFIA3 ABANCECOMU TCP smtp > 38428 [SYN, ACK] Seq=3462674933 Ack=2093898104 Win=16616 Len=0ABANCECOMU INFOGRAFIA3 TCP 8428 > smtp [RST] Seq=2093898104 Ack=2093898104 Win=0 Len=0 

Vemos claramente el RST (reset) enviado en la última línea de la traza, no completando o estableciendo la conexión. 

NOTA: Observemos en ambos casos los incrementos y valores de números de secuencias, los indicadores oflags TCP que se intercambian en el diálogo, etc.

Análisis Capturas Tráfico De Red. Interpretacion Datagrama UDP (III).alfonn 06-02-2008 GTM 1 @ 12:48

Ya vimos en la primera parte y segunda parte   de este estudio sobre Análisis de capturas de tráfico de red la interpretación del datagrama IP y el segmento

TCP, la interpretación de los valores hexadecimales de la salida de TCPDump /WinDump  referente al datagrama IP y segmento TCP. Ahora vamos a estudiar e

interpretar el datagrama UDP. UDP es el protocolo del nivel de transporte que, a diferencia de TCP, no es orientado a conexión y no es fiable. Es el

protocolo más sencillo, más rápido, usado para aplicaciones multimedia y comunicaciones en las que se puede permitir la perdida de algún datagrama. Los

datagramas UDP se encapsulan dentro de la parte de datos de un datagrama IP.

Mostramos a continuación el formato de la cabecera de un datagrama UDP:

La salida tcpdump/windump en hexadecimal:

IP 192.168.1.30.137 > 192.168.1.41.137: UDP, length 620x0000: 4500 005a d5cd 0000 8011 e12d c0a8 011e E..Z.......-....0x0010: c0a8 0129 0089 0089 0046 b453 824c 8500 ...).....F.S.L..0x0020: 0000 0001 0000 0000 2045 4d45 4445 4245 .........EMEDEBE0x0030: 4e46 4145 5046 4a43 4143 4143 4143 4143 NFAEPFJCACACACAC0x0040: 4143 4143 4143 4143 4100 0020 0001 0004 ACACACACA.......0x0050: 93e0 0006 0000 c0a8 011e ..........Hemos marcado con color amarillo la parte correspondiente a UDP y color azul la correspondiente a la cabecera IP.

0089 Puerto de orígen (16 bits). En este caso 137.

0089 Puerto de destino (16 bits). En este caso 137.

0046 Longitud (16 bits) es la longitud expresada en bytes del datagrama. Incluye cabecera y datos del fatagrama. En este caso 70 bytes. el valor

mínimo es 8.

b453 Suma de control o Checksum (16 bits).

Es el campo de comprobación de integridad (checksum). Nos permite comprobar que los datos recibidos son correctos. Para calcular esta suma, se genera una

cabecera con los datos siguientes:

De esta cabecera conocemos todos los datos, incluso el protocol o protocolo que sería UDP. Lo sacamos de la parte correspondiente a la cabecera

IP 8011 en este caso 11 en hexadecimal corresponde a 17 decimal según esta lista:

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.

Cálculo de la suma de control. Según rfc-0768:

El campo Suma de Control (Checksum) es el complemento a uno de 16 bits de la suma de los complementos a uno de las palabras de la combinación de una

pseudo-cabecera construída con información de la cabecera IP, la cabecera UDP y los datos, y rellenada con octetos de valor cero en la parte final (si es

necesario) hasta tener un múltiplo de dos octetos.

Un valor 0 indica que no se requiere comprobación de los datos.

En las siguiente entrega veremos el protocolo ICMP.

Análisis Capturas Tráfico De Red. Interpretacion Tráfico ICMP (I).alfonn 20-02-2008 GTM 1 @ 11:13

En este artículo vamos a estudiar la interpretación de los valores hexadecimales de la

salida deTCPDump/WinDump referente al tráfico ICMP.

El protocolo internet (IP) no está diseñado para ser absolutamente fiable, es por tanto

necesario un mecanismo, entre otros objetivos, sirva para la información de errores en

el procesamiento de datagramas. Es aquí donde entra ICMP. Solo informa y no

garantiza que un datagrama sea entregado.

ICMP se encapsula dentro del datagrama IP y se considera en la misma capa que IP.

Aspectos que diferencian a ICMP de TCP o UDP   pueden ser que no tiene números de

puerto como ya hemos estudiado en anteriores capítulos, no existe el concepto cliente-

servidor y no garantiza entrega alguna. Soporta tráfico de difusión, es decir, se puede

transmitir ICMP a varios hosts. Ping o traceroute son aplicaciones que usan ICMP.

Para la notificación de errores e incidencias ICMP tiene una serie de mensajes que se

generan para cada situación.

El formato de ICMP cambia dependiendo del tipo de mensaje. Eel formato sería:

Tipo (8 bits) Tipo de mensaje ICMP. Y pueden ser:Tipo Tipo de Mensaje

0 Respuesta de Eco3 Destino Inalcanzable4 Origen saturado5 Redireccion (cambiar ruta)8 Solicitud de eco11 Tiempo excedido para un datagrama13 Problema de parametros en un datagrama13 Solicitud de fecha y hora14 Respuesta de fecha y hora17 Solicitud de nascara de direccion18 Respuesta de mascara de direccion

Codigo (8 bits) Contiene el código de error para el datagrama del que da parte el

mensaje ICMP. La interpretación depende del tipo de mensaje. Se utiliza en

algunos mensajes para distinguir, dentro de un tipo de mensaje, distintos subtipos.

Suma de control (16 bits) Campo de control de la integridad de la totalidad del

mensaje ICMP.

Datos Depende del tipo de mensaje.

Solicitud de Eco (Echo request), Respuesta de Eco (Echo reply).

Captura (1): traza o salida de Windump/Tcpdump ante un ping a la dirección de

difusión de la red. 192.168.1.255

 

IP 192.168.1.30 > 192.168.1.255: icmp echo request, id 768, seq 19968

0x0000 4500 003c 5db1 0000 8001 53bb c0a8 0403 

0x0010 c0a8 0401 0800 fc5b 0300 4e00 6162 6364 

0x0020 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 

0x0030 7576 7761 6263 6465 6667 6869

Esta traza vendría seguida por esta otra (Echo Reply):

 

IP 192.168.1.244 > 192.168.1.30: icmp echo reply, id 768, seq 19968

0x0000 4500 003c c403 0000 8001 ed68 c0a8 0401 

0x0010 c0a8 0403 0000 045c 0300 4e00 6162 6364 

0x0020 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 

0x0030 7576 7761 6263 6465 6667 6869

 

Hemos marcado de color azul la zona que nos interesa. Ya lo hemos estudiado en

el datagrama IP, marcamos en verde la clave que nos dice el tipo de protocolo (ICMP).

En amarillo el campo Datos o Data.

Estudiamos primero el echo request (la primera traza)

Tipo 08 solicitud de eco

Código 0 tanto para echo reply como para echo request el codigo es siempre 0.

Se utiliza en algunos mensajes para distinguir, dentro de un tipo de mensaje,

distintos subtipos.

Suma de control fc5b

Identificador, ID o PID 0300 (es el mismo para las dos trazas)

Número de secuencia 4e00 (19968) para el echo request y 4e00 (19968) echo

reply. Simula, en cierta manera, los números de secuencia que vimos en

el segmento TCP. Este número se va incrementando para un mismo identificador

(0300) como ya hemos visto. Si tenemos varias respuestas de eco (echo reply)

para un mismo echo request, este número se va incrementando, pero el

Identificador sería el mismo. Lo vemos en la secuencia de trazas de la captura (1)

más arriba.

Aquí vemos de forma práctica los conceptos Identificador o ID y Número de

secuencia. Lanzamos un ping a la dirección de difución de la red (192.168.1.255). el

identificador es el mismo (768), elnúmero secuencia es distinto para cada grupo

de echo reply que antiende a un echo request, vemos además que se va

incrementando:

Datos o Data Se incluyen diferentes datos, normalmente sin significado. tiene

distinta implementación en Windows y Linux por ejemplo. Es el mismo, como

vemos en la zona marcada de amarillo en la traza, tanto para el echo

request como para el echo reply.

Vamos a ver un poco más del campo Data. Si traducimos los valores haxadecimales a

ASCII vemos:

61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop

71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi

Esta sería la implementación para Windows y es identificativo para un ping.

Como curiosidad podemos decir que podemos generar con un constructor de paquetes

tipo nemesis o Engage packet builder un paquete ICMP del tipo echo request con

el contenido Data que queramos.

En nemesis lo haríamos con la opción -P fichero.txt con el contenido del campo data.

En Engage packet builder:

En proximos capítulos estudiaremos otros tipos de mensajes.

Análisis Capturas Tráfico De Red. Interpretacion Tráfico ICMP (II).alfonn 22-02-2008 GTM 1 @ 11:30

Vamos a estudiar en este artículo otro de los mensajes frecuentes:

Time to Live exceeded in Transit.

Cuando realizamos en un sistema Windows un tracert para ver la ruta o camino que toman los paquetes, routers intermedios y lantencia de cada salto, este se

ecuentra implementado transmitiendo paquetes ICMPcon distintos valores en el campo TTL "Time To Live" de la cabecera IP. En

sistemas Linux traceroute envía datagramas UDP.

Tracert determina la ruta enviando el primer paquete de eco con un TTL de 1 y aumentando el TTL en 1 en cada transmisión posterior, hasta que el destino

responde o hasta que se alcanza el TTL máximo. La ruta se determina examinando los mensajes de ICMP Tiempo agotado devueltos por los enrutadores

intermedios.

Cada router que recibe un paquete es responsable de reducir el TTL en 1, cuando un router recibe un paquete con TTL de 0, lo descarta y debe responder al

equipo origen con un paquete icmp tipo 11 (time to live exceeded).

El campo TTL es reducido en cada salto, es decir, cada vez que un router recibe el paquete. Cuando un router reduce el campo TTL de un paquete a cero, lo

descarta y genera un paquete ICMP con código "Time to Live exceeded in Transit".

El campo TTL además tiene una gran importancia dentro del datagrama IP en en el cual va encapsulado ICMP ya que impide que un mensaje esté dando

vueltas de forma indefinida por la red.

El formato de ICMP para este tipo de mensaje (Time to Live exceeded in Transit) sería:

Al realizar un tracert, obtenemos la siguiente traza (gráfico 2). En esta caso parte de la traza:

Vamos a estudiar el siguiente paqueste, respuesta time exceeded in-transit de la traza anterior:

IP 10.5.132.1 > 192.168.1.30: ICMP time exceeded in-transit, length 36

0x0000: 45c0 0038 9790 0000 fd01 d5a7 0a05 8401

0x0010: c0a8 011e 0b00 62c3 0000 0000 4500 005c

0x0020: 9790 0000 0101 86e4 c0a8 011e d504 82d2

0x0030: 0800 b6cb 0300 5200

Hemos marcado de color azul la zona que nos interesa. Ya lo hemos estudiado en el datagrama IP, marcamos en verde la clave que nos dice el tipo de

protocolo (ICMP).

Tipo 0b (11) Mensaje de Tiempo Superado ("Time Exceeded Message")

Código 0

0 = tiempo de vida superado en tránsito;

1 = tiempo de reensamblaje de fragmentos superado. Suma de control 62c3

0000 0000 sin usar.

Vemos en el gráfico 2 el envio de paquetes ICMP con un TTL = 1 (marcado en amarillo):

0x0000: 4500 005c 9783 0000 0101 0881 c0a8 011e

Si observamos la progesión de la traza vemos también como se incrementa el valor de TTL en 1 en el envio de paquetes ICMP a cada salto de router:

0x0000: 4500 005c 9786 0000 0201 077e c0a8 011e

0x0000: 4500 005c 978f 0000 0301 0675 c0a8 011e

En este tracert el valor TTL se incrementó hasta 07 (siete saltos). Alcanzó el host o máquina de destino en 7 saltos. TTL se incrementa hasta que encuentra el

host destino o hasta superar el límite, por defecto este limite está establecido en TTL = 30.

Si no encuentra el host destino y mientras se supera el valor de 30 saltos por defecto, el host origen seguirá enviando solicitudes de eco:  Eco request .

Cuando un router recibe un paquete icmp en el tracert con el valor, por ejemplo TTL=3, se lo reenvia al siguiente que hay en el camino entre host origen y

host destino que además lo decrementa en 1, estableciendo el valor en TTL = 2 y así hasta el valor TTL = 0 que es cuando este último router devuelve un

paquere con codigo 11 de Time exceeded y un código 0 de Tiempo de vida superado en tránsito. Pero además contiene la dirección IP de ese router, asi

que el host origen del tracert vuelve a enviar un paquete icmp con valot del TTL +1, en este caso TTL = 4 (siguiendo el ejemplo) que el router decrementará

en 1.... así sucesivamente hasta encontrar el router destino.

NOTA: En un próxima actualización incluiré un gráfico más explicativo de este proceso.