CrowdSec vs Fail2Ban : différences dans la pratique

Bien comprendre CrowdSec et Fail2Ban

Le choix approprié ne dépend pas de l'outil considéré comme le plus moderne, mais du serveur, des données de journalisation et du point d'application souhaité. Pour un service SSH unique avec des messages d'erreur clairs, Fail2Ban peut s'avérer très efficace. CrowdSec devient intéressant lorsqu'il s'agit d'analyser et de sécuriser conjointement plusieurs sources de journaux, différents niveaux de protection ou des systèmes distribués.

Ces deux solutions visent à détection des attaques basée sur les journaux: Ils analysent les événements liés à la sécurité, tels que les tentatives de connexion infructueuses, les classent selon un modèle et peuvent faire bloquer une adresse IP. Pour ce faire, Fail2Ban combine des filtres et des actions dans des « jails ». CrowdSec traite les données collectées via son moteur de sécurité et génère des décisions dont la mise en œuvre est prise en charge par un composant de remédiation distinct.

Ce qui compte, c'est ce qui est réellement consigné. Sans horodatage, sans adresse IP source exploitable et sans source de journalisation appropriée, aucun de ces outils ne peut attribuer une attaque de manière fiable. De plus, un blocage n'offre une protection que là où il est techniquement applicable : une règle de pare-feu locale n'est pas automatiquement efficace si le trafic passe au préalable par un proxy inverse externe ou un équilibreur de charge.

Comme Prévention des intrusions Ces deux outils complètent une architecture de sécurité, mais ne la remplacent pas. Les mises à jour de sécurité corrigent les vulnérabilités connues, une authentification forte et, dans la mesure du possible, à plusieurs niveaux limite l'utilisation abusive des comptes, tandis que des règles de pare-feu restrictives réduisent le nombre de services accessibles. Les sauvegardes limitent les dommages après un incident, tandis que la surveillance continue des journaux permet également de détecter les problèmes qui ne déclenchent pas de blocage.

La question pratique qui se pose donc est la suivante : quels modèles faut-il détecter, à quel niveau la réaction doit-elle intervenir et qui gère les règles, les exceptions et les journaux ? Ce n’est qu’ensuite qu’il sera possible de décider en connaissance de cause si une configuration locale et simple de la « jail » suffit ou si les composants distincts de CrowdSec apportent une valeur ajoutée tangible à l’infrastructure.

Comment Fail2Ban associe les « jails » et les actions

Fail2Ban gère la détection et la réaction dans Jails. Avec SSH, une « jail » lit par exemple les journaux d'authentification ou le journal système. Un filtre y recherche les tentatives de connexion infructueuses provenant d'une adresse IP source. Si celle-ci dépasse le nombre autorisé de tentatives infructueuses au cours de la période configurée, Fail2Ban traite cette correspondance comme un cas de blocage.

L'action qui s'ensuit détermine la réaction. Elle vient souvent compléter une règle du pare-feu local, mais d'autres actions configurées sont également possibles. La chaîne est ainsi traçable : la source de journalisation fournit des lignes, le filtre identifie les événements pertinents, la « jail » les compte et l'action met en œuvre la contre-mesure prévue. Cela facilite le dépannage, à condition que le format du journal et le filtre soient compatibles.

Un « jail » utilise exactement un filtre, mais peut effectuer plusieurs actions. Ainsi, un même cas de blocage SSH détecté peut, par exemple, déclencher une action de pare-feu et, en outre, générer une notification. La mise en place de plusieurs actions rend la réaction plus flexible, mais ne modifie pas le principe de base de la détection : toutes dépendent du même filtre et de son interprétation des lignes de journal.

Les textes rédigés par vos soins nécessitent une attention particulière Filtre Regex. La documentation disponible sur les filtres constitue expressément un guide de développement pour Fail2Ban 0.9.0.dev et non une preuve de fonctionnement pour une version stable spécifique du paquet. Vos remarques générales restent utiles pour le développement des filtres : les variantes réelles de formats de journaux doivent être prises en compte, tandis que les motifs ne doivent pas être trop larges. Les nouveaux filtres doivent donc d’abord être testés avec des lignes d’exemple anonymisées avant de déclencher des blocages.

