Les deux outils lisent des journaux et bannissent des adresses, et à première vue CrowdSec n’est qu’un Fail2ban au code plus récent. La différence est plus substantielle, et elle tient non à l’âge du code mais à l’origine de la décision de blocage.

L’architecture

Fail2ban est un processus unique qui lit les journaux, compte les correspondances d’expressions régulières et appelle une commande de pare-feu. Chaque décision se prend sur votre machine à partir de vos compteurs. Rien n’est envoyé nulle part, il n’y a pas de dépendances, et la configuration se résume à des fichiers texte.

CrowdSec est scindé en deux, et c’est l’essentiel à comprendre avant l’installation. L’agent lui-même ne fait que détecter : il analyse les journaux, applique des scénarios et inscrit des décisions dans sa propre base. Les décisions sont appliquées par un programme distinct, le bouncer. Sans bouncer installé, CrowdSec tourne, affiche des alertes, tient une liste de décisions — et ne bloque rien.

C’est la déception la plus fréquente lors de la première rencontre : l’outil est installé, les attaques sont visibles, et le trafic circule exactement comme avant.

sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables
sudo cscli bouncers list

Cette dernière commande doit montrer au moins une entrée enregistrée. Une liste vide signifie qu’il n’y a pas de blocage.

La seconde différence : la réputation partagée

Fail2ban ne connaît que ce qui s’est passé chez vous. Une adresse qui attaquait hier cent serveurs étrangers est propre à ses yeux jusqu’à ce qu’elle frappe à votre porte — et ses cinq premières tentatives sont gratuites.

CrowdSec envoie les signaux de ses déclenchements dans un réseau commun et en reçoit une liste d’adresses repérées ailleurs. Effet pratique : une part notable des tentatives est coupée avant le premier essai. C’est particulièrement important contre les attaques distribuées — des milliers d’adresses avec une tentative chacune, où les compteurs locaux sont impuissants par définition.

Et voici ce qu’il faut savoir d’avance : l’échange est bidirectionnel. Ce qui quitte votre serveur, ce sont les adresses des attaquants et les types de scénarios déclenchés. Un fonctionnement entièrement local est possible — sans inscription à la console infonuagique —, mais la liste commune vous devient alors inaccessible, et l’avantage principal disparaît. C’est un choix délibéré, pas un détail de configuration.

Les commandes du quotidien

sudo cscli metrics
sudo cscli alerts list
sudo cscli decisions list
sudo cscli decisions delete --ip 203.0.113.25

metrics répond à la question de savoir si les journaux sont lus du tout : si le nombre de lignes analysées est nul, la collection pour votre serveur web n’est pas installée ou le chemin du journal est erroné. C’est le deuxième cas le plus fréquent de « c’est installé et ça ne fait rien ».

sudo cscli collections list
sudo cscli collections install crowdsecurity/nginx

Les ressources

CrowdSec est écrit en Go et garde son état dans une base. La consommation mémoire est de l’ordre d’une centaine de mégaoctets, plus le bouncer. Sur un serveur d’un gigaoctet c’est sensible, à partir de deux ce ne l’est plus. Fail2ban est plus léger — et en fait moins.

Faut-il garder les deux

Ils ne se gênent pas : l’un écrit ses règles dans le pare-feu, l’autre les siennes, et bannir deux fois la même adresse ne nuit à rien. Une répartition sensée ressemble à ceci.

CrowdSec prend en charge le volume : la recherche de mots de passe SSH, le balayage du serveur web, les mauvaises adresses connues de la liste commune. Fail2ban reste là où vous avez un journal propre dans un format propre, pour lequel écrire une expression régulière est plus simple qu’un scénario — une application maison, un service rare, un formulaire de connexion particulier.

S’il faut n’en choisir qu’un, le repère est le suivant : sur un serveur hébergeant un site constamment sondé, CrowdSec apporte davantage grâce à la liste commune. Sur un serveur accessible à vous seul par SSH avec des clés, la différence est faible — l’essentiel du travail y a déjà été fait en désactivant les mots de passe.

Une limite commune

Aucun des deux ne protège d’une vulnérabilité applicative. Tous deux travaillent sur la fréquence des requêtes et la réputation d’une adresse, et une requête qui exploite une faille d’extension du premier coup depuis une adresse propre passera devant les deux. C’est le travail d’autres outils — un WAF au niveau des requêtes et des mises à jour à temps. Bannir des adresses supprime le bruit de fond, pas la cause.

La valeur pratique de l’un comme de l’autre dépend de ce que quelqu’un en regarde le résultat. Un nombre de décisions qui augmente, un scénario déclenché pour la première fois, un changement des pays d’où viennent les tentatives — voilà l’information pour laquelle l’outil a été installé. À quoi elle ressemble sur une page, la démonstration ci-dessous le montre.