Laboratorio 5.5.2. Túneles seguros con SSH Port Forwarding¶

Encapsulación de paquetes: observar sin túnel vs. con túnel (Wireshark)¶

Objetivo: Ver de forma práctica qué significa encapsular tráfico y cómo cambia lo que se observa en la red cuando usamos un túnel cifrado. Compararemos:

1) HTTP directo (sin túnel): el contenido viaja en claro y puede leerse.

2) HTTP a través de túnel SSH (port forwarding): el contenido va encapsulado/cifrado dentro de SSH y ya no es visible.

Aviso legal y normas¶

Actividad exclusiva para el laboratorio (VirtualBox/aula).
Realiza capturas únicamente de tu red de prácticas.
No realices esta práctica en redes de terceros sin autorización.

Uso exclusivo en laboratorio

Esta práctica está diseñada para un entorno controlado. No debes aplicarla fuera del aula o del laboratorio sin permiso explícito.

Material necesario¶

Infraestructura¶

Actividad solo para el laboratorio (VirtualBox/aula).
Capturas únicamente de tu red de prácticas.
No realices esta práctica en redes de terceros sin autorización.

Elemento	Detalle
Hipervisor	VirtualBox
Red virtual	Internal Network (`labnet`)
Máquina 1	`SRV` con Ubuntu 24.04 LTS
Máquina 2	`CLI` con Ubuntu 24.04 LTS
Acceso	Usuario con permisos de `sudo`
Software de análisis	Wireshark

Software mínimo¶

Equipo	Paquetes
`SRV`	`apache2`, `openssh-server`
`CLI`	`curl`, `wireshark`, `openssh-client`

1. Requisitos¶

Máquinas virtuales¶

VM	Sistema	Rol
`SRV`	Ubuntu 24.04 LTS	Servidor web HTTP + servidor SSH
`CLI`	Ubuntu 24.04 LTS	Cliente + Wireshark

Red¶

Ambas VMs deben estar en la misma Internal Network (por ejemplo, labnet).
Deben tener conectividad IP entre sí.

Software mínimo¶

apache2, openssh-server en SRV.
curl, wireshark, openssh-client en CLI.

Recomendación

Antes de empezar, verifica que ambas máquinas tienen la fecha y hora correctas y que puedes resolver o identificar sus direcciones IP sin errores.

2. Preparación del servidor (SRV)¶

En SRV, instala Apache y SSH:

sudo apt update
sudo apt install -y apache2 openssh-server
sudo systemctl enable --now apache2
sudo systemctl enable --now ssh

Crea un recurso HTTP con contenido sensible para demostrar el problema:

echo "usuario=admin&password=1234" | sudo tee /var/www/html/login.txt

Comprueba que el servidor responde localmente:

curl http://localhost/login.txt

Evidencia 1: captura de la salida de curl.

Anota la IP del servidor:

ip -br a

Note

En Ubuntu 24.04 LTS, el servicio SSH suele gestionarse como ssh, aunque el paquete instalado sea openssh-server.

3. Preparación del cliente (CLI)¶

En CLI, instala herramientas:

sudo apt update
sudo apt install -y curl wireshark openssh-client

Si Wireshark solicita permisos durante la instalación, acepta la opción adecuada para permitir capturas a usuarios no privilegiados. Después, añade tu usuario al grupo wireshark:

sudo usermod -aG wireshark $USER
newgrp wireshark

Anota la IP del cliente:

ip -br a

Comprueba conectividad con el servidor:

ping -c 2 <IP_SRV>

Evidencia 2: captura de ping.

4. Parte A — Sin túnel (HTTP directo)¶

Paso A1. Generar tráfico HTTP¶

En CLI, ejecuta:

curl http://<IP_SRV>/login.txt

Evidencia 3: captura del contenido devuelto.

Paso A2. Capturar con Wireshark¶

Abre Wireshark en CLI.
Captura en la interfaz de red conectada a labnet.
Aplica el filtro:

http

Vuelve a ejecutar el curl.

Qué debes observar

En esta parte, Wireshark debe mostrar claramente la petición HTTP y la respuesta del servidor porque no existe ningún cifrado intermedio.

Paso A3. Leer el contenido expuesto¶

En un paquete HTTP, clic derecho -> Follow -> TCP Stream.

Resultado esperado: debe aparecer el texto usuario=admin&password=1234 en claro.

Evidencia 4: captura de pantalla de Follow TCP Stream mostrando el contenido en texto claro.

5. Explicación técnica (encapsulación)¶

5.1. Sin túnel (lo que viaja)¶

El paquete transporta el contenido HTTP directamente:

IP: CLI (origen) -> SRV (destino)
TCP: puerto_aleatorio -> 80
HTTP: GET /login.txt
HTTP response: usuario=admin&password=1234

En redes locales (o Wi‑Fi públicas), cualquier atacante que capture el tráfico puede leer esa respuesta.

