🔒 Protegiendo mi Servidor con Fail2Ban – Seguridad Preventiva antes del Lanzamiento - Episodio 21

como-instalar-fail2ban-servidor

Poner mi API en producción sin protección era un riesgo.

Y eso supongo que ya te lo imaginabas  pero claro...

No quería esperar a que los ataques llegaran para reaccionar.

Por eso, configuré Fail2Ban como medida preventiva y en este post te cuento cómo lo he hecho yo...

Por si te sirve para asegurar tu servidor antes de que sea tarde. 🚀🔒

Índice
  1. 🚀 Mi servidor estaba en producción, pero era un blanco fácil...📅 Diario de un SaaS.
  2. 🔍 Problema: ¿Por qué proteger SSH y Nginx antes de recibir ataques?
  3. 🤔 ¿Qué es Fail2Ban y por qué es importante?
    1. 🔹 ¿Cómo funciona Fail2Ban?
  4. 🛠️ Instalación y Configuración de Fail2Ban
    1. ✅ 1. Instalación de Fail2Ban en el servidor
    2. ✅ 2. Configuración de Fail2Ban para SSH
    3. ✅ 3. Protegiendo Nginx de accesos sospechosos
  5. 🔄 Monitoreo y Verificación
  6. ❌ Ajustes finos: Excepciones y optimización
    1. 🔹 Excluir direcciones IP seguras (listas blancas)
    2. 🔹 Revisar logs regularmente
  7. 💡 Aprendizajes del proceso
    1. 🔹 La seguridad debe ser proactiva, no reactiva
    2. 🔹 SSH es un punto de ataque común y debe protegerse
    3. 🔹 Nginx también es vulnerable y necesita protección
    4. 🔹 La seguridad es ajuste constante
  8. 🚀 Próximos Pasos

🚀 Mi servidor estaba en producción, pero era un blanco fácil...📅 Diario de un SaaS.

Cuando puse mi API en producción, sabía que el siguiente paso era asegurar el servidor.

No porque hubiera visto intentos de ataque en los logs, sino porque no quería esperar a que llegaran para reaccionar.

SSH abierto, Nginx recibiendo tráfico sin restricciones y sin un sistema para detectar intentos sospechosos…

O sea todo un coladero.

Y eso no podía dejarlo  al azar.

Fail2Ban era la solución perfecta para reforzar la seguridad desde el primer día. 🔐


🔍 Problema: ¿Por qué proteger SSH y Nginx antes de recibir ataques?

Desde el momento en que tu servidor tiene una IP pública, es accesible para cualquiera en internet.

Eso significa que, tarde o temprano, alguien intentará probar credenciales aleatorias o buscar vulnerabilidades en la API.

Por eso, antes de que eso pasara, decidí configurar Fail2Ban como una medida preventiva:

Proteger SSH de intentos de acceso no autorizados.

Evitar ataques automatizados contra Nginx.

Tener registros de actividad sospechosa para poder reaccionar rápido.

Si todo salía bien, mi servidor bloquearía automáticamente direcciones IP maliciosas antes de que pudieran causar problemas.

🤔 ¿Qué es Fail2Ban y por qué es importante?

Fail2Ban es como un portero de discoteca para tu servidor.

Es decir, imagina que tienes un club exclusivo y alguien intenta entrar con una identificación falsa cinco veces seguidas.

El portero se da cuenta y lo expulsa, prohibiéndole la entrada durante un tiempo.

Eso es exactamente lo que hace Fail2Ban, pero con ataques en SSH, Nginx y otros servicios críticos.

🔹 ¿Cómo funciona Fail2Ban?

1️⃣ Escanea los registros del sistema (logs) en busca de intentos sospechosos.
2️⃣ Si detecta demasiados intentos fallidos en poco tiempo, bloquea la IP del atacante.
3️⃣ Evita ataques de fuerza bruta, impidiendo que bots automatizados intenten acceder con diferentes combinaciones de contraseñas.
4️⃣ Funciona con múltiples servicios, protegiendo no solo SSH, sino también Nginx, Apache, y más.

En resumen, Fail2Ban es una barrera automática contra accesos sospechosos.

Así que si alguien insiste en probar credenciales sin éxito, su IP queda bloqueada antes de que logre entrar. 🚀


🛠️ Instalación y Configuración de Fail2Ban

Fail2Ban actúa como un sistema de defensa automatizado. Si detecta intentos de acceso fallidos o patrones sospechosos en los logs, bloquea la IP automáticamente. Vamos con la instalación y configuración.

