Prcticas de Redes de Computadores

LABORATORIO DE REDES
Práctica 2 Curso 2004-05
Monitorización del tráfico de red mediante la herramienta tcpdump
1. Introducción
Una de las actividades más comunes en la administración de una red es la del análisis del
tráfico que fluye por ella, ya sea para analizar el rendimiento de la red o para analizar la
seguridad de las comunicaciones. No sólo puede interesar analizar el tráfico que fluye a través
de la LAN en la que nos encontramos, sino que también puede interesar analizar el tráfico
entrante y saliente de Internet a través de los servicios que se tengan instalados (proxies,
firewalls, etc.). Este análisis de tráfico puede ser útil para la detección de problemas y, sobre
todo, para detectar tráfico no esperado, presencia de puertas traseras, escaneos de puertos y
cualquier otra intrusión.
Existen varias herramientas muy útiles, dependiendo del S.O., tipo de red, etc. Una de estas
herramientas es tcpdump que actúa como un sniffer de red, basada en la librería de captura de
paquetes (libpcap) y que funciona en plataformas GNU/Linux-UNIX. La librería libpcap
incluye un lenguaje de filtros común que convierte a tcpdump en un software muy potente y
útil.
El comando tcpdump es una herramienta de comunicaciones elaborada en la Universidad
de California (Lawrence Berkeley National Laboratory, LBNL) para la monitorización de redes.
Permite monitorizar, tanto una interfaz Ethernet, como una comunicación punto a punto (ej.
puerto serie).
En realidad, tcpdump es un programa de red que pone la tarjeta de red de un ordenador en
modo promiscuo; es decir, recibe todos los paquetes/tramas que pasan por esa interfaz,
independientemente de que la dirección MAC destino sea la de la tarjeta (normalmente la tarjeta
sólo captura aquellas tramas que contienen su dirección destino). Eso significa que tcpdump
captura todas las tramas que pasan por la interfaz a la que está conectada. La utilidad tcpdump
usa un software llamado BPF (BSD Packet Filter) que es el que permite poner la tarjeta en modo
promiscuo, de forma que cada vez que se transmite, o se recibe una trama por el driver de la
1
tarjeta de red, BPF recibe una copia de esa trama. De esta forma BPF puede procesar y filtrar los
paquetes de red que el usuario considera más interesantes.
El comando tcpdump permite filtrar por protocolos (ej. ip, tcp, udp, arp,
ether, fddi,...); por interfaces (ej. eth0, lo,...); por puerto TCP/UDP o dirección IP;
por dirección (origen, destino, ambas,...); etc.
Éste sniffer para sistemas Unix además de servir para monitorizar todo el tráfico de la
red, puede ser muy útil para detectar posibles problemas de seguridad como ataques ping. Sin
embargo, tcpdump presenta algunas vulnerabilidades en cuanto a la seguridad del sistema. Un
usuario remoto puede hacer que la utilidad entre en un bucle infinito. Puede enviar un paquete
especialmente preparado del tipo ISAKMP al puerto 500 en UDP para hacer que el código entre
irremediablemente en un bucle infinito. Esto provocara que la utilidad no pueda registrar
cualquier paquete adicional. La vulnerabilidad reside en la función del
isakmp_sub_print() en el archivo print_isakmp.c de la librería Pcap.
Quizás tcpump no sea la herramienta perfecta desde el punto de vista de la interpretación
sencilla de los datos mostrados (aunque existen otras herramientas gráficas que usan
tcpdump), pero sí que es de las mejores en cuanto a su potencia y a la cantidad de información
que aporta.
2. Ejercicio 1
Para comprender el funcionamiento del comando tcpdump puede usarse el comando man
de Unix (#man tcpdump). Dedicar 10 minutos a leer en el man las posibilidades de esta útil
herramienta de comunicaciones.
Los siguientes son los parámetros más interesantes que pueden indicarse en la ejecución de
tcpdump:
-a Convierte las direcciones de Red y Broadcast en Nombres.
-c Acaba tras capturar un número determinado de paquetes.
-i Escucha una interfaz determinada. Si no se especifica, tcpdump busca en la lista
de interfaces del sistema la que tenga un número menor.
-x Imprime el contenido de los paquetes en hexadecimal.
-w Registra los paquetes capturados en un archivo.
-r Lee los paquetes desde un archivo fichero que fue creado con la opción –w.
Segmentos TCP:
El formato general de salida de segmentos TCP mostrados por tcpdump es el siguiente:
fecha src > dst: flags [data-sqno ack
window urgent
options]
donde,
fecha:indica
la
hora
en
que
se
produjo
el
evento
en formato
hora:minutos:segundos.microsegundos (o milisegundos dependiendo de la
resolución del reloj).
2
src y dst: son las direcciones IP y puertos TCP/UDP de las conexiones fuente y destino.
Si no se especifica el parámetro –n se intenta resolver el nombre por DNS.
flags: son una combinación de los posibles flags de un segmento/datagrama TCP/UDP:
Puede usarser un “.” para indicar que no hay flags, o bien una combinación de:
S(SYN), F(FIN), P(PUSH), R(RST), W (tamaño de la ventana de congestión), E
(ECN echo) y “.” (no flags).
data-sqno: describe el número de secuencia de la porción de datos mostrada en el
segmento de TCP. El formato es primero:ultimo(n), que significa que desde primero
a ultimo (sin incluir ultimo) hay un total de n bytes de datos.
ack: es el número de secuencia del próximo byte que espera recibir el otro extremo
TCP/UDP.
window: es el tamaño de la ventana que notifica el receptor al emisor.
urgent: indica que hay datos urgentes en ese segmento/datagrama.
options: son las opciones TCP que suelen estar entre corchetes del tipo < >; por
ejemplo, el tamaño máximo del segmento (ej. <mss 1024>)
A continuación se muestra el listado de una de las salidas mostradas por tcpdump:
rtsg.1023 > csam.login:
csam.login > rtsg.1023:
<mss 1024>
rtsg.1023 > csam.login:
rtsg.1023 > csam.login:
csam.login > rtsg.1023:
rtsg.1023 > csam.login:
csam.login > rtsg.1023:
csam.login > rtsg.1023:
csam.login > rtsg.1023:
S 768512:768512(0) win 4096 <mss 1024>
S 947648:947648(0) ack 768513 win 4096
.
P
.
P
P
P
P
ack 1 win 4096
1:2(1) ack 1 win 4096
ack 2 win 4096
2:21(19) ack 1 win 4096
1:2(1) ack 21 win 4077
2:3(1) ack 21 win 4077 urg 1
3:4(1) ack 21 win 4077 urg 1
Esto simula una conexión originada por el ordenador rtsg con destino a csam, con el servicio
rlogin. El significado de las líneas anteriores es el siguiente:
Inicio de conexión de rtsg -> csam SYN ISN 768512 ventana de 4096 bytes.
SYN de csam -> rtsg ISN 947648 ventana de 4096, ACK del SYN anterior.
ACK del SYN enviado por csam. No hay flags.
Envío de 1 byte de datos de rtsg -> csam.. Flag PUSH activado., (los números de
secuencia son relativos al ISN a menos que especifiquemos la opción -S, en cuyo caso
pone los números de secuencia que se imprimen de manera absoluta).
ACK del byte de datos anterior por parte de csam.
19 bytes de datos de rtsg a csam.
csam envía 1 byte de datos a rtsg, y envía el ACK de los 19 bytes transmitidos por
rtsg. La ventana de recepción ha bajado en 19 bytes. Flag PUSH.
csam envía un byte de datos urgente. Flag PUSH.
Similar a la línea anterior.
3
A continuación se muestra el resultado de una ejecución de tcpdump desde el puesto10
de la sala Norba, donde puesto24 es mostrado como el receptor del tráfico.
Redes% tcpdump –i eth0
17:58:58.470000 158.49.98.10.32768 > 158.49.98.24.telnet:P
1191656817:1191656849(32) ack 2435973568 win 61320 (DF)
donde se indica que a las 17:58:58.470000 se genera un segmento con origen
158.49.98.10 (puesto10) y destino 158.49.98.24 (puesto24) (existen opciones
para trabajar con nombres en lugar de @IP).
Los puertos TCP usados son el 32768 en el puesto10 origen y el puerto telnet (21) en
el puesto24 destino.
P indica que el flag PUSH del segmento TCP estaba activado.
Se observa que puesto10 ha enviado 32 bytes de datos con números de secuencia
comprendidos entre el 1191656817 y el 1191656849. Como la conexión estaba ya iniciada
cuando comenzó su monitorización, los números de secuencia son absolutos. Si tcpdump
monitoriza una conexión desde el inicio, los números de secuencia son relativos al número de
secuencia inicial.
El puesto24 reconoce (ack) haber recibido de puesto10 el dato 2435973567 y espera
que el próximo que envíe sea el 2435973568.
Finalmente, puesto10 anuncia una ventana de 61320 bytes y solicita que no se fragmenten
(DF) los datagramas IP.
A continuación se muestra otra nueva captura obtenida en las mismas condiciones anteriores:
10:04:11.672020 > puesto10.unex.es.32768 > puesto24.unex.es.telnet:
. 1:1(0) ack 1 win 5840 <nop,nop,timestamp 116267 43363780> (DF)
En este caso “.” indica que no hay ningún flag activado. Puede comprobarse que en realidad
no se han enviado datos ya que coinciden los números de secuencia inicial y final (1:1).
Si desea visualizarse el contenido de los segmentos en hexadecimal, puede ejecutarse el
comando con los siguientes parámetros:
tcpdump –x –s100 –i eth0
tcpdump capturará los primeros 100 bytes (incluidas cabeceras IP y TCP/UDP y excluidas
las cabeceras Ethernet) del paquete. De esta forma, también podrán observarse los valores de la
cabecera IP (ej. TTL, tipo, etc...).
Fragmentos de datagramas IP:
Los datagramas fragmentados se muestran con una expresión al lado de los mismos entre
paréntesis:
(frag id:size@offset+) (frag id:size@offset)
4
id es el identificador de fragmento.
size tamaño del fragmento.
offset posición del fragmento en el datagrama original. Si existe el + al final de offset
significa que aún quedan más fragmentos. En caso de ausencia del signo + se interpreta
como que es el último fragmento de la secuencia.
Los datos del protocolo del nivel superior, sólo se imprimen en el primer fragmento
SegmentosUDP:
Un segmento UDP se muestra de la siguiente forma:
origen.srcport > destino.dsrport: udp len
origen: Nombre o dirección origen.
srcport: Puerto origen.
destino: Nombre o dirección destino.
dstport: Puerto destino
len: Longitud de los datos de usuario.
A continuación se presenta un ejemplo de captura de un segmento UDP:
12:35:21.457350 10.10.109.10.1025 > 192.168.1.2.1345: udp
121 [ttl 1]
En algunos casos, puede interpretar protocolos que vayan encapsulados en los paquetes
UDP, como NFS o DNS. El grado de detalle en la interpretación de estos protocolos dependerá
del grado de detalle que desee obtenerse con el parámetro -v.
3. Ejercicio 2
El objetivo de este ejercicio es observar los distintos campos del protocolo IP. Para ello se
capturará con tcpdump una conexión telnet o ftp (dar el login y password y a
continuación desconectarse). Por ejemplo, una conexión telnet (o ftp) ejecutada en el
ordenador puesto20 para conectarse al ordenador puesto21.
La captura con el comando tcpdump debe ser de forma que se obtenga el contenido de los
datagramas IP (parámetro –x de tcpdump). Desde puesto20 se hace una conexión telnet
a puesto21, mientras en una segunda sesión de puesto20 se ejecuta tcpdump, siguiendo
las siguientes líneas a ejecutar desde puesto20:
#telnet 158.49.98.21
#tcpdump –xa
El datagrama obtenido por tcpdump es el siguiente:
5
15:08:02.849789 eth0 < 158.49.98.21.telnet > 158.49.98.21.32769: P
1:13(12) ack 1 win 5792 <nop,nop,timestamp 43382898 135384> (DF) [tos
0x10]
4510 0040 c08d 4000 4006 798e 9e31 6215
9e31 6214 0017 8001 21f6 38fc d3ee 19df
8018 16a0 537f 0000 0101 080a 0295 f872
0002 10d8 fffd 18ff fd20 fffd 23ff fd27
A continuación se muestra una tabla con el valor en hexadecimal, en binario y el significado
de cada uno de los campos de la cabecera IP del datagrama anterior:
Campo de cabecera
IP
IP version (4 bits)
Header length (4 bits)
TOS (8bits)
Hex.
Binario
4
5
10
Total length (16 bits)
0040
Identification (16 bits)
c08d
Flags (3 bits)
4000
Fragment Offset(13
bits)
TTL (8 bits)
4000
Protocol type (8 bits)
Checksum (16 bits)
06
798e
Source @IP (32 bits)
9e31
6215
9e31
6214
Destination @ IP (32
bits)
40
Significado
0100 Versión 4 IP.
0101 El tamaño de la cabecera es 5*4=20
bytes.
00010000 Se solicita un servicio con prioridad 0
(normal), seguridad 1 (alta), retardo 0
(bajo) y rendimiento 0 (normal).
000000000010100 La longitud total del datagrama es 64*4
0 = 256bytes.
110000001000110 La secuencia de identificación del
1 datagrama es c08d.
010 El bit de más fragmentos (MF) está
desactivado y el de no fragmentar (DF)
activado.
0000000000000 El desplazamiento es de 0 bytes.
01000000 El tiempo de vida es de 64 puntos de
enrutamiento.
00000110 El tipo de protocolo es 6 (TCP).
011110011000111 La suma de comprobación es igual a
0 798e.
10011110001... La dirección IP origen es 158.49.98.21.
10011110001... La dirección IP destino es 158.49.98.20
A continuación se propone resolver el siguiente ejercicio. Establecer una conexión ftp (o
telnet) entre dos máquinas de la sala Norba (ftp –v @IP). En el caso de usar cuentas
personales se recomienda emplear contraseñas falsas o supuestas, ya que, como veremos más
adelante, la contraseña puede ser capturada. Identificar la cabecera IP del primer datagrama IP
(tomar los 20 primeros octetos). Para esto hay que escribir los campos en hexadecimal y a
continuación interpretarlos (traducir los campos que tengan un significado numérico como las @
IP, TTL, etc...).
6
Campo de cabecera IP
Hex.
Binario
Significado
IP version (4 bits)
Header length (4 bits)
TOS (8bits)
Total length (16 bits)
Identification (16 bits)
Flags (3 bits)
Fragment
Offset(13
bits)
TTL (8 bits)
Protocol type (8 bits)
Checksum (16 bits)
Source @IP (32 bits)
Destination @ IP (32
bits)
(*) Interpretar la parte binaria
•
Para ver el mapeo de caracteres ASCII en hexadecimal puede usarse el anexo al final de
este documento.
•
Los tipos de protocolos pueden encontrarse en el fichero /etc/protocols
•
Observar la correlación entre un datagrama origen y otro destino (las @IP deben estar
intercambiadas).
•
Observar la correlación entre dos datagramas con origen consecutivos: el identificador
usa números consecutivos para datagramas consecutivos. Pero atención, pues los
números son consecutivos entre todos los datagramas IP enviados. Si sólo se capturan
datagramas que encapsulan datos de una aplicación (ej. ftp), podrá comprobarse que hay
números que no son consecutivos (faltaría capturar los datagramas de otras aplicaciones
como pueden ser DNS).
A continuación de la cabecera IP se encuentra encapsulada una estructura de datos
perteneciente a otro protocolo: el campo tipo identifica este protocolo (ej. TCP, UDP. ICMP,
IGMP,...). En el caso de la aplicación telnet o ftp se usa el protocolo TCP (identificador 6).
Este protocolo contiene una cabecera de 20 octetos. A continuación de la cabecera TCP vienen
los datos. Como en el campo IP total length se almacena la longitud del datagrama IP,
basta con restar la cabecera IP y la cabecera TCP para saber el tamaño del campo de datos que
transporta el datagrama IP.
7
4. Ejercicio 3
Identificación del diálogo de aplicación telnet o ftp. Podemos comprobar que telnet
o ftp inician un diálogo en el que debe solicitarse el nombre de usuario y su contraseña.
Aunque las aplicaciones telnet y ftp desactivan el echo de pantalla para que la contraseña
no pueda ser observada, ésta se transmite sin codificar por la red. Esto significa que entre los
datos que se han capturado anteriormente se encuentra también la contraseña.
Si se observa el diálogo telnet o ftp, cuando el emisor solicita el comando 220
puesto20 FTP (cuya secuencia en hexadecimal es 3232 _______ 726f ....) está
solicitando el nombre de usuario que encontraremos en la contestación del otro. FTP solicita
con el comando 331 Password required ... (en HEX es la secuencia 3333 3120
5061 7373 ...) el destino contestará con la contraseña.
Identificar el diálogo FTP y capturar el username (login o nombre de usuario) y
password (contraseña) de la conexión. Por razones obvias se aconseja introducir contraseñas
falsas en las pruebas.
Para realizar este ejercicio se realiza desde puesto20 un telnet a puesto 21 (#telnet 158.49.98.21)
y se hace login en la cuenta usuario. Mientras tanto, en puesto21 se ha puesto su tarjeta de red
en modo promiscuo con el comando #tcpdump –xa eth0. Se muestran a continuación los
datagramas mostrados por tcpdump en el puesto 21, donde pueden observarse cada uno de los
caracteres de la contraseña de la contraseña tecleada por el usuario que desde el puesto 20
accede a la cuenta usuario del puesto21.
Nota: se muestran los dos primeros caracteres de la contraseña subrayados y en negrita.
15:08:12.924998 eth0 < 158.49.98.21.telnet > 158.49.98.20.32769: P 119:129(10)
ack 50 win 5792 <nop,nop,timestamp 43383905 136392> (DF) [tos 0x10]
4510 003e c09b 4000 4006 7982 9e31 6215
9e31 6214 0017 8001 21f6 3972 d3ee 1a10
8018 16a0 9a75 0000 0101 080a 0295 fc61
0002 14c8 5061 7373 776f 7264 3a20
E^P ^@ > .... @^@ @^F y.. .. 1 b^U
.. 1 b^T ^@^W ..^A !.. 9 r .... ^Z^P
..^X ^V.. .. u ^@^@ ^A^A ^H^J ^B.. .. a
^@^B ^T.. P a s s w o r d :
15:08:12.925006 eth0 > 158.49.98.20.32769 > 158.49.98.21.telnet: . 50:50(0)
ack 129 win 5840 <nop,nop,timestamp 136392 43383905> (DF)
4500 0034 091e 4000 4006 311a 9e31 6214
9e31 6215 8001 0017 d3ee 1a10 21f6 397c
8010 16d0 8216 0000 0101 080a 0002 14c8
0295 fc61
E^@ ^@ 4 ^I^^ @^@ @^F 1^Z .. 1 b^T
.. 1 b^U ..^A ^@^W .... ^Z^P !.. 9 |
..^P ^V.. ..^V ^@^@ ^A^A ^H^J ^@^B ^T..
^B.. .. a
15:08:13.742581 eth0 > 158.49.98.20.32769 > 158.49.98.21.telnet: P 50:51(1)
ack 129 win 5840 <nop,nop,timestamp 136474 43383905> (DF)
4500 0035 091f 4000 4006 3118 9e31 6214
9e31 6215 8001 0017 d3ee 1a10 21f6 397c
8018 16d0 11bb 0000 0101 080a 0002 151a
0295 fc61 70
E^@ ^@ 5 ^I^_ @^@ @^F 1^X .. 1 b^T
.. 1 b^U ..^A ^@^W .... ^Z^P !.. 9 |
..^X ^V.. ^Q.. ^@^@ ^A^A ^H^J ^@^B ^U^Z
^B.. .. a p
8
15:08:13.778810 eth0 < 158.49.98.21.telnet > 158.49.98.20.32769: . 129:129(0)
ack 51 win 5792 <nop,nop,timestamp 43383991 136474> (DF) [tos 0x10]
4510 0034 c09c 4000 4006 798b 9e31 6215
9e31 6214 0017 8001 21f6 397c d3ee 1a11
8010 16a0 819d 0000 0101 080a 0295 fcb7
0002 151a
E^P ^@ 4 .... @^@ @^F y.. .. 1 b^U
.. 1 b^T ^@^W ..^A !.. 9 | .... ^Z^Q
..^P ^V.. .... ^@^@ ^A^A ^H^J ^B.. ....
^@^B ^U^Z
15:08:14.091720 eth0 > 158.49.98.20.32769 > 158.49.98.21.telnet: P 51:52(1)
ack 129 win 5840 <nop,nop,timestamp 136509 43383991> (DF)
4500 0035 0920 4000 4006 3117 9e31 6214
9e31 6215 8001 0017 d3ee 1a11 21f6 397c
8018 16d0 0c41 0000 0101 080a 0002 153d
0295 fcb7 75
E^@ ^@ 5 ^I
@^@ @^F 1^W .. 1 b^T
.. 1 b^U ..^A ^@^W .... ^Z^Q !.. 9 |
..^X ^V.. ^L A ^@^@ ^A^A ^H^J ^@^B ^U =
^B.. .... u
15:08:14.091961 eth0 < 158.49.98.21.telnet > 158.49.98.20.32769: . 129:129(0)
ack 52 win 5792 <nop,nop,timestamp 43384022 136509> (DF) [tos 0x10]
4510 0034 c09d 4000 4006 798a 9e31 6215
9e31 6214 0017 8001 21f6 397c d3ee 1a12
8010 16a0 815a 0000 0101 080a 0295 fcd6
0002 153d
E^P ^@ 4 .... @^@ @^F y.. .. 1 b^U
.. 1 b^T ^@^W ..^A !.. 9 | .... ^Z^R
..^P ^V.. .. Z ^@^@ ^A^A ^H^J ^B.. ....
^@^B ^U =
Como ejercicio se propone visualizar la contraseña de tu compañero mientras accede a la
cuenta Redes de tu sistema Linux.
5. Protocolo ICMP
El protocolo ICMP (Internet Control Message Protocol) informa de la aparición de errores
en la manipulación de los datagramas. Siempre que un router detecte un error o excepción en un
datagrama utiliza el protocolo ICMP para informar al host origen de esa circunstancia. ICMP no
realiza ninguna acción para corregir el error que se haya producido, solamente se encarga de
comunicarlo al host origen para que éste realice las acciones oportunas para corregir el error.
Inicialmente, ICMP fue diseñado como un protocolo para los routers, sin embargo los hosts
también lo pueden utilizar.
Aunque este protocolo fue diseñado para detectar las incidencias que se producen en el
transporte de un datagrama hacia el host destino, no todas ellas pueden ser detectadas. Entre
estas causas se encuentra la pérdida de un datagrama que lleva un mensaje ICMP. En este punto
podríamos pensar que para solucionar este problema, esta pérdida podría ser notificada con otro
mensaje ICMP. Más que solucionar el problema, lo estaríamos agravando cuando la razón de
esa pérdida sea una congestión en la red. Por eso, no se permite notificar mediante mensajes
ICMP la pérdida de datagramas que lleven un mensaje ICMP. De hecho, la pérdida de un
datagrama que transporta un mensaje ICMP no se notifica. Otra norma general que impone este
protocolo es que las notificaciones de error se hacen solamente al host origen.
La siguiente figura muestra cómo los mensajes ICMP van encapsulados en datagramas IP:
9
Aunque ICMP va encapsulado en un datagrama IP, eso no quiere decir que ICMP sea un
protocolo de nivel superior. Debe considerarse como parte de IP, como si fuese una herramienta
auxiliar de la que dispone IP para poder detectar errores en el transporte de los datagramas a sus
diversos destinos.
Cada tipo de mensaje ICMP tiene su propio formato, aunque todos ellos comienzan con tres
campos comunes. El resto de campos puede variar en función del tipo de mensaje. Los campos
comunes son el campo Tipo, el campo Código y el campo Checksum.
El campo Tipo identifica el tipo de mensaje ICMP. En la siguiente tabla se muestran algunos
de los tipos de mensajes que contempla este protocolo. El campo Código se usa para aportar
más información acerca del tipo de mensaje ICMP. Este campo no siempre es necesario. El
último campo contendrá el Checksum del mensaje ICMP.
La descripción de cada uno de los tipos de mensajes ICMP de la tabla anterior es la
siguiente:
• Petición de eco y Contestación de eco: Son dos mensajes que se usan conjuntamente para
determinar el alcance de un host o un router. Normalmente son utilizados por los hosts, de
forma que estos puedan extraer información acerca del estado del host remoto, el retardo
que introduce la red en la entrega de los mensajes y el porcentaje de mensajes perdidos.
• Destino inalcanzable: Se trata de un mensaje que es generado por un router cuando no
puede encaminar un datagrama. Existen diferentes causas que provocan la emisión de este
mensaje y que están codificadas en el campo Código del mensaje ICMP. El mensaje es
dirigido al host que ha enviado el datagrama y en su interior se especifican los primeros
64 bits del datagrama que lo ha causado (el que no se puede entregar al destino).
• Paquete de restricción: Es un mensaje que utilizan los routers para frenar el ritmo de
inyección de mensajes en la red de un determinado host. Esta situación se produce cuando
un router se ve sobrecargado con la recepción de datagramas (una posible situación de
congestión) teniendo que descartar algunos por falta de buffers. Cuando se produce esta
situación, el router envía un mensaje de este tipo al host origen del datagrama descartado,
solicitándole que baje el ritmo de envío de datagramas ya que en ese momento hay una
situación temporal de congestión.
10
• Tiempo de vida agotado: Cuando un router encamina un datagrama, una de sus tareas es
decrementar en una unidad el campo Tiempo de vida (TTL) de la cabecera del mismo. Si
tras la operación el campo vale "0", el router debe descartar el datagrama y enviar un
mensaje ICMP de este tipo hacia el host origen.
El objetivo de esta sección es identificar el formato de un mensaje ICMP. Recordar que este
protocolo se encarga de notificar mensajes de error así como mensajes de control. Los mensajes
ICMP van encapsulados en datagramas IP (el campo tipo de IP vale 1, como puede
comprobarse en el fichero /etc/protocols). La cabecera ICMP ocupa 4 octetos (comunes
a todos los mensajes ICMP) más una serie de octetos que depende del tipo de mensaje. Los dos
primeros octetos llamado tipo y código identifican el mensaje ICMP, los dos siguientes
octetos son un checksum de 16 bits.
Para observar este hecho vamos a capturar un mensaje ICMP con el comando tcpdump. La
aplicación ping envía mensajes ICMP ECHO REQUEST (tipo 8) a un host específico. Este
host responde con un mensaje ICMP ECHO_RESPONSE (tipo 0). El host que efectúa la
petición escribe por su salida estándar el mensaje host is alive si ha habido una respuesta
o no answer from host si en 20 segundos el host remoto no ha respondido. También es
posible que ping imprima por su salida estándar estadísticas de los paquetes que ha enviado
(retardo que han sufrido, cuántos se han perdido, etc.) ejecutando ping –s @IP.
Después de los cuatro primeros octetos típicos de ICMP, los mensajes ICMP
ECHO_REQUEST usan 2 octetos que identifican el PID del proceso ping de la máquina que
efectúa la petición de ping (esto lo hace para identificar varios ping de un mismo origen)
seguido de otros dos octetos con un número de secuencia de los paquetes enviados. A partir del
número de secuencia recibido en el echo, ping puede identificar cuántos se han perdido, o se
han desordenado o son duplicados. También puede calcular el RTT (Round Trip Time).
6. Ejercicio 4
Ejecutar el comando ping a una dirección IP y capturar con el comando tcpdump el
contenido de 2 ó 3 paquetes. Identificar en el campo de cabecera IP el tipo de protocolo (ICMP),
y en el payload de IP vendrá la cabecera ICMP donde puede identificarse el tipo y código del
paquete ICMP, identificar el PID del ping y el número de secuencia de los paquetes enviados.
15:15:37.480025 eth0 >
(DF)
4500
9e31
1553
8cfa
24fb
a0d7
158.49.98.20 > 158.49.98.62: icmp: echo request
E^@
.. 1
^U S
....
$..
....
15:15:37.480326 eth0 <
(DF)
4500
9e31
1553
8cfa
^@ T ^@^@ @^@ @^A 9.. .. 1
b > ^H^@ R.. =^A ^B^@ .. )
^G^@ P.. ^G^H ^A^@ ^@^@ ....
.... l.. .... .... ^B @ ....
.... .... ^O @ .... ^O @ ^N^@
^O @
158.49.98.62 > 158.49.98.20:
0054
623e
0700
ffbf
ffbf
0f40
0054
6214
0700
ffbf
0000 4000 4001 39f4 9e31 6214
0800 52b8 3d01 0200 9929 c740
50d9 0708 0100 0000 98fb ffbf
6cfa ffbf cdd6 0240 b499 0f40
b499 0f40 b499 0f40 0e00 0000
b^T
.. @
....
^O @
^@^@
icmp: echo reply
6edf 4000 ff01 0c14 9e31 623e
0000 5ab8 3d01 0200 9929 c740
50d9 0708 0100 0000 98fb ffbf
6cfa ffbf cdd6 0240 b499 0f40
11
24fb ffbf b499 0f40 b499 0f40 0e00 0000
a0d7 0f40
E^@
.. 1
^U S
....
$..
....
15:15:38.480022 eth0 >
(DF)
4500
9e31
1253
8cfa
24fb
a0d7
E^@
.. 1
^R S
....
$..
....
^@ T n.. @^@
b^T ^@^@ Z..
^G^@ P.. ^G^H
.... l.. ....
.... .... ^O @
^O @
158.49.98.20 >
0054
623e
0700
ffbf
ffbf
0f40
..^A
=^A
^A^@
....
....
^L^T
^B^@
^@^@
^B @
^O @
.. 1
.. )
....
....
^N^@
b >
.. @
....
^O @
^@^@
158.49.98.62: icmp: echo request
0000 4000 4001 39f4 9e31 6214
0800 53b8 3d01 0300 9a29 c740
50d9 0708 0100 0000 98fb ffbf
6cfa ffbf cdd6 0240 b499 0f40
b499 0f40 b499 0f40 0e00 0000
^@ T ^@^@ @^@ @^A 9..
b > ^H^@ S.. =^A ^C^@
^G^@ P.. ^G^H ^A^@ ^@^@
.... l.. .... .... ^B @
.... .... ^O @ .... ^O @
^O @
.. 1
.. )
....
....
^N^@
b^T
.. @
....
^O @
^@^@
En los datagramas obtenidos se puede observar que el tipo de protocolo es ICMP, ya que el
valor de este campo es 01 (en negrita). El tipo es 00 en los paquetes echo reply y 08 en los
paquetes echo request (subrayado). El campo código es igual en los tres paquetes y vale 00
(negrita, cursiva y subrayado). El PID del ping es 3d01(negrita y subrayado). Por último, los
números de secuencia de los paquetes son respectivamente 0200 y 0300.
Como ejercicio se propone rellenar las tablas siguientes a partir de los datos obtenidos al
realizar un ping al ordenador de tu compañero.
Campos de cabecera
IP
IP version (4 bits)
Header length (4 bits)
TOS (8bits)
Total length (16 bits)
Identification (16 bits)
Flags (3 bits)
Frag. Offset(13 bits)
TTL (8 bits)
Protocol type (8 bits)
Checksum (16 bits)
Source @IP (32 bits)
Destin. @ IP (32 bits)
Hex.
Significado
12
Campos de cabecera
ICMP
Tipo
Código
Cheksum
PID del ping emisor
Número de secuencia
Hex.
Significado
ANEXO: Código ASCII: Hexadecimal/Character
00
08
10
18
20
28
30
38
40
48
50
58
60
68
70
78
NUL
BS
DLE
CAN
SP
(
0
8
@
H
P
X
`
h
p
x
01
09
11
19
21
29
31
39
41
49
51
59
61
69
71
79
SOH
HT
DC1
EM
!
)
1
9
A
I
Q
Y
a
i
q
y
02 STX
0A NL
12 DC2
1A SUB
22 “
2A *
32 2
3A :
42 B
4A J
52 R
5A Z
62 b
6A j
72 r
7A z
03
0B
13
1B
23
2B
33
3B
43
4B
53
5B
63
6B
73
7B
ETX
VT
DC3
ESC
#
+
3
;
C
K
S
[
c
k
s
{
04
0C
14
1C
24
2C
34
3C
44
4C
54
5C
64
6C
74
7C
EOT
NP
DC4
FS
$
,
4
<
D
L
T
\
d
l
t
05 ENQ
0D CR
15 NAK
1D GS
25 %
2D 35 5
3D =
45 E
4D M
55 U
5D ]
65 e
6D m
75 u
7D }
06
0E
16
1E
26
2E
36
3E
46
4E
56
5E
66
6E
76
7E
ACK
SO
SYN
RS
&
.
6
>
F
N
V
^
f
n
v
~
13