Alternatives à Fail2Ban pour les serveurs Linux modernes

Vérifier la surface d'attaque avant de choisir l'outil

A Alternative à Fail2Ban ne peut être sélectionné de manière pertinente que lorsque les services réellement accessibles sont connus. SSH, SMTP, IMAP et une application HTTP présentent des procédures de connexion, des sources de journaux et des types de dommages différents. En revanche, un service de base de données accessible au public ne devrait en principe pas devoir être protégé par une liste de blocage Internet : son accès réseau doit être limité aux applications nécessaires et aux réseaux de confiance.

Dans le cas des admissions administratives, Restriction d'accès et une authentification forte prime sur les blocages d'adresses IP automatisés. Un service SSH derrière un VPN, un hôte bastion ou des réseaux d’administration dédiés offre aux attaquants une surface d’attaque nettement plus réduite qu’un port ouvert au monde entier. Des mises à jour de sécurité régulières, des comptes privilégiés séparés et une politique de mot de passe soigneusement équilibrée réduisent les risques qu’une liste de blocage à elle seule ne peut éliminer.

Si SSH est sciemment accessible au public, les limites et les blocages basés sur les journaux peuvent limiter les tentatives répétées de mot de passe. Elles restent toutefois un complément : les personnes se trouvant derrière une passerelle NAT commune peuvent utiliser la même adresse source, tandis que les attaques distribuées utilisent de nombreuses adresses. Pour les services de messagerie, il importe également de déterminer quels protocoles sont effectivement accessibles aux utilisateurs externes et quelles tentatives de connexion infructueuses sont consignées.

Dans le cas des applications web, il convient de faire la distinction entre l'accessibilité du proxy inverse et celle des services backend internes. Un serveur Nginx public peut accepter des requêtes HTTP sans que la base de données, le cache ou l'interface d'administration ne soient accessibles depuis Internet. Le Objectif de protection Il ne s'agit donc pas de „ bloquer les adresses IP “ de manière générale, mais de limiter les accès non autorisés pour chaque service, de préserver l'utilisation légitime et d'éviter les autorisations inutiles.

Avant toute modification, les responsables doivent recenser les voies d'accès nécessaires en cas d'urgence et les réseaux sources qui accèdent régulièrement au système. Cet état des lieux permet d'éviter qu'une règle de pare-feu trop restrictive ne bloque l'accès de l'administrateur ou la maintenance automatisée. Ce n’est qu’ensuite qu’il est possible de déterminer si l’analyse des journaux, la limitation des connexions ou une approche à plusieurs niveaux est la solution la plus appropriée.

De plus, un blocage ne répond pas à la question de savoir si un service doit nécessairement être public. Inverser cet ordre revient à traiter les connexions suspectes, alors que l'exposition fondamentale reste inchangée. En particulier pour les interfaces administratives rarement utilisées, un accès privé s’avère souvent plus efficace et plus simple à gérer que des règles de détection de plus en plus complexes.

Quatre approches au lieu d'une alternative à Fail2Ban

Au lieu de chercher une solution de remplacement unique, il vaut mieux distinguer la détection de la réaction. CrowdSec traite des sources de journaux configurables à l'aide de parseurs et de scénarios afin d'évaluer des séquences d'événements et de générer des décisions. Le moteur de sécurité n'applique pas lui-même ces décisions ; pour cela, un composant de correction distinct doit être connecté et opérationnel.

Cette répartition est adaptée lorsque la même détection doit s'appliquer à différents endroits. Un composant de pare-feu peut appliquer des règles aux connexions réseau, tandis que les composants destinés aux serveurs web ou aux proxys inversés interviennent sur le trafic HTTP. Cela implique toutefois des exigences accrues : la collecte des journaux, les analyseurs syntaxiques, l'API locale, les autorisations et la mise en œuvre concrète doivent être planifiées comme une chaîne cohérente.

