Configurer et dépanner Fail2ban : jails, filtres, bannissements, nftables, journaux systemd, déblocage d’IP et protection de SSH et des services web.
Filtrer
Fail2ban surveille les journaux, détecte des échecs répétés puis applique temporairement une action de bannissement, souvent via nftables ou iptables. Il réduit le bruit automatisé mais ne remplace ni les correctifs, ni une authentification forte.
Installer et vérifier le service
5 cmds
sudo apt update && sudo apt install fail2banDebian et Ubuntu
fail2ban-client versionVersion installée
sudo systemctl enable --now fail2banActiver et démarrer
sudo systemctl status fail2ban
sudo fail2ban-client pingVérifier la communication avec le serveur
Organisation de la configuration
● jail.conf contient les valeurs fournies par le paquet
● jail.local surcharge la configuration globale
● jail.d/*.conf permet de séparer les jails personnalisées
● filter.d/*.conf contient les expressions de détection
● action.d/*.conf contient les actions de bannissement
Ne pas modifier directement jail.conf : une mise à jour du paquet peut écraser ou compliquer les changements. Utiliser jail.local ou /etc/fail2ban/jail.d/.
Configuration globale minimale
9 cmds
Exemple /etc/fail2ban/jail.d/local.conf. Adapter le réseau d'administration avant de recharger.
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
port = ssh
backend = systemd
● findtime : fenêtre pendant laquelle les échecs sont comptés
● maxretry : nombre d'échecs avant bannissement
● bantime : durée du bannissement
● ignoreip : IP et réseaux qui ne doivent jamais être bannis
Une plage trop large dans ignoreip désactive la protection pour tout ce réseau. Ne jamais ajouter une adresse non maîtrisée uniquement pour faire disparaître un bannissement.
Valider et recharger
5 cmds
sudo fail2ban-client -tTester la configuration
sudo fail2ban-client -dAfficher la configuration calculée
sudo fail2ban-client reloadRecharger sans arrêter le service
sudo systemctl restart fail2banRedémarrer si nécessaire
sudo journalctl -u fail2ban -n 100 --no-pagerVérifier les erreurs
Toujours exécuter fail2ban-client -t avant un reload ou un restart. Une erreur de syntaxe peut empêcher certaines jails de démarrer.
Voir les jails et bannissements
6 cmds
sudo fail2ban-client statusJails actives
sudo fail2ban-client status sshdDétails de la jail SSH
sudo fail2ban-client get sshd bantimeValeur effective de bantime
sudo fail2ban-client get sshd findtimeValeur effective de findtime
sudo fail2ban-client get sshd maxretryValeur effective de maxretry
sudo fail2ban-client get sshd ignoreipAdresses ignorées
Bannir et débannir une IP
4 cmds
sudo fail2ban-client set sshd banip 203.0.113.50Bannir manuellement dans sshd
sudo fail2ban-client set sshd unbanip 203.0.113.50Débannir dans sshd
sudo fail2ban-client unban 203.0.113.50Débannir dans toutes les jails compatibles
sudo fail2ban-client banned 203.0.113.50Chercher les jails qui bannissent cette IP
Avant de débannir, vérifier la raison du blocage et l'origine de l'adresse. Une IP peut être bannie simultanément dans plusieurs jails.
Lire les logs
5 cmds
sudo journalctl -u fail2ban -fSuivre le service en temps réel
sudo journalctl -u ssh --since '1 hour ago'Échecs SSH sur certaines distributions
sudo journalctl -u sshd --since '1 hour ago'Variante du nom du service
sudo tail -f /var/log/fail2ban.logSi Fail2ban écrit dans un fichier
sudo grep 'Ban\|Unban' /var/log/fail2ban.logHistorique des actions
Tester un filtre
4 cmds
sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.confTester sur un fichier
sudo fail2ban-regex systemd-journal sshdTester le backend journal si pris en charge
sudo fail2ban-client get sshd failregexVoir les regex effectives
sudo fail2ban-client get sshd journalmatchVoir le filtre journal systemd
Tester les filtres sur des journaux représentatifs. Une regex trop large peut bannir des utilisateurs légitimes ; une regex trop stricte laisse passer les attaques.
Le format exact d'un access log dépend de Nginx, du proxy et de l'application. Si un reverse proxy est utilisé, vérifier que le journal contient la véritable IP cliente de manière fiable.
Choisir nftables ou iptables
4 cmds
iptables --versionVoir nf_tables ou legacy
sudo nft list rulesetVérifier les règles nftables
sudo iptables -SVérifier les règles iptables
sudo fail2ban-client get sshd actionsActions de la jail
La valeur par défaut de banaction dépend du paquet et de la distribution. Ne la forcer que si le backend pare-feu est compris et testé.
Fail2ban et Docker
4 cmds
Les ports publiés par Docker utilisent le chemin FORWARD. Une action conçue pour INPUT peut ne pas bloquer le trafic destiné à un conteneur. Les logs doivent aussi exposer la vraie IP cliente.
docker logs --tail 100 reverse-proxyVérifier la présence des IP clientes
sudo nft list ruleset | lessTrouver les chaînes Docker et Fail2ban
sudo iptables -S DOCKER-USERChaîne utilisateur du backend iptables
sudo fail2ban-client status mon-appVoir les bannissements
Ne pas copier une action Docker trouvée en ligne sans l'adapter au backend et à la version. Vérifier le hook, la chaîne, le sens du trafic et tester le blocage depuis une autre machine.
Bannissements progressifs
5 cmds
[DEFAULT]
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w
bantime.rndtime = 10m
Le bannissement progressif est utile contre les récidivistes, mais doit rester compatible avec la politique d'exploitation et la gestion des faux positifs.
Diagnostic d'une jail inactive
6 cmds
sudo fail2ban-client -tSyntaxe générale
sudo fail2ban-client -vvvdFichiers chargés et configuration détaillée
sudo fail2ban-client statusJail présente ou absente
sudo fail2ban-client status nom-jailStatut précis
sudo journalctl -u fail2ban -b -p warningErreurs depuis le démarrage
sudo test -r /chemin/du/log && echo lisibleVérifier le journal
● La jail porte enabled = true
● Le filtre existe dans filter.d
● Le logpath existe ou le journalmatch correspond
● Le service Fail2ban peut lire la source de logs
● Le filtre reconnaît les lignes avec fail2ban-regex
● L'action de bannissement correspond au backend pare-feu
Limites et bonnes pratiques
● Préférer les clés SSH et désactiver l'authentification par mot de passe lorsque possible
● Déployer MFA sur les services compatibles
● Corriger les vulnérabilités au lieu de compter sur le bannissement
● Ajouter le réseau d'administration à ignoreip avec précision
● Surveiller les faux positifs et la croissance des logs
● Tester régulièrement que les règles sont réellement appliquées
● Conserver un moyen d'accès hors bande au serveur