Cuando Fail2Ban se come el CPU de tu servidor

El otro día tenía un servidor que a un horario se atascaba, todos los núcleos del procesador al mango, 100% clavado durante una o dos horas. Okey, es un server con unas bases de datos enormes de unos sitios en Wordpress con cien mil notas cada uno, pero ¿Tanto?

Pues bien, noté que, en realidad, no era MySQL el proceso loco... era Fail2Ban! Para aquellos que no saben qué es, es un programa que banea números de IP desde donde uno recibe ataques. Así que sacarlo no era opción pero ¿Qué cuernos sucedía?

El servidor utiliza Ubuntu, básicamente Debian con retoques más amigables, pero además monté todo con VestaCP. Aquí tienen un howto para instalar VestaCP y armar su propio hosting en un VPS como Digital Ocean.

El problema parece ser que de tantos ataques el Auth.log empieza a crecer, pero a Gigas y gigas, y Fail2Ban lo recorre todo para encontrar y enumerar esos IPs y sus intentos de ataque.

Son ataques al FTP, al SSH, a todo puerto, recurrentes, automatizados, así que debe chequear múltiples intentos y ahí los agrega a una base de datos propia hecha con SQLite.

Pero de tan grande que estaba el Auth.log la cosa se ponía densa, para armar su base de IPs tardaba horas.

LogRotate

Bueno, por defecto el log se renueva cada un tiempo muy largo, hay que cambiar esto por una actualización diaria así que tenemos que editar el archivo donde se indican todas estas actualizaciones de logs.

El LogRotate básicamente comprime lo viejo, te deja un backup y empieza el archivo de nuevo, así nunca será una cosa enorme de semanas de logs.

sudo nano /etc/logrotate.d/rsyslog

Ahí dentro encontrarán que estan listados todos los logs, hay que separar el de auth.log y más abajo podemos armar lo siguiente:

/var/log/auth.log
{
rotate 4
daily
missingok
notifempty
size 10M
su root syslog
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}


Ahora ya le avisamos que a partir de ahora en vez de ser semanal por default será diario, lo demás es lo usual. Ahora bien, esto aplica para el siguiente ciclo así que todavía no terminó el problema inmediato del CPU consumiendo recursos.

Resolviendo el problema inmediato

Primero detenemos el servicio que está afectando todo

sudo service fail2ban stop

Luego le borramos la base de datos SQLite, se que suena drástico pero Fail2Ban la va a crear de nuevo, lola, perdemos los datos de spammers por un rato, nada grave.

sudo rm /var/lib/fail2ban/fail2ban.sqlite3

Ahora la magia, forzamos el LogRotate para que vacíe el Auth.log, hermosa cochineada:

sudo logrotate --force rsyslog

y ahora podemos activar de nuevo Fail2Ban

sudo service fail2ban start

Y listo! resuelto el problema y, para la próxima, Fail2Ban no se va a encontrar con un archivo tan enorme para analizar.

Obviamente en servidores con mejores recursos no haría falta todo esto, pero los VPS son baratos porque, justamente, tienen CPUs igual de económicos, lo mejor es ir limitando consumos ridículos de recursos.

Adicionalmente pueden poner todos los sitios detrás de una cuenta gratuita de Cloudflare para que contenga ataques de todo tipo sin consumo excesivo (sí, también hice eso por las dudas).

La solución la encontré perfectamente explicada aquí

Si te gustó esta nota podés...
Invitame un café en cafecito.app


Otros posts que podrían llegar a gustarte...

Comentarios

  • Gustavo V     20/04/2021 - 11:28:13

    hermoso nardopost.

    gracias por compartir

  • John Doe     20/04/2021 - 18:54:16

    Otra opción es usar sshguard.

  • Marcelo     21/04/2021 - 01:34:16

    Nsda de esto seria necesario si activaran el security flag en el header IPV, definiendo el tipo de ataque y su severidad.

    ht_tps://tools.ietf.org/html/rfc3514

Deje su comentario:

Tranquilo, su email nunca será revelado.
La gente de bien tiene URL, no se olvide del http/https

Negrita Cursiva Imagen Enlace


Comentarios ofensivos o que no hagan al enriquecimiento del post serán borrados/editados por el administrador. Los comentarios son filtrados por ReCaptcha V3.