SSHGuard est destiné à des cas plus spécifiques. Cet outil agrège les journaux système et peut bloquer, via des pare-feu, les sources qui se font remarquer de manière répétée ; il est notamment conçu pour contrer les attaques par force brute visant SSH et d'autres services. Il est donc plus adapté au traitement d'erreurs d'authentification identifiables qu'à une analyse exhaustive des requêtes Web.

Natives Limitation du débit avec nftables adopte une approche différente. Les ensembles dynamiques et les compteurs peuvent limiter les nouvelles connexions TCP par adresse source et gérer les entrées ayant dépassé le délai d’attente. Cela ralentit les séries de connexions rapides avant l’authentification, ne nécessite pas de parseur de journaux et ne permet pas non plus de déterminer si une connexion a échoué ou si une requête HTTP était malveillante.

Le sens de la règle est ici important : nftables fait la distinction entre les règles qui acceptent le trafic jusqu'à un certain débit et les expressions contenant over, qui rejettent le trafic dépassant un certain débit. Une limite doit donc être adaptée au service, au comportement attendu des utilisateurs et aux adresses sources partagées. Il ne s'agit pas d'une classification fiable de chaque identité suspecte.

Pour un serveur unique proposant un nombre restreint de services bien définis, une protection minimaliste des journaux ou une limitation modérée du nombre de connexions peut suffire. La présence de plusieurs hôtes, de sources de journaux centralisées ou la nécessité de disposer de différents points d'application plaident plutôt en faveur d'une architecture modulaire. Aucune de ces options ne remplace les correctifs, une authentification forte ou un partage de réseau restrictif.

Le choix d'une alternative appropriée à Fail2Ban dépend donc des signaux disponibles et de l'endroit où une réaction doit avoir lieu. Les modèles de journaux sont utiles pour les erreurs de connexion répétées ; les règles de paquets limitent la fréquence des connexions. Ces deux méthodes ne détectent que ce pour quoi leur source de données et leurs règles ont été conçues.

Séparer clairement le pare-feu et la protection HTTP

Un serveur Nginx ou un proxy inverse relie deux niveaux de protection qu'il ne faut pas confondre. Un pare-feu bloque ou autorise les connexions provenant d’une adresse source et peut ainsi concerner à la fois SSH, SMTP ou l’accès Web. Il n’évalue toutefois pas chaque chemin HTTP, en-tête ou contenu de requête ; ces informations relèvent du niveau applicatif.

Chez CrowdSec, il y a Détection et application des tâches distinctes. Le Log Processor analyse les données de journaux et les requêtes HTTP provenant de serveurs Web compatibles. AppSec fait partie de ce Log Processor et filtre ces requêtes HTTP. Les Remediation Components, quant à elles, sont chargées de mettre en œuvre les décisions au niveau sélectionné, par exemple au niveau d'un pare-feu, d'un serveur Web ou d'un proxy inverse.

Pour se protéger contre les injections SQL, le cross-site scripting ou tout autre contenu de requête malveillant, un simple composant de pare-feu ne suffit donc pas. Il faut disposer d'une connexion compatible au serveur web ainsi que d'une configuration AppSec adaptée, dotée de règles appropriées. La remédiation doit rester techniquement distincte de cela : elle met en œuvre les décisions au niveau du point d'application sélectionné.

Ces deux niveaux peuvent être utiles en parallèle. Un blocage à l'échelle du réseau limite le trafic supplémentaire provenant d'une source, tandis qu'un Vérification HTTP évalue et filtre les requêtes provenant de serveurs web compatibles avec AppSec. Cela ne signifie pas pour autant qu’un blocage d’adresse IP protège automatiquement contre les injections SQL ou le cross-site scripting : sans vérification des requêtes, le pare-feu ne détecte ni les paramètres ni les données utiles.

À l'inverse, les mesures basées sur la sécurité des applications (AppSec) et les adresses IP restent elles aussi limitées. Les tentatives lentes inférieures aux seuils définis, les nombreuses adresses source changeantes ou les utilisateurs légitimes se trouvant derrière la même adresse NAT compliquent la prise de décision basée sur l'adresse IP source. Les règles doivent donc tenir compte des fausses alertes et ne pas considérer systématiquement l’accès aux formulaires normaux, aux API et aux intégrations automatisées comme une attaque.