Les modifications locales doivent en principe être enregistrées dans des fichiers portant l'extension .local, et non dans celles qui ont été livrées .conf-fichiers. Cela permet de mieux suivre les paramètres personnalisés relatifs aux chemins d'accès aux fichiers journaux, aux réseaux autorisés ou aux actions lors des mises à jour de paquets, et évite qu'ils ne soient simplement écrasés. Avant le déploiement, il convient également de vérifier si la source de journalisation choisie existe bel et bien et contient bien les événements attendus.

Le parcours de CrowdSec : du journal au blocage

CrowdSec sépare plus clairement la détection et l'application en composants distincts. Tout d'abord, les sources d'acquisition définissent les journaux ou flux d'événements à lire. Les analyseurs normalisent ces données ; des scénarios évaluent ensuite les modèles et les comportements. Si un modèle correspondant est détecté, une alerte est générée. L’API locale peut alors, sur la base de profils configurés, prendre une décision, par exemple un blocage d’adresse IP temporaire.

Un bref exemple illustre le processus : les erreurs d'authentification d'un service sont transmises au moteur via le module d'acquisition. Les analyseurs syntaxiques identifient des champs tels que l'heure, le service et l'adresse IP source ; un scénario évalue les tentatives infructueuses répétées. L'alerte ainsi générée est transmise à l'API locale, qui peut prendre une décision à l'aide d'un profil adapté. Ce n'est qu'une fois connectée Composant de remédiation applique cette décision au point de protection prévu.

Ce composant est également appelé « Bouncer » dans le jargon. Selon la variante, il peut appliquer des décisions, par exemple au niveau d’un pare-feu, d’un proxy inverse ou d’un serveur web. Le moteur de sécurité détecte à lui seul les incidents et gère les alertes ainsi que les décisions via l’API locale, mais il ne bloque pas le trafic. Sans composant de remédiation correctement connecté, une décision générée reste une simple information sans blocage actif du réseau ou de l’application.

Concrètement, cette séparation permet de répartir la détection et le blocage sur différents points de l'infrastructure. Elle augmente toutefois la complexité opérationnelle : la source des logs, la connexion API locale, les autorisations et l'affectation au Bouncer doivent être cohérentes. En particulier lorsque plusieurs services sont impliqués, il convient de vérifier si le composant de correction se trouve bien en amont du service dont il est censé bloquer les accès en vertu d’une décision.

Il convient de distinguer les correspondances de scénario locales de la fonction optionnelle Liste noire de la communauté. Dans le cadre d'une participation volontaire, il est possible de fournir des signaux et d'obtenir des décisions validées concernant des attaquants déjà connus. Il s'agit d'une source préventive supplémentaire, mais qui ne remplace pas la détection locale et ne garantit pas la détection d'attaquants nouveaux ou discrets. L’origine d’une décision de blocage doit donc rester traçable au sein de l’entreprise.

Comparer les outils en fonction de leur utilisation

Le choix entre CrowdSec et Fail2Ban repose avant tout sur l'aspect de la protection, et non sur un jugement général de qualité. Fail2Ban analyse les lignes de journal à l'aide de filtres et les associe à des actions dans des « jails ». CrowdSec traite les sources de journaux à l'aide d'analyseurs syntaxiques et de scénarios pour générer des alertes ; l'API locale peut alors, à partir de celles-ci et à l'aide de profils, générer des décisions qui sont mises en œuvre par des composants de correction distincts. Les deux solutions reposent sur des événements correctement enregistrés.

Ce tableau n'est pas un classement. Pour quelques modèles de journaux bien compris, il est souvent plus facile d'analyser une « jail » locale : la source du journal, le filtre et l'action du pare-feu sont proches les uns des autres. Dès que plusieurs sources, des systèmes en amont ou différents points d’application sont impliqués, la séparation entre la détection et la réaction dans CrowdSec peut s’avérer judicieuse. Elle exige toutefois que les relations entre les composants soient gérées de manière transparente.

