Fail2ban pour protéger SSH et Nginx : configuration pratique sur Ubuntu

Le problème : attaques par force brute

#

Après avoir exposé mon serveur Ubuntu à internet, j’ai passé une nuit à examiner les logs. SSH recevait des tentatives de connexion échouées chaque seconde. Nginx aussi avait des requêtes suspectes vers des chemins courants. J’avais besoin de quelque chose pour bloquer ces tentatives automatiquement. Fail2ban a été ma solution.

Installation

#

sudo apt update
sudo apt install fail2ban
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Vérifier qu’il est en cours d’exécution :

sudo systemctl status fail2ban

Structure de Fail2ban

#

Fail2ban fonctionne ainsi : il surveille les logs, détecte les modèles d’échec et crée des règles de firewall pour bloquer les IPs. Il a trois composants clés :

• Jails : définissent quel service protéger
• Filters : modèles regex pour détecter les tentatives échouées
• Actions : que faire quand une attaque est détectée (blocage, email, etc)

Configuration de SSH

#

Le jail SSH est préconfiguré, mais je l’ai personnalisé. Créer le fichier /etc/fail2ban/jail.local :

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

Explication :

• bantime : secondes durant lesquelles dure le blocage (1 heure)
• findtime : fenêtre en secondes pour compter les tentatives (10 min)
• maxretry : tentatives échouées avant blocage (3 pour SSH, plus restrictif)

Configuration de Nginx

#

Pour Nginx, j’ai dû créer un jail personnalisé. D’abord, le filtre dans /etc/fail2ban/filter.d/nginx-http-auth.conf :

sudo nano /etc/fail2ban/filter.d/nginx-http-auth.conf

[Definition]
failregex = ^<HOST> - \S+ \[\S+ \S+\] ".*?" (401|403) .*$
ignoreregex =

Ensuite, ajouter le jail au fichier local :

[nginx-http-auth]
enabled = true
port = http,https
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
findtime = 600
bantime = 3600

Appliquer les modifications

#

sudo systemctl restart fail2ban

Vérifier que les jails sont actifs :

sudo fail2ban-client status

Voir le statut détaillé de SSH :

sudo fail2ban-client status sshd

Surveillance

#

Après quelques heures, j’ai vérifié l’activité :

sudo fail2ban-client status sshd

La sortie affiche les IPs bloquées. Pour voir les détails du jail :

sudo tail -f /var/log/fail2ban.log

Débloquer une IP (au cas où)

#

Si je me suis trompé et que j’ai bloqué ma propre IP :

sudo fail2ban-client set sshd unbanip <IP>

Notes importantes

#

• Fail2ban ne remplace pas les clés SSH. J’ai continué à utiliser l’authentification par clé, pas par mot de passe.
• J’ai augmenté maxretry pour SSH à 3 parce que c’est plus restrictif que 5 pour les applications web.
• Les logs de Nginx doivent être au format combiné. Vérifier /etc/nginx/nginx.conf.
• Pour les modifications de filtres, redémarrer : sudo systemctl restart fail2ban.

Résultat

#

Après avoir implémenté cela, les tentatives de force brute ont disparu. Les logs ont cessé d’être un chaos. Le serveur se sent plus tranquille.

Fail2ban n’est pas une balle magique, mais c’est un bouclier efficace contre l’automatisation basique. Ça vaut la peine de prendre le temps de le configurer correctement.

Équipement recommandé

#

• YubiKey 5 NFC — Clé de sécurité physique pour l’authentification à deux facteurs et l’accès SSH sécurisé
• Raspberry Pi 3 B+ — Serveur léger à faible consommation pour débuter votre homelab

Liens d’affiliation. Aucun coût supplémentaire pour vous.