Fail2Ban UI : l'interface web qui manquait à Fail2Ban pour piloter ses bannissements

Fail2Ban surveille les journaux d'un serveur Linux et bannit automatiquement, via iptables ou nftables, toute adresse IP qui multiplie les tentatives de connexion échouées — SSH, formulaire de connexion web, serveur mail. Le projet existe depuis 2011, cumule plus de 18 000 étoiles sur GitHub et reste l'une des premières lignes de défense installées sur un serveur exposé. Mais tout, de la consultation de l'état des jails à la levée d'un bannissement, se fait en ligne de commande.

Fail2Ban UI comble ce vide sans se substituer à Fail2Ban. Publié par la société suisse Swissmakers GmbH en janvier 2025 sous licence AGPL-3.0, ce binaire Go — plus de 330 étoiles GitHub mi-2026 — se connecte aux instances Fail2Ban déjà en place plutôt que de reprendre lui-même les décisions de bannissement, qui restent entièrement du ressort du démon Fail2Ban de chaque hôte.

Un tableau de bord en temps réel

Le tableau de bord affiche en temps réel, via WebSocket, les jails actifs ainsi que les bans et débans à mesure qu'ils surviennent, avec une recherche centralisée pour localiser une IP sur l'ensemble des jails et des serveurs surveillés. Un module de débogage de filtre teste en direct un motif regex contre les journaux existants, et un module « Ban Insights » affiche une chronologie façon SIEM — à la Kibana — avec comparaison d'incidents et analyse par pays.

Piloter plusieurs serveurs à la fois

Trois connecteurs permettent de piloter plusieurs serveurs à distance depuis une seule interface : connexion locale, SSH via un compte de service dédié aux droits sudo minimaux, ou agent HTTP léger installé sur chaque hôte. Vient s'y ajouter une gestion des récidivistes qui pousse un blocage permanent directement sur un pare-feu MikroTik, pfSense ou OPNsense — précieux dès qu'on protège plus d'un serveur exposé, ce qui est le cas de la quasi-totalité des infrastructures auto-hébergées un tant soit peu sérieuses.

Alertes et bonnes pratiques de sécurité

Les alertes se configurent par e-mail (SMTP), webhook ou Elasticsearch, enrichies en données GeoIP et Whois et croisées avec des bases de renseignement de menace comme AlienVault OTX ou AbuseIPDB. L'authentification OIDC est prise en charge en option (Keycloak, Authentik, Pocket-ID), et le projet le rappelle lui-même noir sur blanc dans sa documentation : ne jamais exposer l'interface directement sur Internet, mais la placer derrière un reverse proxy, un VPN ou un pare-feu.

C'est la posture suivie ici pour tous les services internes exposés : jamais nu sur Internet, toujours derrière une authentification centralisée.

Ajouter une interface comme Fail2Ban UI ne crée aucune nouvelle surface d'attaque tant qu'elle reste protégée de la même façon.