INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA
UNIDAD ADOLFO LÓPEZ MATEOS - ZACATENCO
ACADEMIA DE COMPUTACIÓN
LABORATORIO DE DESARROLLO DE REDES
PRACTICA No.7
PRÁCTICA 7.- SNIFFER
1. Objetivo:
Al término de esta práctica el alumno será capaz de:
♦ Comprender los conceptos básicos de monitoreo de tráfico de red.
♦ Realizar configuraciones básicas en switch-routers Enterasys mediante comandos de rutas estáticas.
♦ Uso de un sniffer comercial (Ethereal).
2. Material
♦ Cables Rectos y cables cruzados
♦ XSR, SSR 8000, Linux y HUB
♦ Práctica No. 6 – Ruteo Estático
3. Introducción
3.1 ¿Qué es un Sniffer?
Se puede definir como Sniffer a un proceso que detecta el tráfico que se genera en la red a nivel de enlace; de este modo puede leer toda la información que circula por el tramo de red en el que se encuentre. A través de este método se pueden capturar claves de acceso, datos que se transmiten, números de secuencia, etc.
3.2 ¿Qué es un Analizador de Protocolos?
Un analizador de protocolos es un sniffer al que se le ha agregado funcionalidad suficiente como para entender y traducir los protocolos que se están hablando en la red. Debe tener suficiente funcionalidad como para entender las tramas de nivel de enlace, y los paquetes que transporten.
3.3 ETHERNET
La red LAN Ethernet actual esta establecido en el estándar IEEE 802.3 y se desarrolla a partir de una tecnología original diseñada en 1980 por un investigador de la compañía XEROX.
En 1985 las compañías DEC, INTEL y XEROX crearon la arquitectura de red local llamada ETHERNET DIX. Esta red LAN usa el método de acceso CDSMA/CD en el cual las terminales compiten por el uso del medio.
FORMATO DE LA IEEE 802.3.
Preámbulo SFD DA SA Tipo Datos PAD CRC
PREAMBULO: Es una secuencia de 7 octetos, cada una de las cuales tienen el formato
10101010 y cuyo fin es permitir al receptor, sincronizarse con el transmisor.
SFD: (start of frame). Es el comienzo de la trama del tamaño de octeto e indica el inicio de la
trama, el formato es 10101011.
DA: (Destination Address) o dirección destino de la trama. Este campo es usualmente de 6
0 - Indica que es una dirección ordinaria, es decir una dirección que identifica una sola terminal 1 - Indica que es una dirección de grupo. En este caso un conjunto de terminales escuchan una misma dirección. Esta forma de direcciones es llamada dirección multicast. Si la dirección destino consiste solo de unos es llamada dirección broadcast, es decir, el paquete es para todas la terminales de la red.
SA: (Source Address) o dirección fuente. Es la dirección de la PC´s que envía la trama su
longitud es de 6 octetos.
Tipo: Es un campo de 2 octetos que indica que protocolo de la capa siguiente superior va
dirigido o quien origino la trama de capa 2.
DATOS: Este campo lleva los datos del nivel LLC o los de capa de red.
PAD: Puede ser de cero a 46 bytes y se usa para llenar una trama con octetos si el campo de
“Datos” es menor que 46 bits. Esto se debe a que una trama válida en Ethernet debe tener una longitud mínima de 64 octetos. Comprendiendo los campos de DA a CRC. Considerando que las longitudes de esos campos son las siguientes:
DA = 6 octetos SA = 6 octetos Longitud = 2 octetos CRC = 4 octetos Total = 18 octetos.
Y dado que la longitud desde DA a CRC debe dar al menos de 64 octetos; se tiene que 64-18=46 octetos. De modo que si los datos LLC o los de capa 3 llegaran a ser de una longitud menor que de 46 octetos el campo PAD se rellena de octetos hasta alcanzar ese número.
CRC: Es una sección de 4 octetos para verificación de error y estos 32 bits se genera en base
al algoritmo CRC.
3.4 Protocolo IP
IP es el principal protocolo de la capa de red. Este protocolo define la unidad básica de transferencia de datos entre el origen y el destino, atravesando toda la red e inclusive otras redes. Además, el software IP es el encargado de elegir la ruta más adecuada por la que los datos serán enviados. Se trata de un sistema de entrega de paquetes (llamados datagramas
IP) que tiene las siguientes características:
- Es no orientado a conexión debido a que cada uno de los paquetes puede seguir rutas distintas entre el origen y el destino. Entonces pueden llegar duplicados o desordenados.
- Es no fiable porque los paquetes pueden perderse, dañarse o llegar retrasados.
Nota: El protocolo IP está definido en la RFC 791
3.4.1 Formato del datagrama IP
El datagrama IP es la unidad básica de transferencia de datos entre el origen y el destino. Viaja en el campo de datos de las tramas físicas de las distintas redes que va atravesando (como puede ser la trama Ethernet). Cada vez que un datagrama tiene que atravesar un ruteador, el datagrama saldrá de la trama física de la red que abandona y se
acomodará en el campo de datos de una trama física de la siguiente red. Este mecanismo
3.4.2 Campos del datagrama IP:
A continuación explicamos los campos del encabezado de un paquete IP de la figura 2
¾ VERS (4 bits). Indica la versión del protocolo IP que se utilizó para crear el datagrama. Actualmente se utiliza la versión 4 (IPv4) aunque ya se están preparando las especificaciones de la siguiente versión, la 6 (IPv6).
¾ HLEN (4 bits). Longitud de la cabecera expresada en múltiplos de 32 bits. El valor mínimo es 5, correspondiente a 160 bits = 20 bytes.
¾ Tipo de servicio (Type Of Service). Los 8 bits de este campo se dividen a su vez en: • Prioridad (3 bits). Un valor de 0 indica baja prioridad y un valor de 7, prioridad
máxima.
• Los siguientes tres bits indican cómo se prefiere que se transmita el mensaje, es decir, son sugerencias a los encaminadores que se encuentren a su paso los cuales pueden tenerlas en cuenta o no.
• Bit D (Delay). Solicita retardos cortos (enviar rápido).
• Bit T (Throughput). Solicita un alto rendimiento (enviar mucho en el menor tiempo posible).
• Bit R (Reliability). Solicita que se minimice la probabilidad de que el datagrama se pierda o resulte dañado (enviar bien).
Los siguientes dos bits no tienen uso.:
Figura 1. Encapsulado de un paquete IP por una trama de capa 2
Figura 2 Encabezado del paquete IP
¾ Longitud total (16 bits). Indica la longitud total del datagrama expresada en bytes. Como el campo tiene 16 bits, la máxima longitud posible de un datagrama será de 65535 bytes. ¾ Identificación (16 bits). Número de secuencia que junto a la dirección origen, dirección
destino y el protocolo utilizado identifica de manera única un datagrama en toda la red. Si se trata de un datagrama fragmentado, llevará la misma identificación que el resto de fragmentos.
¾ Banderas o indicadores (3 bits). Sólo 2 bits de los 3 bits disponibles están actualmente utilizados. El bit de Más fragmentos (MF) indica que no es el último datagrama. Y el bit de
No fragmentar (NF) prohíbe la fragmentación del datagrama. Si este bit está activado y en
¾ Desplazamiento de fragmentación (13 bits). Indica el lugar en el cual se insertará el fragmento actual dentro del datagrama completo, medido en unidades de 64 bits. Por esta razón los campos de datos de todos los fragmentos menos el último tienen una longitud múltiplo de 64 bits. Si el paquete no está fragmentado, este campo tiene el valor de cero. ¾ Tiempo de vida o TTL (8 bits). Número máximo de segundos que puede estar un
datagrama en la red de redes. Cada vez que el datagrama atraviesa un ruteador se resta 1 a este número. Cuando llegue a cero, el datagrama se descarta y se devuelve un mensaje ICMP de tipo "tiempo excedido" para informar al origen de la incidencia.
¾ Protocolo (8 bits). Indica el protocolo utilizado en el campo de datos: 1 para ICMP, 2 para IGMP, 6 para TCP y 17 para UDP.
¾ CRC cabecera (16 bits). Contiene la suma de comprobación de errores sólo para la cabecera del datagrama. La verificación de errores de los datos corresponde a las capas superiores.
¾ Dirección origen (32 bits). Contiene la dirección IP del origen. ¾ Dirección destino (32 bits). Contiene la dirección IP del destino.
¾ Opciones IP. Este campo no es obligatorio y especifica las distintas opciones solicitadas por el usuario que envía los datos (generalmente para pruebas de red y depuración). ¾ Relleno. Si las opciones IP (en caso de existir) no ocupan un múltiplo de 32 bits, se
completa con bits adicionales hasta alcanzar el siguiente múltiplo de 32 bits (recuérdese que la longitud de la cabecera tiene que ser múltiplo de 32 bits).
3.5 Protocolo ICMP
Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar defectuosos a su destino. El protocolo ICMP (Internet Control Message Protocol, protocolo de mensajes de control y error) se encarga de informar al origen si se ha producido algún error durante la entrega de su mensaje. Pero no sólo se encarga de notificar los errores, sino que también transporta distintos mensajes de control.
Nota: El protocolo ICMP está definido en la RFC 792
El protocolo ICMP únicamente informa de incidencias en la red pero no toma ninguna decisión. Esto será responsabilidad de las capas superiores. Los mensajes ICMP viajan en el campo de datos de un datagrama IP, como se puede apreciar en la figura 3:
Figura 3. Encapsulado del protocolo ICMP por un paquete IP
Debido a que el protocolo IP no es fiable puede darse el caso de que un mensaje ICMP se pierda o se dañe. Si esto llega a ocurrir no se creará un nuevo mensaje ICMP sino que el primero se descartará sin más.
Los mensajes ICMP comienzan con un campo de 8 bits que contiene el tipo de mensaje, según se muestra en la tabla siguiente. El resto de campos son distintos para cada tipo de mensaje ICMP.
Campo de tipo Tipo de mensaje ICMP
0 Respuesta de eco (Echo Reply)
3 Destino inaccesible (Destination Unreachable)
4 Disminución del tráfico desde el origen (Source Quench) 5 Redireccionar (cambio de ruta) (Redirect)
8 Solicitud de eco (Echo)
11 Tiempo excedido para un datagrama (Time Exceeded) 12 Problema de Parámetros (Parameter Problem)
13 Solicitud de marca de tiempo (Timestamp)
14 Respuesta de marca de tiempo (Timestamp Reply) 15 Solicitud de información (obsoleto) (Information Request) 16 Respuesta de información (obsoleto) (Information Reply) 17 Solicitud de máscara (Addressmask)
18 Respuesta de máscara (Addressmask Reply)
3.5.1 Solicitud y respuesta de eco
Los mensajes de solicitud y respuesta de eco, tipos 8 y 0 respectivamente, se utilizan para comprobar si existe comunicación entre 2 hosts a nivel de la capa de red. Estos mensajes comprueban que las capas física (cableado), acceso al medio (tarjetas de red) y red (configuración IP) están correctas. Sin embargo, no dicen nada de las capas de transporte y de aplicación las cuales podrían estar mal configuradas; por ejemplo, la recepción de mensajes de correo electrónico puede fallar aunque exista comunicación IP con el servidor de correo.
La orden PING envía mensajes de solicitud de eco a un host remoto e informa de las
respuestas. Veamos su funcionamiento apoyándonos de la figura 4, en caso de no producirse incidencias en el camino.
1. A envía un mensaje ICMP de tipo 8 (Echo) o Ping a B
2. B recibe el mensaje y devuelve un mensaje ICMP de tipo 0 (Echo Reply) o respuesta del Ping a A
3. A recibe el mensaje ICMP de B y muestra el resultado en pantalla
Figura 4 Ping entre A y B A>ping 172.20.9.7 -n 1
Haciendo ping a 172.20.9.7 con 32 bytes de datos:
Respuesta desde 172.20.9.7: bytes=32 tiempo<10ms TDV=128
En la orden anterior hemos utilizado el parámetro "-n 1" para que el host A únicamente envíe 1 mensaje de solicitud de eco. Si no se especifica este parámetro se enviarían 4 mensajes (y se recibirían 4 respuestas). Si el host de destino no existiese o no estuviera correctamente configurado recibiríamos un mensaje ICMP de tipo 11 (Time Exceeded). Si tratamos de acceder a un host de una red distinta a la nuestra y no existe un camino para llegar hasta él, es decir, los ruteadores no están correctamente configurados o estamos intentando acceder a una red aislada o inexistente, recibiríamos un mensaje ICMP de tipo 3 (Destination
Unreachable), como se ve en el siguiente ejemplo:
A>ping 1.1.1.1 -n 1
Haciendo ping a 1.1.1.1 con 32 bytes de datos:
4. Desarrollo:
NOTA IMPORTANTE:
Se usará la práctica 6, como referencia para efectuar nuevamente ruteo estático, pero se realizará ahora con el siguiente diagrama, tomando en cuenta que ahora se usarán solo dos Ruteadores.
Figura 5.
4.1 Realice las configuraciones y conexiones que se muestran en la figura 5. Recuerde que se deben configurar las rutas estáticas con apoyo de los comandos de la práctica 6 en cada ruteador.
4.2 Una vez configurado el ruteo estático haga PING’s entre la PC-1 y PC-2 para comprobar el funcionamiento del mismo (que haya comunicación entre todas las subredes). Obtenga la dirección de las siguientes PC´s:
PC-1:____________ PC-2 ___________
4.3 Se hará el monitoreo de la siguiente forma:
¾ Haga PING de la PC-1 a la PC-2 y capture los paquetes desde la PC-3 ¾ Capture los paquetes desde la PC-1
¾ Capture los paquetes desde la PC-2
¾ Se obtendrán los datos necesarios para llenar las tablas del punto 4.8
4.4. Entrar al Sniffer -Ethereal- y presionar en el menú: “Capture” como se muestra en la figura 6, esto nos abrirá una ventana que se muestra en la figura 7a y 7b. Esto quiere decir que empezaremos a capturar el tráfico de la red, mediante el Sniffer desde el punto donde se encuentra el HUB solamente.
4.5. Seleccionar la tarjeta de red por medio de la cuál monitorearemos el tráfico de la red, como se muestra en la figura 7a, y enseguida seleccionar la casilla “capturar paquetes en modo promiscuo” como se muestra en la figura 7b.
4.6. Una vez que se realizó lo anterior daremos OK, comenzará la captura, y nos abrirá una ventana como la figura 8, nosotros determinaremos el tiempo de monitoreo por lo que presionaremos STOP cuando hayamos terminado la captura de paquetes y obtendremos la figura 9
4.7. Filtrado de paquetes. Esto lo usamos cuando tenemos demasiados paquetes capturados, así que en la barra de herramientas inferior de nuestra ventana principal hay una casilla (Filter) que sirve para una búsqueda más rápida, por ejemplo escribiremos “ICMP” (que es el protocolo al que pertenece el “PING”) y daremos “Apply “, esto nos mostrará solamente los paquetes que contengan datos sobre el protocolo ICMP.
Figura 7a.- Seleccionar Tarjeta de red Figura 7b.- Seleccionar modo promiscuo
Figura 9.- Paquetes específicos.
4.8 Llene las lineas de campos con el monitoreo del Sniffer de la PC-3.
4.9 Llene las líneas de los campos con el monitoreo del Sniffer de la PC-1.
4.10 Llene las líneas de los campos con el monitoreo del Sniffer de la PC-2.
Cuestionario:
1. ¿Qué valor aparece en el campo “Tipo” del encabezado Ethernet y que significa?
2. ¿De quien son las direcciones IP que aparecen en los monitoreos de las tres subredes?
3. ¿De quien son las direcciones de Capa 2 que aparecen en los monitoreos de las tres subredes?
4. ¿Qué papel juega el gateway o puerta de enlace? ¿Qué dirección nos poporciono?
5. ¿Qué es el encapsulado?