5.2. Con túnel (encapsulación)¶

Con túnel, el HTTP sigue existiendo, pero queda dentro de otro flujo cifrado:

Paquete exterior (visible):
IP: CLI (origen) -> SRV (destino)
TCP: puerto_aleatorio -> 22 (SSH)
Datos: CIFRADOS

Dentro (no visible):
IP/TCP/HTTP del tráfico original hacia el puerto 80

Esto es encapsulación: el paquete original se envuelve dentro de otro y se cifra.

6. Parte B — Con túnel (SSH Local Port Forwarding)¶

Paso B1. Configurar acceso SSH (recomendado: clave pública)¶

En CLI:

ssh-keygen -t ed25519 -C "encapsulacion-lab"
ssh-copy-id <usuario>@<IP_SRV>

Prueba acceso:

ssh -o PreferredAuthentications=publickey <usuario>@<IP_SRV>

Sal con exit.

Evidencia 5: captura de la conexión SSH exitosa.

Paso B2. Crear el túnel¶

En CLI, crea el túnel:

ssh -L 8080:localhost:80 <usuario>@<IP_SRV> -N -f

Verifica que el puerto 8080 está escuchando:

ss -tlnp | grep ':8080'

Evidencia 6: captura mostrando 8080 asociado a ssh.

Paso B3. Acceder al recurso HTTP a través del túnel¶

En CLI:

curl http://localhost:8080/login.txt

Evidencia 7: captura de la salida (el contenido sigue llegando, pero viaja por túnel).

7. Captura con Wireshark (con túnel activo)¶

Paso C1. Qué capturar¶

En Wireshark (en CLI), aplica el filtro:

tcp.port == 22

Vuelve a ejecutar:

curl http://localhost:8080/login.txt

Paso C2. Interpretación¶

Verás tráfico SSH.
Si intentas Follow TCP Stream, verás datos binarios/cifrados.
No debería aparecer el texto usuario=admin&password=1234.

Conclusión esperada

El contenido sigue llegando a curl, pero viaja protegido dentro del túnel SSH. Wireshark solo puede mostrar el contenedor cifrado, no el contenido HTTP original.

Evidencia 8: captura de Follow TCP Stream (SSH) mostrando que no se puede leer el contenido.

8. Cierre del túnel¶

En CLI:

ps aux | grep "ssh -L 8080"
kill <PID>

Comprueba que ya no escucha:

ss -tlnp | grep ':8080'

Evidencia 9: captura confirmando que el túnel se ha cerrado.

9. Preguntas (obligatorias)¶

En la Parte A, ¿qué información concreta has podido leer en claro en Wireshark?
En la Parte B/C, ¿por qué ya no se ve el contenido HTTP en claro, aunque el navegador/curl siga recibiendo la respuesta?
Explica con tus palabras qué significa encapsular un paquete.
¿Esto es una VPN completa? ¿En qué se parece y en qué se diferencia (VPN vs. túnel SSH)?

10. Entrega¶

Un PDF con:

Datos del alumno.
IPs de CLI y SRV.
Capturas de la Evidencia 1 a la Evidencia 9 (comentadas).
Respuestas a las 4 preguntas.

11. Criterios de evaluación¶

Criterio	Descripción	Puntos
Preparación	Servicios y conectividad correctos	2
Parte A	Captura HTTP en claro + Follow TCP Stream	3
Parte B	Túnel creado y verificado con `ss`	2
Parte C	Captura SSH cifrada + demostración de no lectura	2
Informe	Claridad y respuestas justificadas	1

Total: 10 puntos

Material de apoyo (MkDocs)¶

Resumen rápido¶

=== “Sin túnel”

CLI --- HTTP ---> SRV
Contenido visible en Wireshark

=== “Con túnel SSH”

CLI --- SSH cifrado ---> SRV
Dentro del túnel viaja HTTP
Contenido no visible en Wireshark

Filtros útiles de Wireshark¶

http
tcp.port == 80
tcp.port == 22
ip.addr == <IP_SRV>

Comprobaciones rápidas¶

# Ver servicios en SRV
systemctl status apache2 ssh --no-pager

# Ver puertos escuchando
ss -tlnp

# Probar cabeceras HTTP
curl -I http://<IP_SRV>/login.txt

# Probar el recurso por el túnel
curl -I http://localhost:8080/login.txt

Problemas habituales¶

Problema	Posible causa	Comprobación
No responde `ping`	IP incorrecta o red virtual distinta	Revisar `ip -br a` en ambas máquinas
No conecta por SSH	Servicio parado o credenciales incorrectas	`systemctl status ssh` en `SRV`
No abre `localhost:8080`	Túnel no levantado	`ss -tlnp \| grep ':8080'`
Wireshark no captura	Falta de permisos	Revisar grupo `wireshark`