SAMUEL TOLEDO HDEZ - ALU0101337821

ÍNDICE

ÍNDICE 1
INTRODUCCIÓN 2
PROTOCOLOS DE LA CAPA ENLACE 3
ETHERNET 3
ARP 4
PROTOCOLOS DE LA CAPA RED 5
IP/ICMP 5
Aspectos relacionados con la cabecera IP y sus campos 5
Fragmentación de paquetes IP 5
Funcionamiento del comando ping 6
Estudio de los mensajes ICMP asociados al comando traceroute 6
PROTOCOLOS DE LA CAPA TRANSPORTE 7
UDP 7
TCP 8
PROTOCOLOS CAPA DE APLICACIÓN 9
DNS 9
HTTP 10
Estudio de la interacción HTTP GET/respuesta básica 10
HTTP GET condicional 10
Protocolos binarios y textuales 10
CONCLUSIÓN 11
BIBLIOGRAFÍA 12

1
INTRODUCCIÓN
Para esta práctica, redactaremos un informe donde se aportará el conocimiento aprendido a
lo largo de la duración de este ejercicio sobre los distintos tipos de protocolos de red, incluyendo
Ethernet y ARP en la capa de enlace, IP y ICMP en la capa de red, UDP y TCP en la capa de
transporte y HTTP en la capa de aplicación. Para llevarlo a cabo, utilizaremos la herramienta de
análisis Wireshark, que nos va a permitir visualizar el tráfico de paquetes que circula por la red de
manera gráfica y que además posee filtros de búsqueda/información.

Para realizar esta tarea, vamos a hacer uso de ciertos comandos que nos van a ayudar al
entendimiento de los distintos protocolos.

En primer lugar usaremos el comando “ifconfig” que nos permitirá visualizar la configuración
de la interfaz de red del dispositivo (incluyendo la dirección IP y la dirección MAC) donde ejecutemos
el comando, en este caso nuestro dispositivo.

Por otro lado, también usaremos el comando ping, el cual envía paquetes de echo
request(ICMP) a una dirección IP específica dentro de una red. Nos va a permitir determinar si una
dirección IP está activa o no, y encontrar el retraso en la comunicación (retraso ida y vuelta) o
encontrar pérdida de paquetes.

Por último dentro de los comandos iniciales, nos encontramos con el comando “traceroute”.
Este nos permite visualizar la trayectoria que siguen los paquetes desde su origen hasta su destino,
aportando información sobre la velocidad de la ruta.

Para terminar es importante conocer que para los protocolos Ethernet y ARP, resulta crucial
comprender el significado de la dirección MAC, que consiste en un número entero de 48 bits utilizado
para identificar las tarjetas de red. En entornos de red, es esencial poder distinguir el dispositivo al
que se desea enviar un paquete, y para ello se emplea la dirección MAC con el objetivo de
diferenciar los distintos dispositivos de la red.

2
PROTOCOLOS DE LA CAPA ENLACE

ETHERNET

Ethernet es un protocolo muy utilizado a nivel de enlace en redes locales mediante cables.
Se ha convertido en la base del estándar IEEE 802.3. Nos vamos a centrar en el estudio de la trama
que lo compone. Esta se compone de tres partes: la cabecera, la carga útil y la cola. La cabecera, se
divide en tres campos principales: el destino (MAC del destinatario), la fuente (MAC del remitente) y
el tipo de protocolo (que indica cómo se interpreta la carga útil).

Para entender el funcionamiento de este protocolo, hemos utilizado/capturado el acceso a

