TP 5 – Laboratorio: SSH, HTTP y Firewall
Elementos de corrección para este laboratorio están disponibles en el repositorio de ejercicios: 👉 módulo-17 – Correcciones
Este laboratorio utiliza hasta 3 tarjetas de red por VM. Para una explicación detallada de los tipos de tarjetas (NAT, Internal Network, Host-Only, Bridged) y su equivalente en VMware, consulte: 👉 Módulo 15 - Bonus: Tarjetas de red VirtualBox vs VMware
Trabajo en equipo de dos personas
| Nombre | |
|---|---|
| Estudiante 1 | ........................ |
| Estudiante 2 | ........................ |
Objetivos
Este laboratorio tiene como objetivo aplicar los conocimientos adquiridos sobre los protocolos y servicios estudiados hasta ahora (SSH, HTTP, Firewall) en un entorno Linux.
Entorno requerido
Hipervisor
- VirtualBox (o VMware Workstation / VMware Player)
Máquinas virtuales a crear
| Máquina | Sistema operativo | RAM | Disco | CPU | Interfaces de red |
|---|---|---|---|---|---|
| srvGateway | Ubuntu Server 24.04 LTS (o 22.04 LTS) | 1 GB mínimo | 20 GB | 1 vCPU | 3 interfaces: NAT + Red interna lan + Red interna clientnet |
| srvSSH | Ubuntu Server 24.04 LTS (o 22.04 LTS) | 1 GB mínimo | 20 GB | 1 vCPU | 1 interfaz: Red interna lan |
| srvWEB | Ubuntu Server 24.04 LTS (o 22.04 LTS) | 1 GB mínimo | 20 GB | 1 vCPU | 1 interfaz: Red interna lan |
| Client | Ubuntu Server 24.04 LTS (o 22.04 LTS) | 1 GB mínimo | 20 GB | 1 vCPU | 1 interfaz: Red interna clientnet |
- srvGateway necesita 3 tarjetas de red:
- Adaptador 1: NAT (acceso a Internet)
- Adaptador 2: Internal Network →
lan(red LAN10.11.12.0/24) - Adaptador 3: Internal Network →
clientnet(red Cliente20.21.22.0/30)
- srvSSH y srvWEB: Internal Network →
lan - Client: Internal Network →
clientnet
Software requerido en las VMs
| Máquina | Software a instalar |
|---|---|
| srvGateway | iptables, net-tools |
| srvSSH | openssh-server |
| srvWEB | apache2, openssl, certbot (opcional) |
| Client | openssh-client, curl, wget |
El enrutamiento IP (ip_forward) debe estar activado en srvGateway para que el tráfico circule entre las redes.
Las demás máquinas (srvSSH, srvWEB, Client) deben tener srvGateway como puerta de enlace predeterminada.
Topología de red
Descripción de las máquinas
| Máquina | Rol | Interfaz(es) |
|---|---|---|
| srvGateway | Enrutamiento y puerta de enlace a Internet | Interfaz 1: NAT (Internet) |
Interfaz 2: 10.11.12.1/24 (LAN) | ||
Interfaz 3: 20.21.22.1/30 (Cliente) | ||
| srvWEB | Servidor web Apache | 10.11.12.150/24 |
| srvSSH | Servidor SSH | 10.11.12.100/24 |
| Client | Máquina cliente | 20.21.22.2/30 |
Conectividad esperada
srvGatewaytiene acceso a Internet- El cliente,
srvWEBysrvSSHpueden acceder a Internet a través desrvGateway - El tráfico SSH, HTTP y HTTPS está autorizado en
srvGateway
El incumplimiento de la topología o la entrega de capturas de pantalla que no correspondan a las instrucciones resultará en una penalización de puntos.
Parte 1 – Configuración del enrutamiento y del compartimiento de conexión (40 puntos)
1.1 – Configurar las direcciones IP estáticas
Configure las direcciones IP estáticas en cada una de las cuatro máquinas según la topología.
Realice una captura de las interfaces para cada una de las máquinas.
1.2 – Activar el enrutamiento permanente en srvGateway
Active el enrutamiento (IP forwarding) de manera permanente en srvGateway.
Inserte la captura de pantalla de la activación del enrutamiento permanente.
1.3 – Configurar el compartimiento de conexión a Internet en srvGateway
Agregue reglas iptables para:
a) Autorizar el tráfico saliente desde la LAN, reenviado por srvGateway
Captura requerida.
b) Autorizar solo el tráfico SSH, HTTP, HTTPS e ICMP para las demás máquinas
Captura requerida.
c) Activar el MASQUERADE
Captura requerida.
d) Probar la conexión a Internet
Pruebe la conexión a Internet desde el cliente, srvSSH y srvWEB.
Captura requerida.
Parte 2 – Configuración de los servicios (40 puntos)
2.1 – Configurar un servidor web Apache en srvWEB
a) Crear dos hosts virtuales
Cree dos hosts virtuales en srvWEB:
| Host virtual | Nombre de dominio |
|---|---|
| Sitio 1 | www.test.local |
| Sitio 2 | www.labo.local |
Captura requerida.
b) Páginas HTML con los nombres de los estudiantes
Inserte páginas HTML con los nombres de los estudiantes del equipo.
Captura requerida.
c) Archivos de configuración y páginas web
Inserte las capturas de pantalla de los archivos de configuración y de las páginas web mostradas.
2.2 – Configurar un acceso seguro en HTTPS
a) Instalar certificados SSL
Instale certificados SSL para ambos hosts virtuales.
Hosts virtuales afectados:
- www.test.local → certificado autofirmado
- www.labo.local → certificado autofirmado
Captura requerida: certificados y páginas HTTPS.
2.3 – Restringir el acceso a srvWEB desde el cliente
a) Bloquear el acceso desde 20.21.22.2
Modifique la configuración para bloquear la dirección 20.21.22.2.
Captura requerida.
b) Probar con curl
Pruebe con curl e inserte la captura de pantalla del acceso denegado.
Parte 3 – Configuración de un acceso remoto (20 puntos)
3.1 – Configurar un servidor SSH en srvSSH
a) Crear el usuario bob
Cree un usuario bob con /home/bob y /bin/bash.
Capturas requeridas:
- Salida de
ss -tan - Salida de
tail /etc/passwd
3.2 – Configurar una redirección SSH local (túnel)
Utilice un túnel SSH para que el cliente pueda acceder a www.labo.local a través de srvSSH.
Principio del túnel SSH:
Capturas requeridas:
- Comando de túnel SSH
- Acceso exitoso a
www.labo.localdesde el cliente vía el túnel
Resumen de la topología y de los flujos
Tabla de evaluación
| Parte | Criterios | Puntos |
|---|---|---|
| Parte 1 | Configuración del enrutamiento y compartimiento de conexión | 40 |
| Configuración de direcciones IP estáticas + capturas | 10 | |
| Activación del enrutamiento permanente | 5 | |
| Reglas iptables (SSH, HTTP, HTTPS, ICMP) | 10 | |
| MASQUERADE | 5 | |
| Pruebas de conexión a Internet (cliente, srvSSH, srvWEB) | 10 | |
| Parte 2 | Configuración de los servicios | 40 |
| Hosts virtuales Apache (www.test.local, www.labo.local) | 10 | |
| Páginas HTML con nombres de los estudiantes | 5 | |
| Archivos de configuración + páginas mostradas | 5 | |
| Certificados SSL y HTTPS | 10 | |
| Restricción de acceso (bloqueo 20.21.22.2) | 5 | |
| Prueba curl + captura de acceso denegado | 5 | |
| Parte 3 | Configuración de un acceso remoto | 20 |
| Usuario bob + capturas (ss -tan, /etc/passwd) | 10 | |
| Túnel SSH + acceso a www.labo.local | 10 | |
| Total | 100 |
TP creado el: Febrero 2025
MÓDULO BONUS – Comprender el handshake TLS (divulgativo)
El objetivo aquí es explicar, con palabras muy sencillas, lo que sucede cuando usted escribe una dirección en HTTPS.
Una versión “módulo bonus” (fuera de este laboratorio) está disponible aquí: Módulo 15 – Bonus: Handshake TLS (divulgativo).
1) Antes de TLS: el “handshake” TCP (SYN / SYN‑ACK / ACK)
Antes de hablar de cifrado (TLS), hay que establecer primero la conexión de red. Para HTTPS, generalmente es TCP en el puerto 443.
TCP utiliza un apretón de manos en 3 mensajes:
- SYN: «Hola, quiero hablar contigo, ¿estás ahí?»
- SYN‑ACK: «Sí, estoy aquí, y he recibido tu SYN. ¿Me escuchas?»
- ACK: «Sí, te escucho, he recibido tu mensaje. Podemos empezar.»
ACK = Acuse de recibo (solo significa: «he recibido»).
👉 Importante: este handshake TCP no cifra nada. Solo sirve para decir: «la conexión está lista».
2) Después: el handshake TLS (para asegurar la conversación)
Una vez establecido TCP, se inicia TLS (lo que convierte HTTP → HTTPS).
Piense en TLS como: ponerse de acuerdo sobre un candado, verificar la identidad del servidor, y luego hablar en un idioma secreto.
Esta es la idea general (sin entrar en detalles criptográficos):
- ClientHello (cliente → servidor):
- «Hola, sé usar TLS, estas son las versiones y algoritmos que soporto.»
- ServerHello (servidor → cliente):
- «OK, elegimos tal versión de TLS y tales algoritmos.»
- El servidor también envía su certificado (su “tarjeta de identidad”).
- Verificación del certificado (lado cliente):
- El cliente verifica que el certificado sea válido, que corresponda al nombre del sitio, y que esté firmado por una autoridad conocida (o aceptado manualmente si es autofirmado).
- Creación de un secreto compartido:
- Cliente y servidor establecen claves para cifrar (a menudo mediante un intercambio de claves tipo Diffie‑Hellman).
- A partir de ahí, pueden generar claves de sesión.
- Finished (ambos lados):
- Se envían un último mensaje para confirmar: «tenemos las mismas claves, estamos listos».
✅ Después de esto, todo lo que sigue está cifrado: URLs completas, contenidos, contraseñas, cookies, etc.
3) Pequeño resumen “en una frase”
- TCP (SYN/SYN‑ACK/ACK): abrimos la puerta (conexión)
- TLS (ClientHello… Finished): ponemos un candado y verificamos la identidad (seguridad)
- HTTP/HTTPS: es lo que decimos una vez abierta la puerta y puesto el candado
- En HTTP, verá el contenido (a menudo legible).
- En HTTPS, verá principalmente el handshake TLS y luego paquetes cifrados (contenido ilegible).