Fail2ban : bannir les intrus sans se bannir soi-même

Fail2ban est souvent posé en quelques minutes sur un serveur, puis oublié. C’est justement là que commencent les erreurs : on croit qu’une prison protège, alors qu’elle ne capture rien, ou l’on finit par se faire bannir soi-même dès le premier test. Sur un hôte exposé à Internet, l’objectif n’est pas d’empiler des règles, mais de vérifier ce que fail2ban bloque réellement, prison par prison, en commençant par l’accès SSH.

Éviter le piège classique, se bannir soi-même

Le premier accident avec fail2ban n’est pas une attaque, c’est l’auto-bannissement. Il suffit de rater plusieurs authentifications SSH depuis sa propre connexion pour se retrouver dehors, parfois sans autre accès que la console de secours de l’hébergeur. Avant toute activation en production, notez votre adresse actuelle et vérifiez que vous savez comprendre ce qu’est une adresse IP publique, surtout si vous administrez depuis une box, un VPN ou un accès mobile qui peut changer.

La première protection concrète consiste à mettre votre IP d’administration en liste blanche. Si vous avez plusieurs points d’entrée légitimes, par exemple bureau, domicile et tunnel VPN, traitez-les avant d’ouvrir la moindre prison. Il faut aussi garder une session SSH déjà connectée pendant les essais, pour pouvoir retirer un bannissement si besoin. Cette précaution fait partie de la Sécurité d’un serveur au même titre que les droits d’accès ou les mises à jour.

Avant de modifier quoi que ce soit, prévoyez aussi des sauvegardes serveur avant toute modification sensible. Fail2ban ne casse pas un système à lui seul, mais une erreur de configuration peut bloquer un service exposé ou compliquer une intervention à distance.

Quelles prisons fail2ban poser d’abord

Sur un serveur exposé, toutes les prisons n’ont pas la même utilité. L’ordre le plus rationnel est simple : l’accès distant d’abord, le serveur web ensuite, l’authentification applicative enfin.

Fail2ban SSH en premier

La prison la plus utile reste celle de fail2ban ssh. Les tentatives automatisées sur SSH sont fréquentes sur les machines connectées en IPv4 publique. Vous n’avez pas besoin d’inventer un scénario : regardez vos journaux d’authentification sur quelques jours, vous verrez vite si des échecs reviennent par grappes depuis les mêmes sources. Cette prison a un intérêt immédiat car elle vise l’accès d’administration lui-même.

Elle ne remplace pas les bases, par exemple clés SSH, désactivation des accès inutiles et restriction des ouvertures réseau. Pour cela, gardez en tête les bases pour sécuriser un serveur. Fail2ban ajoute une couche réactive : après plusieurs échecs visibles dans les journaux, il peut bannir IP pendant une durée donnée.

Le serveur web ensuite

La deuxième famille utile concerne le serveur web, quand des journaux remontent des comportements répétitifs exploitables par fail2ban, par exemple des requêtes anormales sur des points d’accès sensibles ou des erreurs d’authentification HTTP. Là encore, tout dépend de ce qui est effectivement écrit dans les logs. Une prison active sur le papier mais sans événement détectable ne protège rien.

Cette couche complète le rôle du pare-feu dans la protection réseau. Le pare-feu filtre selon des règles réseau, fail2ban réagit à des événements consignés. Les deux répondent à des signaux différents.

L’authentification applicative en troisième

En dernier viennent les applications elles-mêmes, par exemple un CMS, une interface d’administration ou un service qui journalise ses échecs de connexion. C’est ici que la qualité des logs fait toute la différence. Si vous administrez un site exposé, vous pouvez rapprocher cette logique de protéger un site contre les attaques par brute force. Dans tous les cas, une protection brute force n’existe que si les tentatives ratées sont bien enregistrées et lisibles par fail2ban.

Comment vérifier qu’une prison fail2ban agit vraiment

Le point le moins traité dans les tutoriels est pourtant le plus utile : une prison fail2ban n’est pas validée parce qu’elle est démarrée, mais parce qu’elle compte des événements et bannit quand le seuil est atteint. Sur un serveur en production, il faut lire son compteur.

Les indicateurs à contrôler sont toujours les mêmes :

• le nombre d’échecs détectés par la prison ;
• le nombre total d’IP bannies ;
• la liste des IP actuellement bannies ;
• l’évolution de ces valeurs dans le temps.