Pour faciliter la planification, voici un bref aperçu : La Au niveau du pare-feu contrôle le trafic réseau en fonction des adresses, des ports et des caractéristiques de connexion. AppSec traite et filtre les requêtes HTTP provenant de serveurs Web compatibles dans le cadre du Log Processor. Les composants de correction appliquent délibérément les décisions à un niveau choisi.

Un système web public nécessite en outre une séparation claire des responsabilités. Le proxy inverse ne doit accéder qu’aux backends nécessaires, et les points de terminaison administratifs ne doivent pas rester accessibles au public uniquement en raison de la présence d’un filtre en amont. Ainsi, la segmentation du réseau, l’authentification sécurisée et les règles ciblées se complètent, sans attribuer à une seule technique de blocage un effet de protection supérieur à ce qu’elle peut réellement offrir.

Comparaison pour des serveurs Linux types

On ne peut pas choisir judicieusement une alternative à Fail2Ban en se basant uniquement sur le nombre de blocages possibles. Ce qui est déterminant, ce sont les signaux analysés et l'endroit où la mesure est appliquée. CrowdSec sépare son moteur de sécurité du composant chargé d'appliquer les décisions au niveau du pare-feu, du proxy ou du serveur web. SSHGuard, quant à lui, analyse les journaux système à la recherche de tentatives d'attaque répétées ; nftables peut limiter les nouvelles connexions directement dans le chemin des paquets.

Ce tableau ne reflète pas un classement. Pour un service isolé présentant des tentatives de connexion manifestement infructueuses, une analyse simplifiée des journaux n'a rien à voir avec une limite visant à empêcher les tempêtes de connexions. Pour un proxy inverse, il faut également tenir compte du fait que les requêtes HTTP doivent être filtrées par AppSec sur une connexion compatible. Le point d'application doit correspondre à l'objet à protéger : une règle de pare-feu n'évalue pas le contenu des requêtes, tandis que les composants de correction appliquent des décisions au niveau sélectionné.

La gestion centralisée n'est pas non plus une fin en soi. Elle permet d'harmoniser les décisions et l'analyse des journaux sur plusieurs hôtes, mais nécessite un concept d'accès et de gestion des pannes robuste. Pour un petit serveur isolé, cette architecture supplémentaire peut, dans certains cas, entraîner davantage de travail de maintenance que de gains en matière de sécurité. À l’inverse, des services identiques hébergés sur plusieurs serveurs peuvent tirer profit d’une installation centrale de CrowdSec soigneusement planifiée.

Vérifier et classer la configuration en toute sécurité

Avant l'activation, il faut d'abord déterminer quels messages parviennent effectivement au service. Dans le cas d'une solution basée sur les journaux, vérifiez la source des journaux, l'analyseur syntaxique et le format précis des événements SSH, de messagerie ou de proxy. Avec CrowdSec, la simple détection d'une activité ne suffit pas : un composant de remédiation enregistré et accessible doit transmettre les décisions à la connexion prévue au pare-feu ou au proxy.

Les commandes suivantes permettent uniquement d'effectuer des vérifications en lecture seule sur un système Linux, sur lequel les outils correspondants peuvent déjà être installés. Elles ne modifient aucune règle et n'installent aucun paquet. Elles permettent de consulter l'ensemble actuel des règles, les composants CrowdSec enregistrés et les paquets candidats disponibles pour Debian ou Ubuntu.

nft list ruleset
sudo cscli bouncers list
apt-cache policy crowdsec

La sortie ne garantit pas encore de protection. Vérifiez dans nftables si la chaîne d'entrée concernée dispose du hook attendu et de la politique par défaut appropriée, et si des règles sont prévues pour les connexions existantes, le loopback, IPv4 et IPv6, ainsi que pour le port de service réel. Un composant enregistré peut également être configuré pour un point d'application incorrect. Même un paquet candidat visible ne permet pas de déterminer si sa version, sa configuration et son analyseur syntaxique correspondent à la distribution et à votre propre service.