En matière de protection Web, l'aspect technique est déterminant. Un « Bouncer » CrowdSec applique des décisions au niveau du réseau, mais n'analyse pas le contenu HTTP. Dans le cadre d’une configuration AppSec prise en charge, un Bouncer adapté transmet les requêtes HTTP au composant AppSec du moteur de sécurité ; c’est là que les règles AppSec sont évaluées. Ce contrôle vient compléter le développement sécurisé et les mises à jour rapides, plutôt que de corriger les vulnérabilités connues.

Cas pratique : VPS individuel avec SSH

Sur un petit VPS Linux équipé de SSH et d'une pile web simple, Fail2Ban constitue souvent un choix facile à maîtriser. Commencez par vérifier si les tentatives de connexion SSH infructueuses, accompagnées de l'horodatage et de l'adresse IP source, apparaissent bien dans le fichier de journal prévu à cet effet. Sans ces données, une « jail » ne peut ni compter de manière fiable les tentatives infructueuses, ni transmettre la bonne adresse à une action.

Ensuite, tu choisis une « SSH-Jail » adaptée et tu vérifies que les filtres, les plages horaires, le nombre de tentatives autorisées et la durée de blocage correspondent bien à ta réalité en matière de connexion. Une « jail » associe un filtre à une ou plusieurs actions. Cela permet, par exemple, de déléguer le blocage au pare-feu local sans dupliquer la logique de détection. Pour un hôte unique, cette association rend généralement le processus transparent.

Les réseaux d'administration, les accès d'urgence et les systèmes de surveillance nécessitent des exceptions clairement définies. Celles-ci doivent être strictement limitées et ne pas exempter de manière générale les grands réseaux de fournisseurs d'accès. Vérifiez également, avant le déploiement, quelles règles de pare-feu l'opération crée réellement et si les adresses IPv4 et IPv6 sont compatibles avec l'architecture du serveur. Un démarrage contrôlé, accompagné d’une surveillance des journaux, est plus sûr qu’un blocage immédiat et de longue durée.

Propres Filtre Regex ne sont utiles que lorsqu'aucun filtre existant ne couvre le format de journal concerné. Le guide disponible pour le développement de filtres est répertorié comme documentation de Fail2Ban 0.9.0.dev et ne correspond donc à aucune version stable telle que la 1.1.1. Ses conseils de développement n'en restent pas moins pratiques : testez les nouveaux modèles à l'aide de lignes d'exemple réelles anonymisées et de lignes similaires mais légitimes. L'outil de test fail2ban-regex sert à valider le filtre ; il ne modifie pas le blocage de production.

Les paramètres locaux doivent être placés dans .local-fichiers, non inclus dans la livraison .conf-fichiers. Ainsi, les modifications apportées lors des mises à jour des paquets restent traçables et ne sont pas écrasées par inadvertance. Après chaque modification, tu vérifies séparément l'entrée du journal, l'état de la « jail » et l'action déclenchée ; un service en cours d'exécution ne constitue pas à lui seul une chaîne de verrouillage efficace.

Proxys, adresse IP réelle du client et protection Web

Un CDN, un équilibreur de charge ou un proxy inverse modifie l'adresse que voit le serveur. Si le serveur web ne reçoit que l'adresse IP du proxy et l'enregistre comme celle du client, un blocage basé sur les journaux peut, dans le pire des cas, cibler l'intermédiaire commun au lieu du visiteur malveillant. Avant toute mise en place d’une « jail », de tout scénario ou de toute règle WAF, il faut donc déterminer comment l’adresse IP d’origine du client sera transmise, acceptée et enregistrée de manière fiable.

Cette chaîne de confiance ne doit pas simplement reprendre n'importe quel en-tête entrant. Seules les adresses proxy connues doivent être autorisées à fournir une adresse transmise ; sinon, des clients externes pourraient falsifier l'identité sur laquelle reposent la détection et le blocage. Vérifiez, à l’aide d’extraits de journaux anonymisés, si les journaux d’application et d’accès indiquent la même adresse IP client. Documentez également la transmission des en-têtes entre le serveur périphérique et le serveur d’origine. Ce n’est qu’après vérification de l’adresse IP du client qu’une réaction aux événements HTTP suspects peut être interprétée de manière pertinente.

