Fail2ban : configurer un bannissement vérifiable

Fail2ban lit les journaux, compte des échecs reconnus par un filtre et demande une action de bannissement. Il ne remplace ni les clés SSH, ni les mises à jour, ni le pare-feu. Configurez d’abord la bonne source de journal, testez le filtre, puis vérifiez l’adresse réellement bannie.

Comprendre ce que Fail2ban fait réellement

Fail2ban est un mécanisme réactif. Une tentative doit produire une ligne exploitable dans un journal. Un filtre extrait l’adresse, un jail compte les occurrences, puis une action ajoute ou retire un bannissement dans le système choisi.

Cette chaîne réduit le bruit des attaques répétées. Elle ne corrige pas un mot de passe faible, une vulnérabilité non corrigée ou un service exposé inutilement. Gardez l’authentification par clé, les correctifs, les règles réseau minimales et la supervision.

Avant l’installation, vérifiez :

• où le service écrit ses échecs ;
• si le journal contient l’adresse cliente réelle ;
• quelle pile firewall est active ;
• si le serveur accepte IPv4, IPv6 ou les deux.

Installer puis observer les sources disponibles

Sur Ubuntu ou Debian, installez le paquet de la distribution :

sudo apt update
sudo apt install fail2ban
sudo systemctl status fail2ban --no-pager

Inspectez les messages SSH dans le journal avant de choisir un backend :

sudo journalctl -u ssh --since '30 minutes ago'
sudo journalctl -u sshd --since '30 minutes ago'

Le nom d’unité dépend du système. Une commande vide n’est pas la preuve que tout va bien. Elle peut simplement viser la mauvaise unité ou une période sans tentative.

Ne pas modifier jail.conf

Les fichiers .conf sont fournis par le paquet et peuvent évoluer lors d’une mise à jour. Placez uniquement vos écarts dans /etc/fail2ban/jail.local ou dans un fichier .local sous jail.d.

[DEFAULT]
bantime = 10m
findtime = 10m
maxretry = 5

[sshd]
enabled = true
backend = systemd

Ces valeurs sont un point de départ pédagogique, pas un réglage universel. Mesurez le comportement légitime avant de durcir. Une saisie maladroite, un outil d’administration ou plusieurs utilisateurs derrière la même adresse peuvent atteindre le seuil.

Avec backend = systemd, le jail lit le journal via le journalmatch du filtre. N’ajoutez pas logpath à ce jail : cette option n’est pas valable pour le backend systemd.

Relier filtre, jail et action

Un jail active un filtre et une ou plusieurs actions. Le filtre décide quelles lignes sont des échecs ; l’action décide comment l’adresse est bannie. Le port déclaré dans le jail doit correspondre au service réellement protégé, notamment si SSH écoute ailleurs.

sudo fail2ban-client -t
sudo fail2ban-client status
sudo fail2ban-client status sshd

Un service démarré ne prouve pas qu’un jail fonctionne. status doit lister le jail attendu, sa source et son action. Consultez également les erreurs de configuration :

sudo journalctl -u fail2ban --since '30 minutes ago'

Tester le filtre avant de provoquer un bannissement

Pour un backend journal, testez le filtre fourni sur les entrées accessibles :

sudo fail2ban-regex systemd-journal sshd

Pour un fichier de journal, passez son chemin et le nom du filtre :

sudo fail2ban-regex /var/log/auth.log sshd

Le résumé distingue les correspondances, les lignes ignorées et les lignes manquées. L’objectif n’est pas le plus grand nombre de correspondances. Un filtre trop large peut bannir une adresse sur une ligne sans échec d’authentification.

Testez avec des extraits représentatifs et sans données sensibles. Si le format du journal a changé, corrigez la source ou le filtre avant d’augmenter maxretry au hasard.

Éviter le verrouillage avec ignoreip

ignoreip peut exclure une adresse ou un réseau du bannissement. C’est utile pour une adresse d’administration stable, mais dangereux si l’exemption est trop large.

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

Remplacez l’adresse d’exemple par une source réellement maîtrisée. Une adresse dynamique peut changer ; une adresse partagée peut aussi cacher un attaquant. N’exemptez jamais tout Internet pour éviter un blocage. Préparez plutôt une console de secours et la commande de déban.

Pour retirer un bannissement précis :

sudo fail2ban-client set sshd unbanip 203.0.113.10
sudo fail2ban-client status sshd

Le nom du jail et l’adresse doivent venir du statut courant. Ne lancez pas un déban global si une seule adresse pose problème.

Vérifier IPv4 et IPv6 séparément

La capacité de bannir les deux familles dépend de la version installée et de l’action choisie. Vérifiez la version, les adresses observées et les règles créées sur le serveur réel.

fail2ban-client --version
sudo fail2ban-client status sshd
sudo nft list ruleset

Si le système utilise un autre backend firewall, adaptez la commande d’inspection. Une liste de bannis dans Fail2ban n’est pas encore une preuve réseau. Confirmez que l’action produit une règle pour la famille de l’adresse et testez depuis une machine contrôlée.

Traiter correctement un proxy inverse

Derrière un CDN ou un proxy inverse, le journal peut contenir l’adresse du proxy au lieu de celle du client. Fail2ban bannira alors ce qu’il voit : potentiellement le proxy partagé, avec un impact bien plus large que prévu.

Pour NGINX, le module real IP remplace l’adresse cliente à partir d’un en-tête seulement pour les sources déclarées par set_real_ip_from. Ne faites jamais confiance à X-Forwarded-For depuis n’importe quelle adresse. Un client pourrait forger cet en-tête et provoquer le bannissement d’un tiers.

Sur un VPS, testez depuis l’extérieur : la table de bannissement, le pare-feu hôte et le pare-feu du fournisseur sont des couches différentes.