Les seuils, les durées de blocage et les exceptions ne doivent pas être repris tels quels dans l'environnement de production à partir d'exemples sans avoir été vérifiés. En particulier, les adresses NAT partagées, les accès mobiles et les tâches automatisées peuvent sinon entraîner des fausses alertes. Pour l'analyse des événements réseau et du comportement du système, il est possible d'utiliser en complément Suivi eBPF pour la surveillance sous Linux aider ; toutefois, cela ne remplace ni la vérification de la chaîne de journalisation, ni la décision technique concernant un blocage.

Un choix adapté à quatre scénarios d'exploitation

Un VPS isolé disposant d'un accès SSH accessible depuis le monde entier présente des besoins de protection bien définis. SSHGuard peut signaler à un pare-feu backend les tentatives infructueuses répétées, identifiables dans les journaux correspondants. Une limite nftables modérée peut également limiter les nouvelles connexions, mais ne prend pas en compte les erreurs de connexion. La priorité est donnée aux voies d'administration restreintes et à une authentification forte ; le blocage d'adresse IP reste une mesure complémentaire.

Sur un serveur de messagerie, les protocoles SMTP, IMAP et Submission suivent des chemins d'authentification et de journalisation différents. Une réaction allégée basée sur les journaux n'a de sens que si les messages pertinents sont intégralement enregistrés. CrowdSec devient une option lorsque les décisions ou l'analyse des journaux doivent être centralisées sur plusieurs systèmes. Sans ce besoin, l'architecture centralisée serait disproportionnée par rapport à une solution locale clairement délimitée.

Pour Nginx ou Traefik placés en amont d'une application web, un outil exclusivement axé sur SSH ne suffit pas. C'est là qu'intervient une protection à plusieurs niveaux Accès réseau issus des contrôles HTTP : CrowdSec AppSec fait partie du Log Processor et peut filtrer les requêtes provenant de serveurs Web compatibles. Les composants de correction (Remediation Components), quant à eux, appliquent les décisions au niveau sélectionné, par exemple au niveau du serveur Web ou du proxy inverse. Ces deux tâches doivent être correctement intégrées et vérifiées séparément.

Une petite flotte utilisant des journaux centralisés ou Kubernetes peut tirer parti d'une API locale centralisée ou de journaux centralisés. Cela ne simplifie pas automatiquement l'exploitation : les autorisations, l'accessibilité des interfaces, la segmentation et la défaillance d'un composant central doivent être prises en compte. Les aspects liés au traitement des paquets et à la répartition de charge dans les grands réseaux Linux sont également abordés dans l'article consacré à Receive Side Scaling dans les réseaux de serveurs Linux. Pour un petit nombre d'hôtes ne partageant pas de processus d'exploitation commun, une solution locale reste souvent plus facile à comprendre.

Surveiller la logique de verrouillage pendant le fonctionnement

Une logique de blocage n'est compréhensible que si l'on contrôle séparément trois étapes : la réception des données de journalisation, la décision qui en découle et sa mise en œuvre technique. Dans CrowdSec, le moteur de sécurité lit les sources de journaux configurées et génère des décisions à l'aide d'analyseurs syntaxiques et de scénarios ; toutefois, le blocage proprement dit est pris en charge par un composant de remédiation distinct.

Vérifiez d'abord si les messages attendus parviennent effectivement. Pour un service SSH, ce sont les tentatives de connexion infructueuses qui sont pertinentes ; pour un serveur de messagerie, ce sont les protocoles d'authentification correspondants ; et pour un proxy, ce sont ses journaux d'accès ou de sécurité. Les événements visibles ne suffisent pas à eux seuls à prouver l'efficacité d'une défense : seule la chaîne comprenant la réception du journal, la séquence détectée, la décision et la règle effective permet d'établir un diagnostic fiable.

