Sur mon petit serveur dédié, j’ai reçu une notification d’alerte de Load Average élevé venant de ma supervision. Une fois connecté via SSH, j’ai exécuté la commande HTOP pour repérer le ou les processus coupables. Ce qui a été très rapide à trouver: Fail2Ban.

Pourquoi Fail2Ban

Mon premier réflexe a été de pensé que je subissais une attaque, mais après examen rien d’anormal dans les logs. Sauf que, certains fichiers de logs étaient anormalement gros, en particulier les logs d’accès au blog.

Une chose à savoir avec Fail2Ban, il utilise toute la puissance disponible à la présence de gros fichiers log.

Logrotate

Si les fichiers de log deviennent anormalement gros, il se peut que le réglage de la rotation des logs soit mal paramétré (en dehors d’une attaque évidemment).
J’ai revue ma configuration de logrotate, et en particulier celui de nginx.

nano /etc/logrotate.d/nginx 

##le chemin ou se trouve les logs de ngnix :
/var/log/nginx/*.log {
##Copie du fichier de log et vide ce dernier pour le remplir :
copytruncate
##rotation jounalière :
daily
##Je garde un historique de 7 fichiers de log :
rotate 7
##Je compresse les fichiers de log :
compress
##je limite la taille du fichier de log à 10Mo :
size 10M
##si le log n’existe pas, ne créé pas d’erreur :
missingok
##si le journal est vide, il n'y aura aucune action :
notifempty
##Permet l’exécution de postrotate :
sharedscripts
##Action après la rotation des logs (action qui était par défaut)  :
postrotate
                /bin/kill -USR1 `cat /var/run/nginx.pid 2>/dev/null` 2>/dev/null || true
endscript
}

Relance de logrotate :

logrotate -f  /etc/logrotate.conf

Vérification du Load Average

Pour finir, j’exécute la commande HTOP pour vérifier le bon fonctionnement de Fail2Ban :