✅ 1. Instalación de Fail2Ban en el servidor

sudo apt update && sudo apt install fail2ban -y

Una vez instalado, Fail2Ban ya estaba activo, pero con su configuración por defecto.

Vamos a ajustarlo a nuestras necesidades.

✅ 2. Configuración de Fail2Ban para SSH

El acceso SSH es un punto crítico en cualquier servidor.

Así que si alguien logra entrar con credenciales incorrectas, podría tomar el control total.

Por eso, para evitarlo, edité la configuración:

sudo nano /etc/fail2ban/jail.local

Añadí estas reglas para proteger SSH:

[sshd]
enabled = true
bantime = 3600  # Bloquear IPs por 1 hora
maxretry = 5  # Si fallan 5 veces en 10 minutos, se bloquea la IP
findtime = 600

Reinicié Fail2Ban para aplicar los cambios:

sudo systemctl restart fail2ban

Ahora, cualquier IP que fallara 5 veces en 10 minutos quedaría bloqueada automáticamente.


✅ 3. Protegiendo Nginx de accesos sospechosos

No todos los ataques vienen por SSH.

Es más, algunos intentan explotar vulnerabilidades en la API a través de Nginx.

Pues, para prevenirlo, activé Fail2Ban en Nginx:

[nginx-http-auth]
enabled = true
bantime = 600  # Bloqueo de 10 minutos
maxretry = 10  # Si fallan 10 intentos de autenticación en Nginx, se bloquea la IP

Reinicié Fail2Ban:

sudo systemctl restart fail2ban

Con esto, Fail2Ban también bloquea intentos sospechosos de autenticación en la API. 🚀

configurar-fail2ban-vps


🔄 Monitoreo y Verificación

Quería asegurarme de que Fail2Ban realmente estaba funcionando, así que probé estos comandos:

🔹 Ver el estado de protección en SSH:

sudo fail2ban-client status sshd

🔹 Ver intentos bloqueados en los logs:

sudo journalctl -u fail2ban --no-pager | tail -n 20

🔹 Si alguna IP se bloquea por error, desbloquear manualmente:

sudo fail2ban-client set sshd unbanip 192.168.1.100

Ahora, Fail2Ban estaba trabajando en segundo plano para prevenir problemas antes de que ocurrieran. 💪


❌ Ajustes finos: Excepciones y optimización

🔹 Excluir direcciones IP seguras (listas blancas)

Para evitar bloqueos accidentales de mi equipo, agregué nuestras IPs a la lista blanca en /etc/fail2ban/jail.local:

ignoreip = 192.168.1.100 192.168.1.101

Esto evita que Fail2Ban bloquee accidentalmente direcciones de confianza.

🔹 Revisar logs regularmente

Fail2Ban es automático, pero no significa que podamos olvidarnos de él.

Por lo que revisar los logs me permite saber qué tipo de intentos están ocurriendo y ajustar las reglas si es necesario.


💡 Aprendizajes del proceso

🔹 La seguridad debe ser proactiva, no reactiva

Esperar a que un ataque ocurra para reaccionar es un error.

Así que configurar Fail2Ban desde el inicio evita que los atacantes siquiera tengan oportunidad.

🔹 SSH es un punto de ataque común y debe protegerse

Abrir un servidor sin seguridad en SSH es dejar la puerta abierta a los atacantes.

Por eso, Fail2Ban es una barrera imprescindible.

🔹 Nginx también es vulnerable y necesita protección

No basta con asegurar SSH.

Ya que las APIs pueden ser atacadas a nivel HTTP, por lo que activar Fail2Ban en Nginx es un paso fundamental.

🔹 La seguridad es ajuste constante

No basta con instalar y olvidar.

Ya sabes, hay que revisar logs regularmente, ajustar listas blancas y verificar que los bloqueos son efectivos.


🚀 Próximos Pasos

Con Fail2Ban protegiendo mi servidor, el siguiente paso es implementar monitoreo avanzado con Prometheus y Grafana para visualizar en tiempo real intentos de acceso y tráfico sospechoso. 📊🔥

➡️ ¿Usas Fail2Ban en tu servidor?

¿Tienes alguna configuración extra para mejorar la seguridad?

Cuéntamelo en los comentarios.

 

Si quieres conocer otros artículos parecidos a 🔒 Protegiendo mi Servidor con Fail2Ban – Seguridad Preventiva antes del Lanzamiento - Episodio 21 puedes visitar la categoría Proyecto-IA.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Subir