Vérifiez ensuite séparément les décisions et le composant enregistré. Si CrowdSec détecte des événements suspects, mais qu’aucun composant de correction n’est connecté ou opérationnel, les décisions restent sans effet. La documentation officielle relative aux erreurs identifie précisément ce scénario comme la cause pour laquelle le moteur de sécurité fonctionne, mais qu’aucun blocage n’a lieu. La détection n'est pas un blocage.

La protection Web s'accompagne d'un contrôle supplémentaire. AppSec fait partie du Log Processor et filtre les requêtes HTTP provenant de serveurs Web compatibles. Les composants de correction appliquent les décisions au niveau sélectionné, par exemple au niveau du serveur Web ou du proxy inverse. En fonctionnement, il doit donc rester possible de déterminer si un rejet résulte de la vérification HTTP ou d’une décision déjà appliquée, afin de pouvoir analyser de manière ciblée les erreurs et les fausses alertes.

Les fausses alertes ont des conséquences particulièrement graves lorsque de nombreuses personnes autorisées utilisent la même adresse publique. Les passerelles NAT, les réseaux mobiles et les systèmes d'identification (CI) peuvent regrouper de nombreuses tentatives de connexion légitimes sous une seule adresse IP source. Choisis donc les seuils, les durées de blocage et les exceptions en fonction des voies d’accès réelles, et veille à ce que les décisions, ainsi que leur motif et leur durée, soient traçables, au lieu de considérer une longue liste de blocage comme un succès.

Testez d'abord les modifications à l'aide de journaux historiques anonymisés ou dans un environnement de test. Cela permet de vérifier si les analyseurs syntaxiques détectent les modèles prévus et si la correction réagit au niveau attendu, sans compromettre les accès administratifs. SSHGuard traite les journaux système et peut interagir avec différents backends de pare-feu ; c'est pourquoi la source des journaux et le backend doivent être considérés conjointement dans l'environnement installé.

Un scénario contrôlé ne remplace pas un test d'attaque sur le système de production. Documentez les événements attendus, les décisions observées et l’effet des règles qui en résulte ; supprimez ensuite les données de test ou laissez les entrées à durée limitée expirer normalement. Ainsi, l’efficacité de la protection et les éventuels dommages collatéraux restent vérifiables, sans déclencher intentionnellement de véritables blocages pour les utilisateurs en production.

Dépannage des journaux et des règles

Commencez toujours le dépannage par la source du journal, puis remontez jusqu'à l'application. En l'absence de messages pertinents, ni un analyseur de journaux, ni une logique de scénario ou de blocage ne peuvent réagir de manière fiable. Vérifie donc le service, le lecteur de journaux et le format réel avant de modifier les seuils ou de soupçonner les règles du pare-feu.

Avec CrowdSec, le scénario d'erreur est clair lorsque des événements ou des décisions sont visibles, mais que les accès restent possibles : une décision n'est pas automatiquement appliquée par le moteur. Vérifiez si un composant de correction approprié est enregistré, accessible et effectivement connecté au pare-feu, au serveur web ou au proxy. Sans ce composant, aucune règle de blocage n'est appliquée.

Avec SSHGuard, la cause se situe souvent en amont. L'outil agrège les journaux système, mais un lecteur de journaux inadapté ou un format de service s'écartant du modèle attendu ne fournit aucun résultat exploitable. La configuration d'exemple disponible dans le référentiel présente des entrées et des options possibles, mais provient de la branche de développement ; vérifiez-la par rapport à la documentation du paquet et à la version installée, au lieu de la reprendre telle quelle.

Avec nftables, tu vérifies en outre si la règle se trouve dans la chaîne concernée, au niveau du hook attendu, si elle couvre le port de service réel et si elle s'applique aux familles de protocoles requises. L'exemple de jeu de règles sépare IPv4 et IPv6 via des chaînes distinctes, autorise les connexions établies ainsi que les connexions associées et le trafic de bouclage avant les ouvertures de ports. Une protection formulée exclusivement pour IPv4 ne couvre pas IPv6 ; de même, un taux trop restrictif peut affecter les connexions parallèles autorisées.