A Verrouillage IP limite les connexions au niveau du pare-feu avant qu’elles n’atteignent l’application, mais ne vérifie pas le contenu des requêtes. Dans le cadre d’une configuration CrowdSec AppSec prise en charge, un « Bouncer » adapté redirige les requêtes HTTP vers le composant AppSec du moteur de sécurité ; où les règles AppSec correspondantes sont vérifiées. En revanche, un « Bouncer » de type pare-feu pur applique les décisions au niveau du réseau et ne dispose d’aucune vérification HTTP. Le choix de la variante appropriée dépend du point d’entrée réel du trafic et des composants utilisés.

La détection basée sur les journaux reste en outre réactive : un événement doit d’abord se produire, être correctement consigné et identifié comme un modèle. Elle n’empêche pas une exploitation isolée réussie sans événement consécutif notable, et ne remplace pas non plus les correctifs ni une authentification forte. Les composants en amont doivent donc s'intégrer à l'architecture de sécurité globale grâce à leurs transmissions fiables, leurs journaux et leurs points de protection.

Concrètement, cela signifie : déterminez d'abord s'il faut protéger l'accès au réseau, les requêtes HTTP ou les deux niveaux. Documentez ensuite le parcours depuis l'adresse publique jusqu'à l'entrée du journal en passant par le proxy, puis testez les blocages à l'aide d'une adresse de test autorisée. Vous éviterez ainsi qu'une solution qui semble fonctionner Prévention des intrusions ne concerne que le composant d'infrastructure erroné.

Sécuriser plusieurs serveurs de manière contrôlée

Dès qu'il y a plusieurs hôtes, conteneurs ou journaux centralisés en jeu, la séparation entre la détection et l'application des mesures correctives devient pratique avec CrowdSec. Le moteur de sécurité peut analyser les événements provenant de sources définies, tandis que les composants de correction appropriés mettent en œuvre les décisions au niveau des points protégés concernés. CrowdSec documente également les déploiements distribués et l'intégration aux côtés de pipelines de journaux centralisés.

Cela ne réduit pas automatiquement les coûts d'exploitation. Il faut d’abord pouvoir déterminer, pour chaque source de journal, à quel service et à quel client elle est attribuée. Ensuite, chaque « bouncer » doit disposer d’une connexion clairement délimitée à l’API locale ainsi que de sa propre clé d’accès. Un « bouncer » de type proxy inverse ne protège par exemple pas nécessairement un service SSH accessible séparément ; la Affectation des videurs doit suivre les chemins de données réels.

La surveillance doit donc inclure la gestion des jetons, l'accessibilité de l'API, les journaux d'exécution et d'erreurs, ainsi que la vérification de l'efficacité du blocage. Une décision n'est qu'un résultat de détection jusqu'à ce que le composant prévu la récupère et l'applique. En cas de modifications apportées aux conteneurs, aux proxys ou aux règles de pare-feu, cette chaîne doit être réexaminée afin qu’une détection fonctionnelle ne passe pas inaperçue sans entraîner de réaction efficace.

Si des chaînes et des règles propres existent déjà, le Firewall-Bouncer peut, dans le Mode « Set-only » gérer exclusivement des ensembles créés au préalable. La responsabilité des règles et des chaînes incombe alors délibérément à l'opérateur. Cela s'inscrit dans le cadre de concepts de pare-feu contrôlés et d'exigences de conformité, mais nécessite une bonne compréhension de l'ordre des règles existantes et ne constitue pas une simplification pour les débutants.

Vérifier systématiquement les erreurs courantes

En l'absence de blocage, il vaut mieux suivre un ordre de vérification bien défini plutôt que de changer d'outil à la hâte. Il faut d’abord vérifier si l’événement attendu est bien reçu avec des horodatages plausibles. Ensuite, il faut s’assurer que l’adresse enregistrée correspond bien à l’adresse IP du client. Ce n’est qu’alors qu’il est possible de vérifier de manière pertinente si le filtre ou le scénario reconnaît le modèle et si cela donne lieu à une décision de blocage.

Avec Fail2Ban, l'entrée dans le journal est suivie de la vérification de la « jail », du filtre et du compteur de correspondances. Une « jail » associe un filtre à une ou plusieurs actions ; dans le cas de chemins de journaux basés sur des fichiers, seuls les fichiers existants correspondant au modèle « glob » sont pris en compte au démarrage. Pour les journaux systemd, le backend et les droits d'accès doivent être vérifiés séparément. Une « jail » qui semble correcte n'offre aucune protection si elle ne lit pas la source réelle.

