REDES DE COMPUTADORAS SNIFFER

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

México DF. Abril de 2004

FNC/jrdc&oavr
REDES DE COMPUTADORAS SNIFFER

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

octetos (48 bits) que indica la dirección de la terminal destinaría de la trama. De los 48 bits en
el octeto del más alto orden, en el bit menos significativo, si es:

FNC/jrdc&oavr
REDES DE COMPUTADORAS SNIFFER

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
permite que un mismo datagrama IP pueda atravesar redes distintas: enlaces punto a punto,
redes ATM, redes Ethernet, redes Token Ring, etc. El propio datagrama IP tiene también un
campo de datos: será aquí donde viajen los paquetes de las capas superiores. Vea la figura 1.

FNC/jrdc&oavr
REDES DE COMPUTADORAS SNIFFER

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
una determinada red se requiere fragmentar el datagrama, éste no se podrá transmitir y se
descartará.

FNC/jrdc&oavr
REDES DE COMPUTADORAS SNIFFER

¾ 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.

Nota: El formato y significado de cada mensaje ICMP está documentado en la RFC 792

FNC/jrdc&oavr
REDES DE COMPUTADORAS SNIFFER

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:
Respuesta desde 192.168.0.1: Host de destino inaccesible.

FNC/jrdc&oavr
 REDES DE COMPUTADORAS SNIFFER

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.

Subred B
148.204.218.3/24 PC-1 148.204.219.1/24 148.204.219.2/24 PC-2 148.204.220.2/24

1 2

Subred C
Subred A 148.204.218.1/24 148.204.220.1/24

PC-3 148.204.219.3/24
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.

Figura 6.- Pantalla principal del Sniffer.

FNC/jrdc&oavr
REDES DE COMPUTADORAS SNIFFER

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.

Figura 7a.- Seleccionar Tarjeta de red Figura 7b.- Seleccionar modo promiscuo

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 8.- Captura de tráfico

FNC/jrdc&oavr
REDES DE COMPUTADORAS SNIFFER

Figura 9.- Paquetes específicos.

4.8 Llene las lineas de campos con el monitoreo del Sniffer de la PC-3.
ICMP

Versión HLong TOS … IP-Origen IP-Destino DATOS

________ ________ ___________ ___________

MAC-Fuente MAC-Destino TIPO DATOS CRC

__________________ __________________ ________

4.9 Llene las líneas de los campos con el monitoreo del Sniffer de la PC-1.

ICMP

Versión HLong TOS … IP-Origen IP-Destino DATOS

________ ________ ___________ ___________

MAC-Fuente MAC-Destino TIPO DATOS CRC

__________________ __________________ ________

FNC/jrdc&oavr
REDES DE COMPUTADORAS SNIFFER

4.10 Llene las líneas de los campos con el monitoreo del Sniffer de la PC-2.

ICMP

Versión HLong TOS … IP-Origen IP-Destino DATOS

________ ________ ___________ ___________

MAC-Fuente MAC-Destino TIPO DATOS CRC

__________________ __________________ ________

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?
6. ¿Qué diferencias existen entre el Ethernet DIX y el 802.3
7. ¿Qué es un sniffer?

Bibliografía:
http://www.linuxjournal.com
http://www.saulo.net
http://www.arrakis.es
http://www.ethereal.com

FNC/jrdc&oavr