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 0000
En 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 el Segmento 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 B
2. 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 ejemplos
 1.- 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 –p25

La traza resultante:
INFOGRAFIA3 ABANCECOMU TCP 1125 > smtp [SYN] Seq=13766490 Ack=0 Win=16384 Len=0
ABANCECOMU INFOGRAFIA3 TCP smtp > 1125 [SYN, ACK] Seq=472370892 Ack=13766491 Win=8736 Len=0
INFOGRAFIA3 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 25

La traza resultante:
ABANCECOMU INFOGRAFIA3 TCP 38428 > smtp [SYN] Seq=2093898103 Ack=0 Win=2048 Len=0
INFOGRAFIA3 ABANCECOMU TCP smtp > 38428 [SYN, ACK] Seq=3462674933 Ack=2093898104 Win=16616 Len=0
ABANCECOMU 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 62

0x0000: 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 .........EMEDEBE
0x0030: 4e46 4145 5046 4a43 4143 4143 4143 4143 NFAEPFJCACACACAC
0x0040: 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 Eco
3 Destino Inalcanzable
4 Origen saturado
5 Redireccion (cambiar ruta)
8 Solicitud de eco
11 Tiempo excedido para un datagrama
13 Problema de parametros en un datagrama
13 Solicitud de fecha y hora
14 Respuesta de fecha y hora
17 Solicitud de nascara de direccion
18 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.