Si une prison reste à zéro pendant des semaines sur un service pourtant exposé et attaqué, deux possibilités dominent : soit le service n’est pas réellement ciblé, soit le filtre ne correspond pas aux journaux présents sur la machine. Dans les deux cas, croire qu’elle protège serait une erreur.

La bonne méthode consiste à observer sur plusieurs jours, puis à croiser avec les journaux du service visé. Si vous voyez dix, cinquante ou cent échecs d’authentification dans les logs, mais aucun bannissement côté fail2ban, la prison ne fait pas son travail. À l’inverse, si le compteur monte et que des IP apparaissent dans la liste des bannis, vous avez une mesure concrète de son action.

Mesurer ce que fail2ban bloque sur un serveur exposé

Mesurer, ici, ne veut pas dire produire des statistiques universelles. Il n’existe pas de chiffre public valable pour tous les serveurs, car l’exposition varie selon l’adresse, les services ouverts, la réputation du bloc IP et la durée d’observation. En revanche, chaque administrateur peut mesurer sa propre surface d’attaque observée.

Procédez simplement :

• relevez les compteurs de chaque prison sur une période fixe, par exemple 24 heures ou 7 jours ;
• notez combien d’IP ont été bannies par service ;
• comparez ces valeurs avec les journaux natifs du service ;
• vérifiez si les mêmes sources reviennent après expiration du bannissement.

Ce suivi permet de hiérarchiser vos efforts. Si SSH déclenche des bannissements quotidiens et que votre prison web ne voit rien, vous savez où fail2ban apporte un effet réel. Si une prison applicative ne capture jamais rien, elle n’est peut-être pas prioritaire, ou bien ses journaux ne sont pas adaptés.

Ajuster sans multiplier les règles inutiles

Une erreur fréquente consiste à activer beaucoup de prisons et à ne plus les relire. Sur un petit serveur, mieux vaut trois prisons utiles et contrôlées qu’une longue liste inactive. À chaque ajout, posez-vous trois questions : le service est-il exposé, produit-il des journaux pertinents, et la prison a-t-elle déjà attrapé quelque chose ?

Il faut aussi tenir compte de vos usages légitimes. Si vous changez souvent d’adresse, si plusieurs administrateurs se connectent depuis des réseaux variables, ou si un outil d’intégration tente parfois plusieurs connexions, des seuils trop agressifs peuvent gêner l’exploitation. Le bon réglage n’est pas le plus dur, c’est celui qui bloque les échecs anormaux sans couper l’administration normale.

Enfin, testez sobrement. L’idée n’est pas de rejouer une attaque complète, mais de vérifier qu’un nombre limité d’échecs volontaires, depuis une machine de test que vous contrôlez, fait bien monter le compteur de la prison visée. Si ce n’est pas le cas, il faut investiguer avant de déclarer la protection opérationnelle.

La réserve

Fail2ban a une limite nette : il lit des journaux. Il ne voit donc rien de ce qui n’est pas écrit dans les logs, rien de ce qui est mal journalisé, et rien de ce qui contourne ce niveau d’observation. Une prison silencieuse ne veut pas forcément dire absence d’attaque, mais parfois absence de traces exploitables.

Autre contrepartie, fail2ban ne remplace pas un pare-feu. Il intervient après détection d’événements consignés, pas comme filtre réseau général. Enfin, le risque de se bannir soi-même reste concret, surtout lors des premiers essais ou si votre IP d’administration change souvent. La liste blanche et une session de secours déjà ouverte ne sont pas des détails, ce sont des garde-fous d’exploitation.

Questions frequentes

Qu'est-ce que Fail2ban ?

Fail2ban est un service qui lit des journaux système ou applicatifs pour repérer des échecs répétés, puis bannir temporairement une adresse IP via les mécanismes de filtrage du serveur. Son intérêt principal sur une machine exposée est de réduire les tentatives répétitives, notamment sur SSH, à condition que les événements soient bien consignés et que la prison concernée capture réellement quelque chose.

Comment configurer Fail2ban ?

La bonne approche consiste à commencer par votre propre adresse en liste blanche, puis à activer d’abord la prison SSH, ensuite celles du serveur web, puis celles des applications. Inutile de recopier toute la syntaxe de configuration : la documentation fait autorité. En pratique, il faut surtout vérifier les journaux lus, confirmer que les compteurs de prison montent, et ajuster les seuils pour éviter les faux positifs.