Práctica 7 — Seguridad y Cortafuegos

Antes de empezar

Esta práctica parte de un servidor en estado inseguro. El profesor habrá ejecutado el script de setup en tu VM. Si lo haces por tu cuenta, el Paso 0 lo explica.

---

Paso 0 — Estado inicial (servidor inseguro)

El servidor empieza así (el profesor lo establece):

# (Para el profesor)
sudo apt install -y nginx ufw fail2ban
sudo ufw disable
sudo systemctl stop fail2ban
sudo sed -i 's/^PasswordAuthentication.*/PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
sudo systemctl reload sshd

Verifica en qué estado está el servidor ahora mismo:

# ¿El firewall está activo?
sudo ufw status
# Esperado: Status: inactive

# ¿fail2ban está corriendo?
systemctl is-active fail2ban
# Esperado: inactive

# ¿Se permite el login de root por SSH?
grep "PermitRootLogin" /etc/ssh/sshd_config
# Esperado: PermitRootLogin yes  (inseguro)

# ¿Se acepta autenticación por contraseña?
grep "PasswordAuthentication" /etc/ssh/sshd_config
# Esperado: PasswordAuthentication yes  (inseguro)

Tu objetivo: pasar de este estado inseguro a un servidor correctamente protegido.

---

Ejercicio 7.1 — Configurar el firewall con UFW

Contexto

UFW (Uncomplicated Firewall) es la interfaz simplificada de iptables en Ubuntu. Por defecto, un servidor nuevo no tiene firewall activo — cualquier puerto expuesto es accesible desde internet.

⚠ Lee esto antes de activar UFW

Si activas UFW sin permitir SSH primero (puerto 22), perderás la conexión SSH y necesitarás acceder desde la consola de VirtualBox. Sigue el orden de los pasos exactamente.

Tarea 1 — Política por defecto: denegar todo

# Deniega todo el tráfico entrante por defecto
sudo ufw default deny incoming

# Permite todo el tráfico saliente (para que el servidor pueda hacer peticiones)
sudo ufw default allow outgoing

Tarea 2 — Permitir los puertos necesarios ANTES de activar

# PRIMERO: permite SSH (si lo pierdes, queda sin conexión)
sudo ufw allow ssh
# O de forma equivalente:
sudo ufw allow 22/tcp

# Permite HTTP (para que el servidor web funcione)
sudo ufw allow 80/tcp

# Permite HTTPS
sudo ufw allow 443/tcp

Tarea 3 — Activar UFW

sudo ufw enable
# Escribe 'y' cuando pregunte si continuar

¿Sigue funcionando SSH?

Después de activar UFW, intenta abrir una nueva terminal y conectarte por SSH. Si funciona, perfecto. Si no, revisa que permitiste el puerto 22 en el paso anterior.

# Verifica el estado completo del firewall
sudo ufw status verbose

Debes ver:

Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Tarea 4 — Probar que UFW bloquea puertos no permitidos

# Lista los puertos en escucha en el servidor
sudo ss -tlnp

# Intenta conectar a un puerto no permitido (por ejemplo, el 8080)
# Desde tu ordenador (fuera de la VM):
nc -zv 192.168.56.X 8080
# Debe dar timeout o "Connection refused"

---

Ejercicio 7.2 — Proteger SSH con fail2ban

Contexto

fail2ban monitoriza los logs del sistema y bloquea automáticamente las IPs que realizan demasiados intentos fallidos de autenticación. Es la defensa estándar contra ataques de fuerza bruta.

Tarea 1 — Instalar y activar fail2ban

sudo apt install -y fail2ban

# Inicia el servicio
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

# Verifica que está corriendo
systemctl status fail2ban

Tarea 2 — Configurar la jail de SSH

fail2ban usa “jails” (celdas) para definir qué monitorizan y qué IP bloquear. La configuración principal está en /etc/fail2ban/jail.conf pero no debes editarla directamente — se sobreescribe al actualizar. Usa un archivo local:

sudo nano /etc/fail2ban/jail.local

Escribe:

[DEFAULT]
# tiempo de baneo en segundos (1 hora = 3600)
bantime  = 3600
# ventana de tiempo para contar intentos (10 minutos)
findtime = 600
# número de intentos fallidos antes de banear
maxretry = 3

[sshd]
enabled = true
port    = ssh
logpath = /var/log/auth.log

Aplica la configuración:

sudo systemctl restart fail2ban

# Verifica el estado de la jail SSH
sudo fail2ban-client status sshd

Debe mostrar que la jail sshd está activa con 0 IPs baneadas (a menos que alguien ya haya intentado entrar).

Tarea 3 — Simular un ataque para ver fail2ban en acción

Desde un terminal diferente en tu ordenador (no en la VM):

# Intenta conectarte con una contraseña incorrecta 4 veces seguidas
# (cambia la IP a la de tu VM)
ssh -o ConnectTimeout=5 usuario_falso@192.168.56.X
# Escribe cualquier contraseña incorrecta y repite hasta que deje de responder

Después comprueba en la VM:

# ¿Hay IPs baneadas?
sudo fail2ban-client status sshd

# ¿Aparece el baneo en el log?
sudo tail -20 /var/log/auth.log | grep "Ban\|Failed"

Desbanea tu IP si te baneaste accidentalmente:

sudo fail2ban-client set sshd unbanip TU_IP

---

Ejercicio 7.3 — Hardening de SSH

Tarea 1 — Desactivar el login de root por SSH

sudo nano /etc/ssh/sshd_config

Busca estas líneas y asegúrate de que tienen estos valores:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Antes de desactivar contraseñas

Asegúrate de que tu usuario tiene las claves SSH configuradas (de la práctica 3). Si desactivas contraseñas sin tener claves, quedas sin acceso SSH.

# Aplica los cambios
sudo systemctl reload sshd

# Prueba que root no puede conectarse:
# (desde tu terminal fuera de la VM)
ssh root@192.168.56.X
# Debe decir: Permission denied, please try again

---

Ejercicio 7.4 — Auditoría con Lynis

Tarea 1 — Instalar y ejecutar Lynis

sudo apt install -y lynis

# La auditoría completa tarda unos minutos
sudo lynis audit system

Lynis puntúa la seguridad del servidor. Busca la línea:

Hardening index : XX [############            ]

Tarea 2 — Revisar las sugerencias

# Las advertencias de lynis (las más importantes)
sudo grep "warning\|suggestion" /var/log/lynis.log | head -20

Lynis clasifica los hallazgos en:

• WARNING (amarillo) → problema de seguridad importante, corrígelo
• SUGGESTION (azul) → mejora recomendable pero no crítica

Implementa al menos 2 correcciones de las que sugiera lynis. Dos sugerencias habituales:

# 1. Restringir permisos de /etc/crontab (suele sugerirlo)
sudo chmod 600 /etc/crontab

# 2. Configurar umask más restrictivo
# Lynis suele pedir umask 027 en lugar del 022 por defecto
# Añade al final de /etc/profile:
echo "umask 027" | sudo tee -a /etc/profile

---

📤 Bloque de entrega

echo "=== ENTREGA PRÁCTICA 7 ===" && \
echo "" && \
echo "--- Firewall UFW ---" && \
sudo ufw status verbose && \
echo "" && \
echo "--- fail2ban SSH ---" && \
sudo fail2ban-client status sshd && \
echo "" && \
echo "--- Config SSH ---" && \
grep "PermitRootLogin\|PasswordAuthentication\|PubkeyAuthentication" /etc/ssh/sshd_config && \
echo "" && \
echo "--- Lynis (hardening index) ---" && \
sudo lynis show version && \
sudo grep "Hardening index" /var/log/lynis.log | tail -1