UFW y Fail2Ban en producción
Cuando un servidor expone servicios críticos a Internet, no basta con “cruzar los dedos”. Necesitas una capa mínima de defensa que filtre tráfico, bloquee intentos sospechosos y reduzca el ruido constante de bots y escáneres automáticos. En este artículo te muestro cómo combino UFW y Fail2Ban en producción para mantener a raya a los visitantes no deseados.
📡 Arquitectura de protección
La idea es sencilla: UFW actúa como portero de la puerta principal, y Fail2Ban como el vigilante que observa el comportamiento de los invitados. Si alguien insiste demasiado, queda fuera.
+------------------------------------------------------+ | CAPA DE SEGURIDAD | +------------------------------------------------------+ | UFW (Firewall) | Fail2Ban (Detección ataques) | | ----------------- | ---------------------------- | | - Filtrado puertos | - Bloqueo IPs maliciosas | | - Reglas por servicio | - Protección SSH/HTTP | +------------------------------------------------------+
🧱 Configuración de UFW
UFW es perfecto para servidores donde no necesitas reglas complejas. Su filosofía es clara: bloquear todo lo que no hayas permitido explícitamente. Así reduces superficie de ataque desde el primer minuto.
$ ufw default deny incoming $ ufw default allow outgoing $ ufw allow 22/tcp $ ufw allow 443/tcp $ ufw enable
Una vez activado, comprueba que las reglas están aplicadas correctamente:
daniel@server:~$ sudo ufw status verbose
Si ves tus puertos abiertos y el resto bloqueado, ya tienes la primera capa de defensa lista.
🚫 Configuración de Fail2Ban
Fail2Ban analiza los logs del sistema en busca de comportamientos sospechosos. Si detecta demasiados intentos fallidos, banea la IP automáticamente. Es especialmente útil para SSH, donde los ataques de fuerza bruta son constantes.
# /etc/fail2ban/jail.d/sshd.conf [sshd] enabled = true port = 22 filter = sshd logpath = /var/log/auth.log maxretry = 5 bantime = 3600
Comprueba que la jail está activa:
daniel@server:~$ sudo fail2ban-client status sshd
Si aparece la lista de IPs baneadas, significa que Fail2Ban ya está haciendo su trabajo. Spoiler: siempre hay alguien intentando entrar.
📋 Logs y detección de ataques
Para ver Fail2Ban en acción en tiempo real, puedes monitorizar su log. Es bastante revelador ver cuántos intentos fallidos ocurren incluso en servidores recién desplegados.
daniel@server:~$ sudo tail -f /var/log/fail2ban.log 2026-01-12 14:22:11 [sshd] Ban 185.23.91.10 2026-01-12 14:22:45 [sshd] Ban 201.55.33.8
Si ves líneas como estas, no te alarmes: es completamente normal. Lo raro sería no ver ninguna.
⚙️ Retos y soluciones
🔸 Reto: Falsos positivos en Fail2Ban
A veces un usuario legítimo puede equivocarse varias veces con la contraseña. Si Fail2Ban
lo banea, puede ser un problema. La solución pasa por ajustar maxretry y revisar
los filtros para evitar bloqueos innecesarios.
🔸 Reto: Servicios expuestos innecesariamente
Es habitual dejar puertos abiertos “por si acaso”. UFW te obliga a pensar qué servicios necesitas realmente. Cierra todo lo que no uses y tu servidor será mucho más difícil de atacar.
⏱️ Timeline del artículo
[2026-01-12] Configuración inicial de UFW [2026-01-13] Integración de Fail2Ban [2026-01-14] Pruebas de ataques simulados [2026-01-15] Ajustes finales y documentación
Con UFW y Fail2Ban trabajando juntos, tu servidor gana una capa de protección esencial. No es una solución definitiva, pero sí un punto de partida sólido para cualquier entorno en producción.