Le logiciel Fail2ban lit les journaux d’accès à nos services et applique des restrictions d’accès selon des règles prédéfinies à l’aide d’iptables.
Nous l’utilions pour protéger nos services de tentatives d’attaque par force brute ou d’abus de ressources.
Nous avons commencé à utiliser Fail2ban dès l’ouverture de notre premier service, pour protéger notre service Mail et l’accès SSH à nos serveurs.
Avec la mise en place de l’infrastructure V2, nous avons dû détourner l’usage du logiciel pour répliquer les bannissements d’IP sur plusieurs serveurs.
Nous utilisons l’image crazymax/fail2ban pour déployer une instance conteneurisée de Fail2ban, mais qui agit tout de même sur le réseau de l’hôte grâce à des droits étendus.
Notre configuration est assez spécifique, car adaptée pour une infrastructure à plusieurs serveurs. Nous utilisons un modèle client-serveur pour distribuer un bannissement sur plusieurs machines, très similaire à celui présenté sur ce dépôt :
Il est possible de tester le bannissement d’une IP depuis Antigone :
docker exec -it fail2ban-server bash
$> fail2ban-client set NOM_DE_LA_JAIL banip IPV4_OU_IPV6
Le bannissement de l’IP devrait être effectif sur toutes les machines en l’espace d’une minute. Un bon moyen de vérifier si le bannissement a bien été transmis est de consulter le fichier des bannissements partagé sur NFS.
Il est important de vérifier si le bannissement de l’IP est bien effectif depuis l’extérieur : pour tester, vous pouvez bannir votre propre IP. Attention à utiliser une jail qui ne concerne pas le port SSH (une jail HTTP ou IMAP/POP/SMTP peut faire l’affaire), sinon vous risquez de vous retrouver bloqué·e à l’extérieur.
Fail2ban consomme beaucoup de ressources pour une activité qui ne devrait pas en solliciter autant (de la lecture de journaux).
Il est important de noter que sa consommation varie fortement selon le nombre de détections par jail configurée. Si Fail2ban doit garder en mémoire un grand nombre de tentatives de nombreuses IPs, sa consommation de RAM peut exploser (dépasser 500 Mo) et ses performances se dégraderont fortement.
Cette configuration de fail2ban en mode « distribué » est un détournement de l’usage principal du logiciel et n’est pas du tout pratique à utiliser. Préparer une nouvelle infrastructure basée sur ce modèle n’est pas recommandé. D’autres solutions sont à l’étude.
Il est parfois nécessaire de créer de nouvelles jails Fail2ban (ou d’ajuster les paramètres des jails existantes) pour bloquer plus efficacement certaines requêtes, éviter les risques de faux positifs ou étendre la protection sur de nouvelles routes.
Fail2ban utilise des expressions régulières pour le filtrage des journaux, qui sont testables avec la commande fail2ban-regex dans le conteneur.
Un bug lié à notre usage spécifique de fail2ban crée des processus pour le bannissement des IPs qui ne se terminent jamais. Il est nécessaire de redémarrer régulièrement les conteneurs de fail2ban pour éviter qu’ils arrivent à leur limite de PIDs fixée dans leur fichier docker-compose.yml respectif.
La mise à jour de fail2ban s’effectue en téléchargeant la nouvelle image et en redémarrant le conteneur. Toutefois, à cause de notre configuration spécifique, des changements qui cassent notre configuration pourraient se manifester. La lecture des notes de version et quelques tests sont incontournables avant un déploiement généralisé de la mise à jour.
Fail2ban est très consommateur en ressources et n’est pas adapté pour une infrastructure avec plusieurs serveurs. Nous envisageons de changer de solution de protection pour nous orienter vers un logiciel plus adapté. Nous étudions notamment CrowdSec pour cet usage.