LABORATORIO DE REDES. MONITORIZACIÓN DEL TRÁFICO DE RED MEDIANTE LA HERRAMIENTA tcpdump PRÁCTICA 2 1. INTRODUCCIÓN

Transcripción

1 LABORATORIO DE REDES PRÁCTICA 2 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 de la LAN en la que se encuentra un ordenador, 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 Sistema Operativo o del tipo de red. 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 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. Este 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 1

2 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 provocará 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 para la monitorización de la red. 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 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 del sistema). 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 parámetros 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 2

3 ack: window: urgent: options: desde primero a ultimo (sin incluir ultimo) hay un total de n bytes de datos. es el número de secuencia del próximo byte que espera recibir el otro extremo TCP/UDP. es el tamaño de la ventana que notifica el receptor al emisor. indica que hay datos urgentes en ese segmento/datagrama. 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 obtenidas por tcpdump: rtsg.1023 > csam.login: S :768512(0) win 4096 <mss 1024> csam.login > rtsg.1023: S :947648(0) ack win 4096 <mss 1024> rtsg.1023 > csam.login:. ack 1 win 4096 rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096 csam.login > rtsg.1023:. ack 2 win 4096 rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077 csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1 csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1 Este ejemplo 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 ventana de 4096 bytes. SYN de csam -> rtsg ISN 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 se especifique 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. A continuación se muestra el resultado de una ejecución de tcpdump desde el puesto10 del laboratorio, donde puesto24 es usado como el receptor del tráfico. Redes% tcpdump i eth0 17:58: > telnet:P : (32) ack win (DF) 3

4 donde se indica que a las 17:58: se genera un segmento con origen (puesto10) y destino (puesto24) (existen opciones para trabajar con nombres en lugar Los puertos TCP usados son el en el puesto10 origen y el puerto telnet (21) en el puesto24 destino. P indica que el parámetro PUSH del segmento TCP estaba activado. Se observa que puesto10 ha enviado 32 bytes de datos con números de secuencia comprendidos entre el y el 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 y espera que el próximo que envíe sea el Finalmente, puesto10 anuncia una ventana de 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: > puesto10.unex.es > puesto24.unex.es.telnet:. 1:1(0) ack 1 win 5840 <nop,nop,timestamp > (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. IHL, ttl, versión, 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) 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. 4

5 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: > : 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). Iniciando el sistema con Trinux, desde puesto20 se hace una conexión telnet a puesto21, mientras en una segunda sesión de puesto20 (Alt+F2) se ejecuta tcpdump. Siguen las líneas a ejecutar desde puesto20: #telnet #tcpdump xa Un datagrama obtenido por tcpdump podría ser el siguiente (Ctrl-S congela el scroll de pantalla para observar los valores con detenimiento y Ctrl-Q lo descongela): 15:08: eth0 < telnet > : P 1:13(12) ack 1 win 5792 <nop,nop,timestamp > (DF) [tos 0x10] c08d e 9e e f6 38fc d3ee 19df a0 537f a 0295 f d8 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: 5

6 Campo de cabecera IP Hex Binario Significado IP version (4 bits) Versión 4 IP. Header length (4 bits) El tamaño de la cabecera es 5*4=20 bytes. TOS (8bits) Se solicita un servicio con prioridad 0 (normal), seguridad 1 (alta), retardo 0 (bajo) y rendimiento 0 (normal). Total length (16 bits) La longitud total del datagrama es 64 bytes Identification (16 bits) c08d La secuencia de identificación del datagrama es c08d. Flags (3 bits) El bit de más fragmentos (MF) está desactivado y el de no fragmentar (DF) activado. Fragment Offset(13 bits) El desplazamiento es de 0 bytes TTL (8 bits) El tiempo de vida es de 64 puntos de enrutamiento. Protocol type (8 bits) El tipo de protocolo es 6 (TCP). Checksum (16 bits) 798e La suma de comprobación del CRC es igual a 798e. (32 bits) 9e La dirección IP origen es IP (32 bits) 9e La dirección IP destino es A continuación se propone resolver el siguiente ejercicio. Establecer una conexión ftp (o telnet) entre dos máquinas del laboratorio (ftp 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 IP, ttl, etc...). 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) (*) 6

7 TTL (8 bits) Protocol type (8 bits) Checksum (16 bits) (32 bits) 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 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. 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 f...) 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 ) 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 en que se usen cuentas de usuario personales. 7

