En este artículo vamos a estudiar la interpretación de los valores hexadecimales de la salida de TCPDump/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), el nú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.
Seguridad y Redes 
gracias por la informacion.help me to studie
Pingback: Netsniff-ng. Un sniffer diferente de alto rendimiento. Parte I. | Seguridad y Redes
Interesante