UFW & Fail2ban (Protección de Red y Bloqueo de Ataques)

1. Visión general del concepto y problema sistémico

Un servidor Linux accesible públicamente en Internet está sujeto a un escaneo automatizado continuo por parte de botnets. Los escáneres buscan puertos abiertos, contraseñas débiles de SSH, puertos abiertos de bases de datos (PostgreSQL, Redis, MySQL) y paneles de administración desprotegidos. Sin un firewall de red sistemático, el servidor se vuelve vulnerable a ataques de denegación de servicio (DoS), agotamiento de límites de descriptores de socket abiertos y acceso no autorizado directo.

UFW (Uncomplicated Firewall) y Fail2ban forman un sistema de protección activa de dos niveles:

• UFW (Nivel Estático): Interfaz simplificada para la configuración del subsistema iptables / nftables del núcleo de Linux bajo el principio Default-Deny: todas las conexiones entrantes están bloqueadas, excepto los puertos explícitamente permitidos (SSH, HTTP/HTTPS).
• Fail2ban (Nivel Dinámico): Demonio de análisis de comportamiento que monitorea los registros del sistema y modifica dinámicamente las reglas del firewall, aislando las direcciones de los bots que muestran patrones de ataques de fuerza bruta o sondeos de vulnerabilidades.

+-------------------------------------------------------------------+
| Tráfico de Entrada (Internet)                                      |
+---------------------------------+---------------------------------+
                                  |
                                  v
                   +-----------------------------+
                   |       Demonio Fail2ban      |
                   | (Análisis de registros journald/auth) |
                   +--------------+--------------+
                                  | DROP Dinámico (por ejemplo, 24 horas)
                                  v
                   +-----------------------------+
                   |        UFW / Netfilter      |
                   |  (iptables / nftables del núcleo) |
                   +--------------+--------------+
                                  |
              +-------------------+-------------------+
              | Permitido (22, 80, 443)                | Bloqueado (DROP)
              v                                       v
    +-------------------+                   +-------------------+
    | Servicios del Sistema |                   | Paquete Destruido  |
    | (Nginx, SSHd)     |                   | sin respuesta      |
    +-------------------+                   +-------------------+

2. Taxonomía arquitectónica y modelo mental

La protección del nodo se basa en una clara distribución de responsabilidades entre los componentes:

1. Filtro de Red del Núcleo (Netfilter / nftables):
   • Motor de bajo nivel en el núcleo de Linux que verifica los encabezados de cada paquete de red en las interfaces de red.
2. UFW (Uncomplicated Firewall):
   • Utilidad de gestión simple de las cadenas de filtrado INPUT, OUTPUT, FORWARD.
   • Proporciona una sintaxis comprensible para humanos en lugar de las complejas construcciones sintácticas de iptables.
   • Establece una política estática: bloqueo de rangos de puertos no autorizados.
3. Fail2ban (Marco de Prevención de Infiltraciones):
   • Jail (Aislamiento): Entidad de configuración que vincula el filtro (filter.d), el registro de logs y la acción de bloqueo (action.d).
   • Filter: Conjunto de expresiones regulares (failregex) para el análisis de errores de autenticación.
   • Action: Instrucción (por ejemplo, iptables-multiport) que añade temporalmente una IP a la cadena de rechazo de paquetes.

3. Pipeline técnico y mecánica interna

Despliegue básico y configuración de UFW

[!IMPORTANTE] Siempre permite el puerto SSH antes de activar el firewall para evitar bloquear tu propia sesión:

# 1. Restablecimiento y políticas por defecto (denegar todo entrante, permitir saliente)
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. Permitir puertos críticos
sudo ufw allow 22/tcp comment "OpenSSH"
sudo ufw allow 80/tcp comment "HTTP (Let's Encrypt)"
sudo ufw allow 443/tcp comment "HTTPS"

# 3. Activar el firewall
sudo ufw --force enable
sudo ufw status verbose

Configuración de Fail2ban (/etc/fail2ban/jail.local)

Nunca edites jail.conf directamente (se sobrescribe con actualizaciones de paquetes); crea un archivo de sobrescritura:

[DEFAULT]
# Lista de IPs de confianza (lista blanca que nunca se bloquea)
ignoreip = 127.0.0.1/8 ::1 198.51.100.12

# Tiempo de bloqueo (1 día) y ventana de observación (10 minutos)
bantime  = 24h
findtime = 10m
maxretry = 5

# Uso del backend systemd para distribuciones modernas (Ubuntu 22.04/24.04, Debian 12)
backend = systemd
banaction = ufw

[sshd]
enabled = true
port    = 22
mode    = aggressive

[nginx-http-auth]
enabled = true
port    = http,https
logpath = /var/log/nginx/error.log

Gestión del demonio:

sudo systemctl enable --now fail2ban
# Verificación del estado del aislamiento SSH
sudo fail2ban-client status sshd

4. Escenarios prácticos de ingeniería en producción

01. Protección contra escaneo de vulnerabilidades dirigido en Nginx / servidor web

Los atacantes ejecutan escáneres (nikto, sqlmap) que generan cientos de solicitudes a /wp-login.php, /.env, /phpmyadmin. Se crea un filtro personalizado /etc/fail2ban/filter.d/nginx-botsearch.conf que rastrea en los registros los códigos de estado 404 y 403 para tales rutas. Después de 3 intentos, la IP se bloquea durante 7 días a nivel del firewall, preservando el CPU de la instancia.

02. Limitación de acceso a métricas internas de Prometheus y servicios de bases de datos

El servidor de monitoreo o la base de datos PostgreSQL debe escuchar en la interfaz externa para replicación o scraping de métricas. En lugar de abrir puertos públicamente, se configura una restricción por direcciones IP específicas de nodos asociados:

sudo ufw allow from 10.0.0.15 to any port 9090 proto tcp comment "Prometheus scraper"
sudo ufw allow from 10.0.0.20 to any port 5432 proto tcp comment "Postgres Replica"

Todas las demás solicitudes a estos puertos son rechazadas sin enviar TCP RST (modo sigiloso).

03. Desbloqueo de emergencia a través de fail2ban-client

Un desarrollador cometió un error al conectarse con una clave incorrecta y su IP doméstica fue bloqueada. El administrador se conecta a través de un nodo Jump y desbloquea sin reiniciar todo el servicio:

sudo fail2ban-client set sshd unbanip 203.0.113.45

5. Errores comunes, trampas y seguridad

1. Docker elude UFW a través de iptables: Cuando Docker inicia un contenedor con el parámetro -p 8080:8080, crea reglas en la cadena PREROUTING, que tienen prioridad sobre las reglas de UFW. El puerto se abre para todo el mundo, incluso si ufw status muestra una prohibición. Corrige esto vinculando puertos exclusivamente al loopback (-p 127.0.0.1:8080:8080) o desactivando la gestión de iptables en /etc/docker/daemon.json ({"iptables": false}).
2. Desbordamiento de registros sin logrotate: Si Fail2ban analiza registros de servidor web de gigabytes sin rotación, el demonio comenzará a consumir el 100% de CPU del núcleo, intentando leer el archivo desde el principio. Asegúrate de que logrotate comprima correctamente los archivos de registro.
3. Bloqueo de propios proxies (Cloudflare / Reverse Proxy): Si el servidor web está detrás de Cloudflare o AWS ALB, Fail2ban en configuración estándar bloqueará las direcciones IP de Cloudflare en lugar de los clientes reales. Configura el módulo mod_remoteip en Nginx/Apache para restaurar X-Forwarded-For antes de activar los jails HTTP.