Les expressions régulières personnalisées nécessitent une attention particulière. Le guide des filtres disponible est présenté comme une documentation de développement pour Fail2Ban 0.9.0.dev et ne doit pas être considéré comme une référence valable pour la version 1.1.1 de Fail2Ban. Ses recommandations restent toutefois utiles pour le développement de vos propres filtres : testez d'abord les modèles avec des lignes d'exemple anonymisées et représentatives, ainsi qu'avec des lignes délibérément non conformes. Cela permet de détecter les variantes de format des journaux et les éventuelles erreurs de classification avant qu'un blocage ne soit appliqué en production.

Avec CrowdSec, lorsqu’un scénario est déclenché, il faut également vérifier l’ensemble de la chaîne d’application : lorsqu’une alerte est générée, l’API locale peut-elle, à partir de celle-ci et à l’aide d’un profil, générer une décision, et celle-ci parvient-elle au composant de correction prévu ? Sans Bouncer correctement connecté, la décision reste sans effet, sans blocage actif. Il faut ensuite vérifier l'efficacité du pare-feu ou du proxy au point d'entrée approprié, sans se bloquer l'accès depuis son propre compte administrateur.

Exploiter la solution adaptée à long terme

Fail2Ban convient souvent à un serveur unique présentant des modèles de journaux locaux bien définis, tels que des tentatives SSH infructueuses répétées. Ses « jails », ses filtres et ses actions peuvent être directement associés à un service bien délimité. CrowdSec devient plus intéressant lorsqu'il s'agit de coordonner plusieurs sources de journaux, différents points d'application ou la protection Web à l'aide d'un composant adapté. Ce qui est déterminant, c'est le parcours vérifiable des données, et non un jugement général sur l'outil le plus moderne.

Ces deux solutions nécessitent un processus de modification bien défini : gérer les versions des configurations, tester au préalable les nouveaux filtres ou scénarios à l'aide d'exemples de journaux connus et surveiller les blocages. Les mises à jour méritent la même attention. Fail2Ban 1.1.1 a été publié le 15 août 2026. Les adaptations locales et les actions de pare-feu effectivement mises en œuvre doivent être comparées à l'environnement cible avant toute mise à jour.

Prévention des intrusions Cela vient compléter les mesures de sécurité de base, mais ne les remplace pas : des mises à jour régulières, une authentification forte et, dans la mesure du possible, à plusieurs niveaux, des règles de pare-feu restrictives, des sauvegardes et la surveillance des journaux restent indispensables. Dans les environnements d'hébergement en particulier, il convient également de veiller à la durée de fonctionnement des applications. L'article sur CloudLinux Alt-PHP et ses aspects liés à la sécurité montre pourquoi des versions d'exécution distinctes et bien entretenues font partie intégrante d'un modèle d'exploitation résilient.

Pour les services Web, le chemin complet, du client à l'origine en passant par le CDN ou le proxy inverse, doit également figurer dans la documentation d'exploitation. Les modifications apportées aux protocoles et aux voies de distribution peuvent influencer le composant qui accepte les connexions et l'adresse qui apparaît dans le journal. L'article sur HTTP/2 Server Push dans l'hébergement explique, à l'aide d'exemples, comment le navigateur, le CDN et le serveur web interagissent lors de la diffusion du contenu. Indépendamment de cela, il reste essentiel, pour la logique de blocage, que l'adresse IP du client, transmise de manière fiable, soit disponible au point de protection approprié.

Ce choix à long terme doit rester vérifiable : si les formats de journaux, les chemins de proxy, les services ou le nombre de serveurs changent, un concept qui convenait auparavant peut présenter des lacunes. Notez donc quels événements doivent être détectés, où les décisions sont mises en œuvre et qui valide les exceptions. Ces discipline au travail transforme un blocage d'adresse IP en une mesure de protection contrôlable, plutôt qu'en une modification du pare-feu effectuée à l'insu de l'utilisateur.