una página web (http://www.gnu.org) para analizar las dos tramas de envío y recepción entre el
ordenador y la puerta de enlace. Para facilitar la visualización de la captura, hemos desactivado el
protocolo IPv4 para centrarnos en las direcciones MAC y hemos añadido el campo de tipo de
protocolo, que nos ha permitido llevar a cabo el estudio de los paquetes de manera mucho más
rápida y eficiente.

Para conocer la dirección MAC de nuestro ordenador/dispositivo, hemos utilizado el comando

ifconfig, (explicado anteriormente). La dirección IP de mi ordenador es 192.168.1.95 y la dirección
MAC es 00:d8:61:e8:50:e1, que coincide con la dirección MAC especificada en el campo fuente. En
el campo destino, podemos observar la dirección MAC a0:64:8f:b5:ec:f9, que corresponde a la
puerta de enlace. Por último, el campo Frame type indica el número hexadecimal 0x800, lo que indica
que se trata del protocolo IPv4 (cometido del campo).

En cuanto al paquete de respuesta, se puede observar que las direcciones MAC (tanto de
origen como de destino) están intercambiadas con respecto al paquete de la petición. El campo
Frame type sigue siendo 0x800, lo que indica que sigue siendo el protocolo IPv4.

En conclusión, la trama de Ethernet es fundamental para la comunicación de dispositivos en

redes locales mediante cable, y su estudio nos permite comprender mejor cómo se lleva a cabo esta
comunicación de datos.

3
ARP
El protocolo ARP, el cuál corresponde a esta parte de la práctica se utiliza para asociar
direcciones de capa de red (IP) con direcciones de capa de enlace (MAC). Su utilidad es encontrar la
dirección MAC de un dispositivo dentro de la misma red que tiene una dirección IP que ya es
conocida. Los campos que componen un paquete de ARP son: Dirección Ethernet de destino: Es la
dirección MAC de la máquina de destino a la que se envía el paquete ARP(48 bit), Dirección Ethernet
del remitente; es la dirección MAC del dispositivo que envía el paquete ARP(48 bit), Tipo de
protocolo: se indica en este campo el tipo de protocolo que se utiliza en la red. El valor para Ethernet
es 0x0806(16), entro otros.

Por otro lado también utilizaremos la tabla ARP, la cual es una tabla que se emplea para
almacenar las direcciones de capa de enlace y red asociadas. Cuando, por ejemplo, un dispositivo
necesita enviar un paquete a una dirección IP, primero busca en su tabla ARP para ver si ya tiene
una entrada para dicha dirección. Si esta ya existe, dicho dispositivo utilizará la dirección de la capa
de enlace asociada, almacenada en la tabla. Si no existiera la entrada, el dispositivo enviará una
solicitud tipo ARP para obtener la dirección de la capa de enlace que corresponde a la dirección IP.
Se manda un mensaje con la dirección IP que se busca y la MAC FF:FF:FF:FF (broadcast). Dicho
mensaje atraviesa todos los dispositivos conectados a la red, y se va preguntando individualmente si
la IP del mensaje corresponde a la IP del dispositivo conectado. Una vez lo recibe el dispositivo con
misma IP que la IP preguntada responde con su MAC y se guarda en la tabla ARP.

Para estudiar el funcionamiento del protocolo ARP vamos a utilizar el comando ping, en este
caso ping 10.209.32.132, haciendo una petición a otro ordenador de la red local de la universidad.
Primero borraremos las previas entradas de la tabla (sudo ip neigh flush all). Las direcciones que se
encuentran en la tabla pertenecen a 3159-et-wifi.com.stic.ull.es (10.159.0.1), que pertenece al
servicio de TIC (STIC) que proporciona la universidad.

Para la segunda parte de este apartado y para continuar con el estudio de la trama de la
petición ARP, filtramos los paquetes por ARP y observamos que los propios mensaje de petición
están siendo enviados por la propia dirección MAC del dispositivo, es decir: 00:d8:61:e8:50:e1 y su
destino FF:FF:FF:FF, en cambio el contenido del mensaje es simplemente la dirección IP que
buscamos/solicitamos. Dentro de la trama vemos el opcode 0001 - “petición” y los diferentes campos;
mac address, sender ip address, target mac address y target ip address, que corresponden a;
dirección MAC, dirección IP, MAC del emisor e IP del emisor, respectivamente.

Respecto a la trama de respuesta, su tipo es 0x806 correspondiente a ARP. Dentro de esta

se observa como el opcode es 0002 - “respuesta” y respecto a los valores de ip address e ip address
intercambian sus valores. Por último el contenido de la trama es nulo ya que la MAC que se estaba
buscando ya ha sido encontrada.

Si hubiéramos enviado un ping a una dirección de host de Internet, se hubiese realizado una
consulta ARP para resolver la dirección MAC del gateway de la red, siendo la dirección IP de la
consulta la dirección IP del gateway.

4
PROTOCOLOS DE LA CAPA RED

IP/ICMP
Para este apartado de la práctica nos vamos a dedicar al estudio de los protocolos IP e
ICMP. El protocolo IP de Internet Protocol, es el protocolo principal del modelo TCP/IP, y tiene como
función principal dar formato a los paquetes y a las direcciones a nivel de red. Sobre todo nos
centraremos en el estudio de la cabecera IP, la cual contiene toda la información necesaria para que
los hosts y los routers encaminen los paquetes salida-destino.

Aspectos relacionados con la cabecera IP y sus campos

La dirección IP en este apartado cambia respecto al resto de apartados debido a que

wireshark me presentaba algunos problemas para hacer el filtro de presentación “ip.src==”, por lo
cual lo realice desde un ordenador del centro de cálculo con ip 10.209.32.132 (como se observa en la
imagen). Como el protocolo que estamos utilizando es ICMP el valor del protocolo es uno “ip.proto==
0x01”. La cabecera IPv4 consta de 20 bytes fijos, y el tamaño de paquete en este caso es de 2000
bytes. Esto nos indica que el tamaño del payload será de 2000 bytes - 20 bytes de cabecera = 1980
bytes. Cada paquete tiene un identificador único y este se incrementa en uno para cada paquete que
se envía (evoluciona valor del identificador).

Fragmentación de paquetes IP
En el comando ping se puede establecer el tamaño del datagrama enviado. Mandaremos
paquetes con el comando ping www.etsii.ull.es -c 3 -s ??? con diferentes tamaños (50, 2000,
3500).Para responder a las cuestiones de la fragmentación de paquetes tenemos que;

Respecto al paquete de tamaño de 2000 bytes podemos observar como ha sido

fragmentado, esto lo sabemos debido a que gráficamente cada dos paquetes fragmentados
coloreados corresponde a un frame de envío. El primer paquete se ha fragmentado de tal manera
que; Posee uno de los flags activados 0x2000, significando así que hay más fragmentos (paquete
fragmentado). Este es el primero ya que su offset es 0. Este posee un tamaño de 1480 bytes y 20
bytes de cabecera para completar los 1500 de la longitud. En cambio el segundo fragmento tiene los
flags a 0 significando que es el último fragmento y el offset a 1480. (empieza donde acabó el primer
fragmento). Los fragmentos tienen la misma identificación pero con checksum y flags diferentes.

En cambio en el envío del paquete de 3500 bytes, se han generado 3 fragmentos a partir del
paquete original. Por lo tanto los primero dos fragmentos tienen los flags activados de tal manera que
indican que hay más fragmentos. Al igual que antes sus offset son 0 y 1480 (ejemplo de 2000 bytes),
pero como ya se intuía el último fragmento tiene los flags a 0 y offset a 2960 (mismo procedimiento
que la fragmentación anterior).

5
Funcionamiento del comando ping
Para este apartado nos introduciremos en el estudio del protocolo ICMP de Internet Control
Message Protocol. Este se utiliza para el intercambio de información de control entre dispositivos
terminales y routers, o por el contrario entre router y router. Destacar que ICMP es parte de IP.

Para comenzar este subapartado, empezaremos por la captura de paquetes resultantes del
comando ping (explicado anteriormente). Vamos a ejecutar el comando ping -c 10 10.209.3.1, donde
10 representa la cantidad de paquetes ICMP echo request que se estarán enviando. Cuando
aplicamos el filtro que se nos indica en la captura, podemos observar la aparición de 20 paquetes en
total, de estos 20, 10 corresponden a las solicitudes que hemos emitido y los restantes 10 a las
respuestas de cada solicitud. Para verificar la información de los paquetes lo que vamos a analizar es
que dentro del apartado de IP se indica el protocolo 0x01 (ICMP). Donde los paquetes se clasifican
en dos partes/tipos, el tipo 8 y el tipo 0 que corresponden a los códigos echo request y echo reply. Si
seguimos analizando nos encontramos que la dirección de salida de peticiones es 192.168.1.95
correspondiente a nuestro dispositivo mientras que la dirección de destino es 10.209.3.1. Dentro de
dichos paquetes de solicitud nos encontramos que el código es 0 y el tipo 8 correspondiente a
“request”. Dentro de la cabecera otros campos relevantes que se hacen destacar son, el checksum,
el identificador y el número de secuencia, cada uno ocupando 2 bytes en la cabecera, mientras que
el tipo y el código solamente ocupan 1 byte. En cambio dentro de los paquetes de respuesta, el
código sigue siendo 0, aunque su tipo cambia de 8 a 0 (reply). Los demás campos permanecen
iguales al paquete de solicitud correspondiente, con la excepción del checksum, al que se le agrega
el tiempo que ha tardado en la respuesta.

Estudio de los mensajes ICMP asociados al comando traceroute

Para este estudio lanzaremos el comando traceroute www.etsii.ull.es para conocer el
camino que sigue un paquete desde el origen hasta el destino. En este caso, la ip del nodo de origen
es 192.168.1.95 y la del nodo destino 193.145.119.72 .

El campo TTL resulta de gran importancia ya que ayuda a evitar que los paquetes que se
hayan enviado a través de rutas que no existen o direcciones erróneas viajen indefinidamente por la
red. Consiguiendo así ayudar o prevenir a la congestión de red ya que elimina la acumulación de
paquetes que no pueden ser entregados correctamente. Traceroute es una herramienta de
diagnóstico (identifica la ruta tomada por los paquetes desde un dispositivo hasta otro a través de
una red), donde los mensajes de respuesta incluyen los tiempos de respuesta.
Los paquetes de ICMP devueltos desde el nodo final difieren de los paquetes enviados en el
mensaje de destino inalcanzable o “destination unreachable”. Esto quiere decir que han llegado al
puerto de destino y se intenta devolver un mensaje UDP. Como dato curioso podemos destacar que
el mensaje de “destination unreachable” puede ser generado por cualquier dispositivo de red que se
encuentre en la ruta hacia la dirección de destino.

6
PROTOCOLOS DE LA CAPA TRANSPORTE

UDP

El protocolo UDP es ampliamente utilizado en la capa de transporte de la red y tiene

funciones muy específicas. Su objetivo principal es la multiplexación y demultiplexación de procesos,
además de la detección de errores en la transferencia de datos. La capa de red se encarga de enviar
la información de un dispositivo a otro por la mejor ruta posible, mientras que UDP identifica los
procesos en ejecución y los procesos que necesitan los datos. La cabecera del protocolo UDP es
simple, ya que solo cuenta con cuatro elementos: los puertos de origen y destino, el checksum y la
longitud de la carga útil.

Para analizar el intercambio de paquetes mediante el protocolo UDP al realizar una captura
con WIreshark y ejecutar el comando dig www.amazon.com, examinaremos detalladamente los
campos que se incluyen en la cabecera. Los cuatro campos de la cabecera ocupan un total de 8
bytes, ya que cada campo se almacena en 2 bytes. El campo de longitud indica el tamaño del
datagrama, incluyendo los 8 bytes de la cabecera. En el caso del paquete que estamos analizando,
el campo length indica que el datagrama tiene un tamaño de 1358 bytes, de los cuales 1350 son de
carga útil. El tamaño máximo del datagrama de UDP es de 65535 bytes, de los cuales hay que restar
los 8 bytes de la cabecera, lo que nos da un tamaño máximo de carga útil de 65527 bytes. Lo mismo
se aplica para el número máximo de puerto, que es 65535.

En la cabecera IP, el número de protocolo UDP es 17 (11 en hexadecimal). El valor del

campo checksum se obtiene del complemento a 1 de la suma de los 16 bits de una pseudo cabecera
(puerto de origen y destino y la longitud) y los datos reales de UDP.

7
TCP
Para este fragmento del informe, investigaremos sobre el funcionamiento del protocolo TCP.
TCP es un protocolo de nivel de transporte que se enfoca en la conexión con control de flujo. Es un
poco más complejo que UDP, ya que también se encarga del control de flujo y de realizar entregas.
Para la cabecera del TCP, esta comparte algunos campos con la cabecera del UDP, como los
puertos de origen y destino y el checksum, pero también incluye otros campos, como el número de
confirmación (ACK) para la entrega segura de paquetes.

Para el entendimiento de su funcionamiento mientras realizamos una captura en Wireshark,

ejecutaremos el comando "wget" para descargar una imagen ISO de Debian GNU/Linux, y vamos a
detener la descarga cuando esta alcance el 1%. En cuanto al segmento TCP SYN enviado al
servidor, el número de secuencia de su cabecera es 0. Wireshark muestra el número de secuencia
relativo al primer segmento de transmisión, y además también muestra el número bruto.

Se propuso un algoritmo para la selección de números de secuencia inicial (ISN) de TCP,

debido a que las conexiones TCP habían sufrido severos ataques, consiguiendo así que las
posibilidades de que un atacante pudiera adivinar los números de secuencia válidos se minimizaran.
La expresión del algoritmo es: ISN = M + F (ip de origen, puerto de origen, ip de destino, puerto de
destino, clave secreta). En esta expresión, M es un temporizador de 4 microsegundos y F es una
función pseudoaleatoria (PRF). La clave secreta es un número aleatorio de 128 bits que cambia
según:
● El sistema se está ejecutando.
● Expira algún tiempo predefinido.
● La clave se ha utilizado varias veces.

En cuanto a la cabecera del segmento SYN enviado, el segundo flag está activo (0x002), lo
que indica que es una petición SYN. Para la respuesta del servidor ACK-SYN, el número de
secuencia es 0 y un número bruto. En este caso, también se ha activado otro flag de
Acknowledgment (0x012). En el último mensaje del inicio de conexión (el ACK del cliente), se
desactiva el flag SYN (0x010) y se empieza a enviar información en la carga útil.

Los segmentos SYN y (SYN-ACK) poseen varias opciones, entre ellas, el tamaño máximo
del segmento que se usará durante la conexión (Maximum Segment Size) y la ampliación del tamaño
de los paquetes para hacer más eficiente su envío (Window Scaling). También se encuentra la opción
SACK, que se encarga de solicitar que solo se manden los datos que faltan en caso de que se pierda
parte de los datos enviados. La opción Timestamps, que determina los tiempos de entrega ida y
vuelta para que TCP espere antes de transmitir un segmento que no ha sido reconocido. Por último,
se encuentra la opción No Operation (NOP) para separar las diferentes opciones utilizadas dentro del
campo Opción TCP.

8
PROTOCOLOS CAPA DE APLICACIÓN

DNS

DNS es un protocolo que permite traducir el espacio de nombres de dominio a direcciones IP.
Esto es de gran utilidad, ya que, el protocolo IP utiliza direcciones IP para identificar a los hosts y
debido a que a los seres humanos nos resulta más sencillo recordar nombres de dominio que
direcciones IP, es de gran utilidad una herramienta que pueda traducir de nombres de dominio a
dichas direcciones.

Para poder investigar el uso de este protocolo vamos a hacer uso del comando “dig”. Dig es
una herramienta para “preguntar” a servidores DNS. Realiza peticiones y muestra las respuestas que
se retornan al servidor de nombres que se consultan (domain information groper).

Vamos a utilizar como dominio de prueba www.ulpgc.es. El puerto de destino de la petición

se trata del puerto número 53, que es un puerto bien conocido del protocolo DNS, es el puerto
estándar que se utiliza para las consultas y respuestas de DNS. El nombre canónico corresponde a
cluster-web.ulpg.es y la dirección IP correspondiente es 193.145.138.32. El archivo /etc/resolv.conf lo
utilizan los programas en el sistema para saber que servidores de DNS utilizar para resolver la
traducción de nombres de dominio a direcciones IP mediante el propio protocolo.

Para el comando “dig ulpgc.es NS”, el puerto de destino es el mismo que para el anterior
ejemplo es decir el puerto 53, puerto estándar que se utiliza para consultas y respuestas. La
dirección 199.184.182.1 . el archivo etc/resolv.conf funciona de la misma manera que el ejemplo
anterior.

Para el último ejemplo tenemos “dig @dns1.ull.es ww.ull.es” . Este realiza una única
petición de DNS al servidor de DNS especificado(dns1.ull.es) para obtener información de dominio
www.ull.es, esto se debe a que solo se está consultando solo un registro de recursos (RR) específico
(www.ull.es).

9
HTTP
A lo largo de este último apartado en lo referente a protocolos, estudiaremos el protocolo
HTTP que puede ser el más conocido y utilizado en la transferencia de información a través de
archivos en la World Wide Web. Dicho protocolo está situado en la capa de aplicación y se encarga
de la transferencia de información a través de la red. HTTP significa Hypertext Transfer Protocol.

Estudio de la interacción HTTP GET/respuesta básica

Al realizar una llamada (get) a un servidor, podremos observar su respuesta, antes de que se
realize la petición get realiza una petición DNS para poder asociar el nombre del dominio con su
dirección IP correspondiente, como ya hemos analizado en otros apartados. En la petición, el
servidor nos muestra información que nos es relevante como la versión del protocolo HTTP (1.1) o
los lenguajes que se aceptan (inglés o español). Se entiende que la petición es realizada desde
nuestro dispositivo debido a que se nos muestra nuestra propia dirección IP (192.168.1.95). La
respuesta se retorna en la misma versión de HTTP, con un datagrama de 128 bytes, esta incluye el
estado 200 (OK-solicitud exitosa). Estos códigos de estados se pueden dividir en: 1-- (respuestas
informativas),2-- (respuestas satisfactorias), 3-- (redirecciones), 4-- (errores de cliente) y 5-- (errores
de servidores).

HTTP GET condicional

Para este subapartado en el estudio de este protocolo, vamos ha realizar una petición GET
condicional. Realizaremos una petición del tipo Get al servidor y refrescaremos (F5) la página para
realizar exactamente la misma petición. Se borrará la caché antes de empezar a capturar con la
herramienta Wireshark.

El proceso de la primera petición y su respuesta ya lo analizamos en el apartado anterior. En

cambio la segunda petición (cuando refrescamos con F5) incluye un nuevo campo
“IF-MODIFIED-SINCE”, este indica la fecha de la primera conexión. Si se ha modificado el contenido
del fichero que hemos solicitado a partir de dicha fecha se mandará una nueva respuesta con el
fichero modificado. En nuestro ejemplo el código del protocolo es 304 - “No modificado”, por lo tanto
no se ha modificado el fichero desde la fecha de conexión.

En resumen, hasta este punto del estudio del protocolo HTTP podemos destacar que es
fundamental para la transferencia de información en la red. La realización de peticiones GET básica y
condicional nos permite comprender su funcionamiento y las diferentes respuestas que se pueden
obtener.

Protocolos binarios y textuales

Los datos binarios antes del HTTP GET corresponden a protocolos de la capa de transporte;
TCP o UDP (explicado su funcionamiento anteriormente en este informe). Estos protocolos binarios
son ilegibles por el ser humano, ya que están codificados en binario y no en ASCII, como sucede con
los protocolos textuales. La codificación en binario permite una transmisión más eficiente de los
datos, pero hace que la información sea difícil de entender sin herramientas especiales de
decodificación.

1
0
CONCLUSIÓN
A lo largo de todo este trabajo hemos estado aprendiendo las funcionalidades del programa
Wireshark. Hemos hecho un recorrido por diferentes protocolos de red, investigando su
funcionamiento y analizandolos mediante el uso de diversos comandos.

Hemos podido aprender que Wireshark es un programa de análisis de protocolos de

red/herramienta esencial para administradores de redes. Este posee la capacidad para analizar y
capturar el tráfico de red en tiempo real. Wireshark permite detectar problemas de red, identificar
cuellos de botella, optimizar el rendimiento de la red y solucionar problemas de seguridad.

Wireshark puede además ayudar a los administradores de red a solucionar ciertos problemas
dentro de la red, identificar amenazas de seguridad, optimizar la red y comprender su tráfico entre
otras.

Sin embargo, debido a su potente capacidad de captura de paquetes, Wireshark también

puede ser utilizado con fines maliciosos. Personas con fines maliciosos podrían utilizar la herramienta
para capturar/observar información confidencial, como contraseñas, correos electrónicos y datos
personales, lo que hace que sea importante utilizar Wireshark con precaución. Un ejemplo personal
de este caso es; durante la realización de este informe, en concreto en el apartado del protocolo UDP
me encontraba en una biblioteca universitaria, conectado a la red universitaria de dicho centro de
estudios. Al iniciar la captura realmente entendí la potencia de esta herramienta y la capacidad de
escucha que tiene sobre la red. Los administradores de red y expertos en seguridad informática
deben asegurarse de proteger su red contra posibles amenazas y utilizar Wireshark solo en
situaciones muy concretas. También existe la posibilidad que personas con fines éticos utilicen
Wireshark de manera totalmente opuesta, es decir hacer uso de sus características para encontrar
fallas en la red, pudiendo así prevenir dichos ataques.

En conclusión, Wireshark es una herramienta valiosa para el análisis de protocolos de red,

como para nosotros, para investigar sobre el funcionamiento de los protocolos, pero también puede
ser una herramienta peligrosa en manos equivocadas. Por lo tanto, es importante que se use
Wireshark de manera responsable, implementando medidas de seguridad para evitar posibles
amenazas y proteger la información relevante.

1
1
BIBLIOGRAFÍA
PROTOCOLO ETHERNET:
-https://ccnadesdecero.es/protocolo-ethernet-caracteristicas/
-https://www.ionos.es/digitalguide/servidores/know-how/ethernet-ieee-8023/

PROTOCOLO ARP:
-https://www.redeszone.net/tutoriales/internet/que-es-protocolo-arp/
-https://www.ionos.es/digitalguide/servidores/know-how/arp-resolucion-de-direcciones-en-la-
red/

PROTOCOLO IP:
-https://neo.lcc.uma.es/evirtual/cdd/tutorial/red/ip.html
-https://www.pedrocarrasco.org/fragmentacion-ip/
-https://netwgeeks.com/fragmentacion-ipv4/

PROTOCOLO ICMP:
-https://www.ionos.es/digitalguide/servidores/know-how/que-es-el-protocolo-icmp-y-como-fu
nciona/
-https://neo.lcc.uma.es/evirtual/cdd/tutorial/red/icmp.html

PROTOCOLO UDP:
-https://www.ionos.es/digitalguide/servidores/know-how/udp-user-datagram-protocol/
-https://es.khanacademy.org/computing/ap-computer-science-principles/the-internet/x2d2f70
3b37b450a3:transporting-packets/a/user-datagram-protocol-udp

PROTOCOLO TCP:
-https://ayudaleyprotecciondatos.es/2021/07/29/protocolo-tcp/
-https://www.dsi.uclm.es/personal/miguelfgraciani/mikicurri/docencia/LenguajesInternet0910/
web_LI/Teoria/Protocolos%20de%20bajo%20nivel/Protocolo%20TCP.htm

PROTOCOLO DNS:
-https://www.cartagena99.com/recursos/alumnos/apuntes/211028153856-enunciadoP2.pdf
-https://www.redeszone.net/tutoriales/internet/que-es-protocolo-dns/

PROTOCOLO HTTP:
-https://es.semrush.com/blog/que-es-https/?kw=&cmp=ES_SRCH_DSA_Blog_ES&label=ds
a_pagefeed&Network=g&Device=c&utm_content=641166107997&kwid=dsa-193044264521
9&cmpid=19249322774&agpid=145537342218&BU=Core&extid=64577950247&adpos=&gc
lid=Cj0KCQjw8e-gBhD0ARIsAJiDsaXSrhnXP57CCi-Afa_IaxAvcRzaTGGLYPz0cAhoN2wAF
pVUTHbAdu0aAlIOEALw_wcB
-https://developer.mozilla.org/es/docs/Web/HTTP/Overview

1
2