8 Para realizar este ejercicio se realiza desde puesto20 un telnet a puesto21 (#telnet ) 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 capturados por tcpdump en el puesto21, donde pueden observarse cada uno de los caracteres de la contraseña tecleada por el usuario que desde el puesto20 accede a la cuenta usuario del puesto21. Nota: se muestran los dos primeros caracteres de la contraseña subrayados y en negrita. 15:08: eth0 < telnet > : P 119:129(10) ack 50 win 5792 <nop,nop,timestamp > (DF) [tos 0x10] e c09b e e f d3ee 1a a0 9a a 0295 fc c f a20 E^P y 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: eth0 > > telnet:. 50:50(0) ack 129 win 5840 <nop,nop,timestamp > (DF) e a 9e e d3ee 1a10 21f6 397c d a c fc61 E^@ ^@ 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: eth0 > > telnet: P 50:51(1) ack 129 win 5840 <nop,nop,timestamp > (DF) f e e d3ee 1a10 21f6 397c d0 11bb a a 0295 fc61 70 E^@ ^@ 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 15:08: eth0 < telnet > :. 129:129(0) ack 51 win 5792 <nop,nop,timestamp > (DF) [tos 0x10] c09c b 9e e f6 397c d3ee 1a a0 819d a 0295 fcb a E^P y b^u.. 1 b^t ^@^W..^A! ^Z^Q..^P ^V..... ^@^@ ^A^A ^H^J ^B..... ^@^B ^U^Z 15:08: eth0 > > telnet: P 51:52(1) ack 129 win 5840 <nop,nop,timestamp > (DF) e e d3ee 1a11 21f6 397c d0 0c a d 0295 fcb7 75 E^@ ^@ 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 8

9 15:08: eth0 < telnet > :. 129:129(0) ack 52 win 5792 <nop,nop,timestamp > (DF) [tos 0x10] c09d a 9e e f6 397c d3ee 1a a0 815a a 0295 fcd d E^P y b^u.. 1 b^t ^@^W..^A! ^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 Red Hat. 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 realicen solamente al host origen. La siguiente figura muestra cómo los mensajes ICMP van encapsulados en datagramas IP: 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. 9

10 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 éstos 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. 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 10

11 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 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: eth0 > > : icmp: echo request (DF) f4 9e e31 623e b8 3d c d fb ffbf 8cfa ffbf 6cfa ffbf cdd b499 0f40 24fb ffbf b499 0f40 b499 0f40 0e a0d7 0f40 E^@ ^@ b^t.. 1 b > ^H^@ R.. =^A ^B^@.. ^U S ^G^@ P.. ^G^H ^A^@ ^@^@ l $ ^N^@ ^@^@... 15:15: eth0 < > : icmp: echo reply (DF) edf 4000 ff01 0c14 9e31 623e 9e ab8 3d c d fb ffbf 8cfa ffbf 6cfa ffbf cdd b499 0f40 24fb ffbf b499 0f40 b499 0f40 0e a0d7 0f40 E^@ ^@ T ^L^T.. 1 b >.. 1 b^t ^@^@ Z.. =^A ^B^@.. ^U S ^G^@ P.. ^G^H ^A^@ ^@^@ l $ ^N^@ ^@^@... 15:15: eth0 > > : icmp: echo request (DF) f4 9e e31 623e b8 3d a29 c d fb ffbf 11

12 8cfa ffbf 6cfa ffbf cdd b499 0f40 24fb ffbf b499 0f40 b499 0f40 0e a0d7 0f b^t.. 1 b > ^H^@ S.. =^A ^C^@.. ^R S ^G^@ P.. ^G^H ^A^@ ^@^@ l $ ^N^@ ^@^@... 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 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 Hex. Significado 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) (32 bits) IP (32 bits) Campos de cabecera ICMP Tipo Código Cheksum PID del ping emisor Número de secuencia Hex. Significado 12

13 ANEXO: Código ASCII: Hexadecimal/Character 00 NUL 01 SOH 02 STX 03 ETX 04 EOT 05 ENQ 06 ACK 08 BS 09 HT 0A NL 0B VT 0C NP 0D CR 0E SO 10 DLE 11 DC1 12 DC2 13 DC3 14 DC4 15 NAK 16 SYN 18 CAN 19 EM 1A SUB 1B ESC 1C FS 1D GS 1E RS 20 SP 21! # 24 $ 25 % 26 & 28 ( 29 ) 2A * 2B + 2C, 2D - 2E A : 3B ; 3C < 3D = 3E > 41 A 42 B 43 C 44 D 45 E 46 F 48 H 49 I 4A J 4B K 4C L 4D M 4E N 50 P 51 Q 52 R 53 S 54 T 55 U 56 V 58 X 59 Y 5A Z 5B [ 5C \ 5D ] 5E ^ 60 ` 61 a 62 b 63 c 64 d 65 e 66 f 68 h 69 i 6A j 6B k 6C l 6D m 6E n 70 p 71 q 72 r 73 s 74 t 75 u 76 v 78 x 79 y 7A z 7B { 7C 7D } 7E ~ 13