Práctica 2: Captura y Análisis de Protocolos con Wireshark

1. ENUNCIADO #

En este laboratorio práctico vas a utilizar Wireshark (el analizador de protocolos de red estándar de la industria) para interceptar el tráfico real de tu interfaz de red, inspeccionar las cabeceras de los protocolos estudiados y entender cómo viajan los datos en cada capa del modelo OSI/TCP-IP.

Vas a capturar y analizar:

1. Resolución de direcciones con ARP (Capa 2/3).
2. Consultas y respuestas DNS (Capa 7 sobre UDP).
3. El 3-Way Handshake de TCP (Capa 4).
4. Diferencias entre tráfico en texto plano (HTTP) y cifrado (HTTPS / TLS).

2. OBJETIVOS #

• Aprender a capturar tráfico en la interfaz de red adecuada.
• Dominar el uso de filtros de visualización (Display Filters).
• Inspeccionar tramas Ethernet, paquetes IP y segmentos TCP/UDP.
• Comprender la secuencia SYN $\rightarrow$ SYN-ACK $\rightarrow$ ACK.
• Verificar el principio de confidencialidad analizando la carga útil (payload) de HTTP vs TLS.

3. PARTE 1 - PREPARACIÓN Y CAPTURA #

1. Descarga e instala Wireshark (disponible para Linux, Windows y macOS desde wireshark.org o mediante sudo apt install wireshark).
2. Abre Wireshark y selecciona tu interfaz activa (Wi-Fi o Ethernet / eth0 / en0).
3. Haz doble clic sobre la interfaz para iniciar la captura en tiempo real.

4. PARTE 2 - ANÁLISIS DE TRÁFICO ARP #

1. En la barra de filtros de visualización de Wireshark escribe:

   arp

2. Abre tu terminal y haz un ping a la IP de tu router (por ejemplo ping 192.168.1.1).
3. Si la dirección MAC del router ya está en la caché de vecinos, el ping puede no generar ARP. Espera a que caduque la entrada o usa otra máquina IPv4 accesible del mismo enlace cuya MAC no esté en caché. ARP se utiliza en IPv4; IPv6 utiliza NDP. Cuando se resuelva la dirección, observa:
   • ARP Request (Broadcast): "Who has 192.168.1.1? Tell 192.168.1.X" (Dirección MAC destino: ff:ff:ff:ff:ff:ff).
   • ARP Reply (Unicast): "192.168.1.1 is at [MAC_del_Router]".

5. PARTE 3 - ANÁLISIS DE CONSULTAS DNS #

1. Cambia el filtro de visualización a:

   dns

2. En la terminal ejecuta una consulta DNS:

   1dig example.com A

   (O nslookup example.com en Windows).
3. Localiza en Wireshark:
   • Standard query: petición al puerto UDP 53 preguntando por el registro A de example.com.
   • Standard query response: respuesta con la dirección IP devuelta en tu captura; puede variar.

Esta prueba busca DNS clásico sobre UDP/53. Si el resolvedor es local, puede ser necesario capturar también en la interfaz de loopback. Un navegador puede usar DNS cifrado (DoH/DoT), cuyo contenido no aparecerá en claro con el filtro dns.

6. PARTE 4 - EL 3-WAY HANDSHAKE DE TCP #

1. Aplica el filtro:

   tcp.port == 80 || tcp.port == 443

2. Ejecuta estas peticiones en procesos nuevos de curl. Forzamos HTTP/1.1 para estudiar conexiones TCP sin que el navegador reutilice una conexión o negocie HTTP/3:

   1curl --http1.1 http://neverssl.com/
   2curl --http1.1 https://example.com/

   La primera petición genera un GET HTTP sin cifrar y la segunda un GET protegido con TLS. Si tu entorno utiliza un proxy, la captura puede mostrar la conexión al proxy en lugar de al servidor final.
3. Detén la captura (botón rojo cuadrado).
4. Localiza los 3 primeros paquetes entre tu IP y la IP del servidor web:
   1. [SYN]: Observa el campo Flags: 0x002 (SYN) y el número de secuencia relativo Sequence Number: 0.
   2. [SYN, ACK]: Observa Flags: 0x012 (SYN, ACK) y Acknowledgment Number: 1.
   3. [ACK]: Observa Flags: 0x010 (ACK) completando el apretón de manos.

7. PARTE 5 - HTTP VS HTTPS (TEXTO CLARO VS CIFRADO) #

1. Inspección HTTP (Texto plano):

   • Filtra por http.
   • Haz clic derecho sobre una petición GET $\rightarrow$ Follow $\rightarrow$ TCP Stream.
   • Observa cómo puedes leer claramente la URL, cabeceras (User-Agent, Host) y datos del formulario o HTML.

2. Inspección HTTPS (TLS):

   • Filtra por tls.
   • Localiza Client Hello y Server Hello, donde se negocian parámetros criptográficos. En TLS 1.3 los mensajes posteriores a Server Hello, incluido el certificado del servidor, están cifrados.
   • El contenido de la aplicación no se puede leer con una captura pasiva sin los secretos de sesión. Wireshark puede descifrarlo si se le proporcionan secretos exportados por un cliente compatible en un laboratorio controlado.

3. Comparación opcional con HTTP/3 (QUIC sobre UDP):

   • Reinicia la captura y usa el filtro quic || udp.port == 443.
   • Comprueba con curl -V si tu compilación incluye la característica HTTP3. Si la incluye, prueba curl --http3-only https://cloudflare-quic.com/.
   • HTTP/3 necesita soporte del cliente, del servidor y conectividad UDP. Si la prueba falla o tu cliente no lo soporta, conserva la captura TCP anterior; un fallo no demuestra que HTTP/3 siempre esté bloqueado.
   • QUIC integra TLS 1.3 y no realiza el handshake TCP SYN → SYN-ACK → ACK. El filtro TCP de la parte anterior no muestra este tráfico.

Referencias: HTTP/3 (RFC 9114), opciones de curl y TLS en Wireshark.

8. EJERCICIO DE ENTREGA #

Responde a las siguientes preguntas a partir de tu captura:

1. ¿Cuál es la dirección MAC de origen y destino en el paquete ARP Request capturado?
2. ¿Qué número de puerto efímero asignó tu sistema operativo como puerto de origen durante el 3-way handshake de TCP?
3. En la consulta DNS, ¿qué campo de la cabecera indica que se trata de una respuesta (Response) y no de una petición (Query)?
4. ¿Por qué el filtro tcp.port == 443 no permite observar una conexión HTTP/3? Si hiciste la prueba opcional, explica qué tráfico capturaste.