« Ein Meter » limite les nouvelles connexions en fonction d'un débit défini par source et peut gérer des entrées de jeu dynamiques avec un délai d'expiration. Cela ne prend toutefois pas en compte les tentatives de connexion infructueuses. Si une attaque reste en dessous du débit, l'absence de détection n'est donc pas nécessairement due à un défaut de la règle, mais peut relever d'une limite inhérente à l'approche choisie. Crochet, chaîne et point de mesure doivent correspondre à l'effet escompté.

Effectuez les modifications une par une et vérifiez à chaque étape l'entrée du journal, la décision et l'application. Avant de modifier le pare-feu, assurez-vous de disposer d'un accès d'urgence indépendant, par exemple via une console, un hôte bastion ou un réseau d'administration séparé. Cela évite qu'une règle mal placée ou un ajout IPv6 erroné ne coupe le seul accès au serveur.

Décision en fonction du risque et de l'effort requis

Le choix d'une alternative appropriée à Fail2Ban dépend de la surface d'attaque exposée, et non d'un classement général. Déterminez quels services sont accessibles au public, s'ils traitent des connexions, quels journaux sont disponibles de manière fiable et qui gère la configuration en permanence. Un service de base de données non accessible au public n'a pas besoin d'une liste de blocage Internet ; son accès réseau reste la décision de sécurité la plus importante.

Pour un serveur unique de taille raisonnable présentant des erreurs répétées de connexion SSH ou de messagerie, SSHGuard peut constituer une approche allégée basée sur les journaux. Ce projet vise à protéger contre les attaques par force brute visant SSH et d'autres services, et utilise pour cela les journaux système ainsi que les backends de pare-feu. La couverture concrète des journaux et les paramètres de blocage doivent toutefois être adaptés à la distribution installée et au format du service.

Si l'objectif est avant tout de limiter les nouvelles connexions rapides, une limitation de débit modérée via nftables constitue un complément direct. Les compteurs peuvent limiter le nombre de connexions par adresse source ; les règles avec over Rejeter le trafic dépassant le seuil défini. Cette opération a lieu avant la connexion, mais ne fournit aucune indication sémantique permettant de déterminer si une connexion a échoué ou si une requête HTTP était malveillante.

CrowdSec est la solution idéale lorsque l'analyse des journaux et l'application des règles doivent être coordonnées à plusieurs niveaux ou sur plusieurs hôtes. Son architecture sépare le moteur des composants de correction ; des variantes distribuées avec une API locale centralisée ou des journaux centralisés sont possibles. Cet avantage s'accompagne d'exigences supplémentaires en matière d'autorisations, d'accessibilité, de segmentation et de plan de secours en cas de panne. Opérationnalité C'est donc un critère de sélection qui s'ajoute à l'éventail des fonctionnalités.

Dans le cas des applications Web publiques, un blocage par pare-feu ne suffit pas pour évaluer chaque requête HTTP. Il faut pour cela une intégration AppSec compatible, dotée de règles adaptées. AppSec fait partie du Log Processor et filtre les requêtes HTTP provenant de serveurs Web compatibles ; les composants de correction appliquent les décisions au point d'application sélectionné. Le facteur déterminant est de savoir si le besoin de protection concerne les connexions, les événements d'authentification ou le contenu HTTP.

Les mesures basées sur l'adresse IP restent limitées : les botnets répartissent leurs tentatives sur de nombreuses sources, les attaques lentes peuvent rester en dessous d'un certain seuil, et les adresses partagées affectent des personnes non impliquées en cas de blocage. Elles réduisent le bruit généré par les automatisations, mais ne remplacent pas les correctifs appliqués en temps opportun, les accès administratifs restreints et l’authentification forte. En particulier pour SSH, la connexion par clé et l’accessibilité limitée priment sur des seuils de blocage de plus en plus agressifs.