fail2ban : ce que tu bloques vraiment quand tu bloques une adresse

Personne ne t'a ciblé. Une machine quelque part en Roumanie essaie `root` avec `123456`, puis `admin`, puis `pi`, et recommence. C'est du bruit de fond sur Internet, et fail2ban existe pour arrêter de le lire à la main.

Ce que fait le programme, concrètement

fail2ban lit des journaux. Il applique une expression régulière à chaque ligne, compte les correspondances par adresse IP, et quand le compteur dépasse un seuil dans une fenêtre de temps donnée, il ajoute une règle à ton pare-feu.

Rien de plus. C'est un traducteur entre « ce journal contient un échec d'authentification » et « cette adresse ne parle plus à la machine pendant dix minutes ».

Le daemon s'appelle `fail2ban-server`. Il tourne en arrière-plan. À côté, `fail2ban-client` te permet de lui parler : consulter l'état d'une jail, bannir une adresse manuellement, en libérer une. Un troisième outil, `fail2ban-regex`, sert à tester une expression contre un fichier de journal réel avant de la mettre en production. Ce dernier outil vaut la peine d'être connu : une `failregex` mal écrite qui ne matche rien te donne l'impression d'être protégé.

Tu ne l'es pas.

Les fichiers que tu vas éditer

La configuration se répartit en plusieurs endroits, et c'est là que la plupart des gens se perdent.

`fail2ban.conf` contient les réglages globaux : niveau de journalisation, chemins, socket. Tu n'y touches presque jamais.

`jail.conf` définit les services surveillés, avec le nombre d'échecs tolérés, la durée du bannissement et l'action à exécuter. Sauf que ce fichier appartient au paquet. Une mise à jour l'écrasera.

La bonne pratique consiste à créer `jail.local` à côté, ou des fichiers séparés dans `jail.d/`. Ce que tu écris là survit aux mises à jour.

Les filtres vivent dans `filter.d/*.conf`. Chacun contient une ou plusieurs `failregex`. Un filtre par service : `sshd.conf`, `apache-auth.conf`, `dovecot.conf`, `postfix-sasl.conf`. Si ton service n'en a pas, tu écris le tien.

Les actions vivent dans `action.d/*.conf`. Une action, c'est ce qui se passe quand le seuil est franchi : ajouter une règle `iptables`, poser une règle `nftables`, envoyer un courriel, appeler un script. La plupart des distributions livrent des actions prêtes pour `iptables`, `nftables`, `firewalld` et `pf` sur BSD.

fail2ban gère IPv4 et IPv6. Il ne fait pas de différence entre les deux dans sa logique de comptage, mais ton pare-feu, lui, en fait.

Ce que ça coûte

Un bannissement n'est pas une protection. C'est un ralentissement.

L'attaquant qui change d'adresse toutes les deux minutes ne verra jamais ton seuil. Celui qui loue un bloc de mille adresses non plus. fail2ban est efficace contre le balayage automatique et idiot, qui représente l'immense majorité du trafic hostile sur un serveur exposé. Il est inutile contre quelqu'un qui sait ce qu'il fait.

Il y a un second coût, moins visible : les faux positifs.

Une adresse partagée par un opérateur mobile, une université, un réseau d'entreprise derrière un NAT — si quelqu'un sur ce réseau rate trois fois son mot de passe, tout le monde est dehors. Le client légitime qui ne comprend pas pourquoi sa connexion tombe ne pensera pas à ton pare-feu. Il pensera que ton service est cassé.

C'est pour cette raison que la liste blanche (`ignoreip`) n'est pas un ornement. Mets-y au minimum `127.0.0.1/8` et `::1`. Si tu administres depuis une adresse fixe, mets-la aussi. Si tu administres depuis une adresse dynamique, tu vas apprendre à tes dépens pourquoi les gens montent un bastion.

Le rythme des versions

Le projet existe depuis octobre 2004, lancé par Cyril Jaquier. Il est aujourd'hui maintenu par une poignée de contributeurs réguliers — Yaroslav Halchenko, Daniel Black, Steven Hiscocks et d'autres — et publié sous forme de versions stables.

La branche 0.8 a tenu près de six ans, jusqu'à la 0.8.11 en novembre 2013. La 1.1.0 est sortie en avril 2024 et vise les distributions modernes. La 1.1.1 est annoncée pour août 2026, ce qui te donne une idée du rythme : ce n'est pas un projet qui bouge tous les mois.

Cette lenteur est une qualité pour un outil qui touche au pare-feu. Un composant qui filtre du trafic réseau n'a pas besoin de sortir une fonctionnalité par trimestre. Il a besoin de ne pas casser ta connectivité SSH à deux heures du matin.

L'alternative que personne ne nomme

Il existe une autre approche, plus radicale : ne pas exposer SSH du tout.

Déplacer le port ne sert à rien — les scanners le trouvent en quelques heures. Mais désactiver l'authentification par mot de passe et n'accepter que des clés élimine la quasi-totalité du problème. Un attaquant peut essayer `root` autant qu'il veut : il n'y a pas de mot de passe à deviner.

Si tu vas jusque-là, fail2ban perd beaucoup de son intérêt sur SSH. Il garde le sien sur les services web, sur le courriel, sur tout ce qui accepte encore des identifiants.

L'autre alternative est un service managé. Ton hébergeur filtre le bruit avant qu'il atteigne ta machine, et tu ne configures rien. Ce que ça coûte : tu ne vois plus ce qui frappe à la porte, et tu dépends de quelqu'un d'autre pour la politique de blocage.

Le piège de la première installation

Tu installes, tu actives, tu vérifies que le service tourne, et tu passes à autre chose.

Trois semaines plus tard, tu ne peux plus te connecter. Tu as oublié que tu avais lancé une session depuis une adresse que tu viens de bannir toi-même, et le seul moyen de rentrer passe par la console de secours de ton hébergeur.

La commande qui t'aurait sauvé :

``` fail2ban-client status sshd ```

Elle affiche le nombre d'échecs actuels, la liste des adresses bannies et le total depuis le démarrage. Si tu la lances une fois par semaine, tu connais le rythme de ton serveur. Tu sais si tu reçois dix tentatives par jour ou dix mille.

Ce chiffre, à lui seul, vaut l'installation.

Là où ça devient une question de goût

fail2ban fait une chose et la fait depuis vingt ans. Il lit des journaux, il compte, il bloque. Il ne connaît rien à ton application, ne comprend pas le contexte d'une connexion, ne distingue pas un utilisateur qui a oublié son mot de passe d'un script qui teste une liste.

Tu peux écrire tes propres filtres, tes propres actions, brancher un script qui envoie une notification vers ton système de supervision. Chaque filtre ajouté est une expression régulière de plus à maintenir, et une expression régulière qu'on ne teste pas est une expression régulière qui ne matche rien.

Ce que tu gagnes en finesse, tu le paies en surface à surveiller.

La vraie question n'est pas de savoir si fail2ban est le bon outil. C'est de savoir combien de temps tu veux passer à lire des journaux d'authentification. Si la réponse est « le moins possible », un hébergeur qui filtre en amont te coûtera moins cher en attention. Si la réponse est « je veux voir ce qui se passe et décider moi-même », fail2ban te donne exactement ça, avec la responsabilité qui vient avec.