fail2ban vs CrowdSec vs protection kernel : quelle solution de ban IP en 2026 ?

Le ban IP est l'un des outils les plus classiques pour protéger un serveur Linux contre les attaques par force brute, le scanning de ports ou les tentatives d'accès non autorisées. En 2026, trois grandes approches se distinguent : fail2ban, historique et répandu ; CrowdSec, moderne et communautaire ; et les solutions kernel-level (XDP/eBPF + nftables), qui offrent une réactivité sub-microseconde et une intégration directe au cœur du réseau. Ce comparatif technique explore les forces, limites et cas d'usage de chacune, avec un focus sur les environnements critiques où latence et débit sont essentiels.

fail2ban : la référence historique pour le ban IP automatisé

fail2ban est un démon Python qui surveille les logs systèmes (SSH, Nginx, Apache, Postfix…), détecte des patterns d'attaque par expressions régulières, puis bannit automatiquement les adresses IP malveillantes via iptables ou nftables. Stable depuis 2004, fail2ban reste le choix par défaut pour de nombreux administrateurs Linux.

Architecture et fonctionnement

fail2ban repose sur trois composants principaux :

• Jails : définissent les services surveillés (sshd, postfix, nginx…), les filtres regex associés et le nombre de tentatives tolérées.
• Filtres : expressions régulières appliquées aux logs pour détecter échecs d'authentification, scans, erreurs 401/403…
• Actions : commandes exécutées lors du ban, par défaut via iptables -I INPUT -s <IP> -j DROP ou nft insert rule inet filter input ip saddr <IP> drop.

Configuration typique pour SSH :

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600

Dès que 5 échecs SSH sont détectés en 10 minutes, fail2ban insère une règle de drop dans le firewall. L'IP est débannie après 1 heure (bantime).

Points forts

• Compatibilité universelle : fonctionne avec iptables, nftables, PF (FreeBSD), ipfw. S'intègre à tous les services Linux générant des logs structurés.
• Écosystème mature : centaines de filtres prêts à l'emploi (Apache, Dovecot, vsftpd, Asterisk…).
• Flexibilité : actions personnalisables (envoi d'email, webhook, scripts shell).
• Léger : consommation CPU et RAM négligeables en mode standard.

Limites techniques

• Réactivité : délai entre l'attaque et le ban (quelques secondes), car fail2ban lit les logs a posteriori. Un attaquant peut envoyer des milliers de paquets avant d'être bloqué.
• Dépendance aux logs : si un service ne log pas (UDP spoofé, SYN flood massif), fail2ban est aveugle.
• Scalabilité iptables : avec des milliers d'IP bannies, iptables linéaire (parcours séquentiel) dégrade les performances. nftables améliore ce point avec des sets, mais fail2ban par défaut insère des règles individuelles.
• Pas de protection DDoS volumétrique : fail2ban ne traite que les logs applicatifs. Un flood UDP ou SYN flood saturera le serveur avant que fail2ban ne réagisse.

Pour optimiser fail2ban avec nftables, il est possible de forcer l'usage de sets :

nft add set inet filter fail2ban_blacklist { type ipv4_addr \; flags timeout \; }
nft add rule inet filter input ip saddr @fail2ban_blacklist drop

Puis configurer fail2ban pour ajouter/supprimer des IPs dans ce set au lieu d'insérer des règles individuelles.

CrowdSec : l'approche collaborative du ban IP

CrowdSec (2020) se positionne comme l'évolution moderne de fail2ban : même logique (lecture de logs, détection d'attaques, ban IP), mais avec une dimension collaborative et une architecture agent-bouncer plus modulaire.

Architecture distribuée

CrowdSec sépare deux rôles :

• Agent (crowdsec-agent) : parse les logs via parsers et scenarios (équivalents des filtres fail2ban), détecte les attaques, stocke les décisions locales dans une base SQLite.
• Bouncers : exécutent les décisions de ban (iptables, nftables, HAProxy, Nginx, Cloudflare…). Un bouncer peut être déployé sur plusieurs machines pour mutualiser la protection.

Exemple de scenario CrowdSec détectant un scan SSH :

type: leaky
name: crowdsecurity/ssh-bf
filter: evt.Meta.log_type == 'ssh_failed-auth'
leakspeed: 10s
capacity: 5
blackhole: 4h

Dès 5 échecs SSH en 10 secondes, l'IP est bannie pour 4 heures. Le bouncer crowdsec-firewall-bouncer-nftables ajoute alors l'IP dans un set nftables.

Intelligence collective

La force de CrowdSec réside dans son CTI (Cyber Threat Intelligence) partagé :

• Les agents peuvent remonter anonymement les IPs bloquées vers la CrowdSec Central API.
• Chaque agent peut télécharger les blocklists communautaires (IPs signalées par d'autres instances CrowdSec dans le monde), classées par confiance (IP Reputation Score).
• Résultat : votre serveur bénéficie de millions de signalements avant même d'être attaqué. Une IP ayant scanné 10 000 serveurs CrowdSec la semaine dernière sera pré-bannie chez vous.

Activation des blocklists :

cscli collections install crowdsecurity/sshd
cscli decisions list
cscli bouncers add nftables-bouncer

Points forts

• Proactivité : ban d'IPs malveillantes avant qu'elles n'attaquent votre infrastructure.
• Modularité : parsers/scenarios communautaires (Hub CrowdSec), bouncers pour de nombreux points d'entrée (firewall, reverse proxy, CDN).
• Performance nftables : CrowdSec utilise nativement les sets nftables, évitant la dégradation linéaire d'iptables.
• Dashboard intégré : CrowdSec Console (SaaS) offre une visualisation des attaques, alertes temps réel, gestion centralisée multi-serveurs.

Limites

• Complexité accrue : architecture agent-bouncer plus verbeuse que fail2ban. Configuration de scénarios YAML, gestion des collections, API keys pour la Console.
• Latence identique à fail2ban : CrowdSec reste dépendant des logs. Délai de plusieurs secondes entre l'attaque et le ban local (hors blocklists pré-chargées).
• Pas de protection kernel-level : comme fail2ban, CrowdSec bannit via iptables/nftables userland. Un flood volumétrique (plusieurs millions de pps) saturera le serveur avant que CrowdSec ne traite les logs.
• Dépendance cloud partielle : les blocklists les plus riches nécessitent un compte CrowdSec (gratuit jusqu'à 1 million de requêtes/mois, puis 49$/mois).

CrowdSec excelle pour protéger des services applicatifs (SSH, web, mail) contre les tentatives d'intrusion répétées, mais ne remplace pas une protection DDoS kernel.

Protection kernel-level : XDP/eBPF + nftables pour un ban IP sub-microseconde

Les solutions kernel-level traitent les paquets avant qu'ils n'atteignent la stack réseau Linux complète. XDP (eXpress Data Path) permet d'exécuter des programmes eBPF directement dans le driver réseau, décidant en quelques nanosecondes si un paquet doit être bloqué, relayé ou redirigé.

Pourquoi XDP change la donne pour le ban IP

Comparé à iptables/nftables (couche netfilter, post-routage IP), XDP intervient avant le kernel :

• Latence : traitement en <1 µs par paquet, contre ~10-50 µs pour netfilter.
• Débit : capacité de filtrer plusieurs millions de paquets par seconde sur une interface 10 Gbps, avec un CPU < 10%.
• Early drop : les paquets d'une IP blacklistée sont jetés avant même l'allocation de sk_buff (structure noyau coûteuse). Zéro charge CPU pour du trafic malveillant.

Exemple d'architecture PAKKT.io, plateforme SaaS gérant XDP + nftables :

• Programme XDP unique par interface (PAKKT Engine) chargé dans le driver.
• Jusqu'à 256 règles pilotées par BPF maps (hash map de règles lues par le programme XDP en temps réel, sans rechargement).
• Blacklist/Whitelist IP maintenues dans une map XDP + un set nftables synchronisé, offrant deux couches de défense.
• Firewall nftables stateful complémentaire (table isolée inet pakkt) pour rate-limit TCP/UDP par connexion, filtrage stateful (conntrack), validation TCP flags.

Chargement d'un programme XDP sur eth0 :

ip link set dev eth0 xdp obj pakkt_engine.bpf.o sec xdp

Ajout d'une IP blacklistée via BPF map :

bpftool map update name pakkt_blacklist key 192.0.2.123 value 1

La prochaine fois qu'un paquet de 192.0.2.123 arrive sur eth0, le driver appelle le programme XDP, qui lit la map, détecte le match et retourne XDP_DROP instantanément. Zéro log, zéro passage en userland.

Double couche XDP + nftables

Une architecture robuste combine XDP (stateless, vitesse maximale) et nftables (stateful, flexibilité) :

Couche	Rôle	Exemples d'usage
XDP (eBPF)	Blacklist/Whitelist IP, rate-limit global par port (pps), drop par taille de paquet, filtrage protocole (TCP/UDP/ICMP)	Bloquer une IP de botnet, limiter les requêtes UDP à 100 000 pps sur le port 19132, dropper les paquets < 64 bytes (attaque amplification)
nftables (netfilter)	Conntrack (état TCP NEW/ESTABLISHED), rate-limit par connexion, validation TCP flags (SYN flood), burst meter, logging sélectif	Accepter max 50 nouvelles connexions TCP/sec sur le port 25565, dropper les SYN sans ACK après 3 tentatives, logger les connexions suspectes

Exemple de règle nftables complémentaire (rate-limit par connexion) :

nft add rule inet pakkt input tcp dport 22 ct state new limit rate 10/minute accept

Cette règle accepte max 10 nouvelles connexions SSH par minute. Si un attaquant génère 1000 SYN/sec, XDP peut déjà limiter le débit global à 100 000 pps, puis nftables affine en limitant les nouvelles connexions établies. Les deux couches se complètent sans conflit.

Gestion centralisée : l'atout des plateformes SaaS

Déployer XDP/eBPF manuellement nécessite :

• Compiler le code eBPF (clang, libbpf).
• Gérer le cycle de vie (load, unload, mise à jour de maps).
• Synchroniser les règles nftables.
• Collecter les métriques (bpftool, exporter Prometheus).
• Maintenir la compatibilité noyau (5.x, 6.x, quirks par distro).

Les plateformes comme PAKKT.io automatisent l'intégralité du workflow :

• Agent Go léger : déploiement en 30 secondes, self-update automatique (SHA256), connexion mTLS au panel centralisé.
• Dashboard temps réel : métriques par port/règle (paquets bloqués, rate-limit atteint), GeoIP avec carte monde, top IPs sources, audit log des modifications.
• Blacklist/Whitelist synchronisées : ajout d'une IP dans le panel → push instantané vers la BPF map + set nftables de tous les agents concernés.
• Templates communautaires : marketplace de règles XDP/nft partagées (ex : protection Minecraft 1.20, rate-limit FiveM, filtrage GTA V).
• Intégrations : API publique (clé API), plugin Pterodactyl v1.x fonctionnel (Pelican/WHMCS à venir), webhooks pour automatisation (ex : ban IP depuis un script fail2ban ou CrowdSec, si vous souhaitez hybrider).

Déploiement PAKKT typique :

curl -sSL https://get.pakkt.io/install.sh | bash -s -- --token YOUR_TOKEN
# L'agent charge automatiquement le PAKKT Engine XDP, crée la table nftables isolée, se connecte au panel

Impact : < 1% CPU, < 5 MB RAM, zéro conflit avec Docker, fail2ban, iptables-persistent. La table inet pakkt est strictement isolée ; vos règles iptables/nftables existantes restent intactes.

Limites des solutions kernel-level

• Linux uniquement : XDP nécessite un noyau 5.x ou supérieur. Pas de support Windows/BSD.
• Stateless par défaut : XDP ne voit pas l'état des connexions TCP. Pour du rate-limit par connexion ou de l'inspection stateful, il faut combiner avec nftables ou maintenir des maps eBPF complexes.
• Courbe d'apprentissage : eBPF reste bas niveau. Une plateforme SaaS simplifie drastiquement, mais comprendre les concepts (maps, verdicts XDP_DROP/PASS/TX, BTF) demande un minimum de formation.
• Pas de scrubbing en amont : XDP protège sur le serveur. Si un flood volumétrique sature la liaison montante (ex : 100 Gbps sur une ligne 10 Gbps), XDP ne peut rien faire. Dans ce cas, une solution de scrubbing cloud (OVH VAC, Cloudflare Spectrum) reste nécessaire en complément.

Comparatif synthétique : quand choisir fail2ban, CrowdSec ou kernel-level ?

Critère	fail2ban	CrowdSec	XDP/eBPF + nftables
Réactivité	Quelques secondes (lecture logs)	Quelques secondes (lecture logs) ; proactif via blocklists pré-chargées	Sub-microseconde (kernel-level)
Débit max traitable	Limité par iptables/nftables userland (~100k pps avant dégradation)	Idem fail2ban (~100-500k pps avec sets nftables)	Plusieurs millions pps (XDP), quasi-linéaire avec le nombre de cœurs
Détection d'attaques	Logs applicatifs uniquement	Logs applicatifs + CTI communautaire (IPs signalées)	Inspection réseau brute (IP, port, taille paquet, protocole) ; pas de logs applicatifs
Complexité	Faible (conf INI)	Moyenne (YAML, agents/bouncers, Hub)	Élevée en mode manuel ; faible avec SaaS (PAKKT)
Protection DDoS volumétrique	Non	Non	Oui (rate-limit pps, early drop)
Gestion centralisée multi-serveurs	Non (scripts manuels)	Oui (CrowdSec Console SaaS)	Oui (PAKKT panel, API publique)
Coût	Gratuit	Gratuit (limites) / 49$/mois (Premium blocklists)	PAKKT : 3€/agent/mois (essai 7j gratuit)

Recommandations pragmatiques

• Serveur web classique, SSH, mail : fail2ban suffit. Simple, stable, gratuit. Combinez avec un set nftables pour scalabilité si vous bannissez > 1000 IPs.
• Infrastructure multi-serveurs, besoin de CTI : CrowdSec. Les blocklists communautaires apportent une proactivité réelle. Le bouncer nftables optimise les performances.
• Serveur de jeu, API haute fréquence, DDoS volumétrique : XDP/eBPF + nftables. Seule approche capable de traiter plusieurs millions de paquets par seconde sans dégrader la latence. PAKKT simplifie le déploiement et offre métriques temps réel + gestion centralisée.
• Approche hybride : CrowdSec (détection applicative, blocklists) + PAKKT (protection kernel). CrowdSec détecte les scans SSH/HTTP, PAKKT les bloque au niveau XDP. API publique PAKKT permet d'intégrer les décisions CrowdSec via webhook.

En pratique, de nombreux administrateurs combinent fail2ban ou CrowdSec (protection applicative, logs, alertes) avec une couche kernel XDP/nftables (protection volumétrique, rate-limit pps, early drop). Les deux approches sont complémentaires, pas exclusives.

Cas d'usage concrets : ban IP pour serveurs de jeu, API et infrastructures critiques

Serveur Minecraft sous attaque DDoS (UDP flood)

Symptômes : 500 000 paquets UDP/sec sur le port 25565, serveur inaccessible, CPU saturé par le traitement réseau.

Solution fail2ban/CrowdSec : inefficace (pas de logs UDP exploitables, réactivité trop lente).

Solution XDP (PAKKT) :

# Règle XDP : limiter le port 25565 à 100 000 pps
bpftool map update name pakkt_rules key 25565 value "{ rule_type: rate_limit, max_pps: 100000, protocol: udp }"
# Règle nftables : rate-limit par IP source (burst 50 paquets/sec)
nft add rule inet pakkt input udp dport 25565 meter flood_limit { ip saddr limit rate 50/second burst 100 packets } accept
nft add rule inet pakkt input udp dport 25565 counter drop

Résultat : XDP drop 400 000 paquets/sec au niveau driver (< 5% CPU), les 100 000 pps légitimes passent à nftables, qui affine par IP (50 pps max par source). Le serveur reste jouable, latence inchangée.

API REST publique : brute-force sur /login

Symptômes : 10 000 requêtes POST /login par minute depuis 200 IPs différentes (botnet).

Solution fail2ban : efficace si Nginx/Apache log les 401. Regex typique :

failregex = ^<HOST> .* "POST /login HTTP/1\.\d" 401

Limite : délai de plusieurs secondes entre l'attaque et le ban. 10 000 requêtes peuvent saturer la base de données avant que fail2ban ne réagisse.

Solution CrowdSec + PAKKT :

• CrowdSec détecte les IPs malveillantes via logs Nginx (scenario crowdsecurity/http-bf).
• Webhook CrowdSec pousse les IPs vers l'API PAKKT (POST /api/v1/blacklist).
• PAKKT ajoute instantanément les IPs dans la BPF map XDP de tous les agents concernés.
• Prochaines requêtes de ces IPs sont droppées au niveau driver, avant même Nginx.

Avantage : combinaison de la détection applicative intelligente (CrowdSec) et de la réactivité kernel (XDP).

Infrastructure multi-datacenter : blacklist globale

Contexte : 50 serveurs répartis sur 3 datacenters, besoin de blacklister une IP sur tous les nœuds en < 1 seconde.

Solution PAKKT via API publique :

curl -X POST https://api.pakkt.io/v1/blacklist \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"ip": "198.51.100.42", "reason": "botnet_scan", "duration": 86400}'

L'IP est ajoutée dans la BPF map de tous les agents en < 500 ms (heartbeat 30s + push immédiat). Audit log centralisé dans le panel PAKKT : qui, quand, pourquoi, durée, nombre de paquets bloqués par agent.

Alternative fail2ban/CrowdSec : nécessite un script maison pour synchroniser iptables/nftables sur 50 serveurs, gestion manuelle des conflits, pas de métriques centralisées.

Conclusion

Le choix entre fail2ban, CrowdSec et les solutions kernel-level (XDP/eBPF + nftables) dépend de vos besoins en réactivité, débit et complexité. fail2ban reste la référence pour protéger des services applicatifs classiques (SSH, web) avec une configuration simple. CrowdSec ajoute une dimension collaborative précieuse via ses blocklists communautaires, idéale pour anticiper les menaces. Enfin, XDP/eBPF offre une protection sub-microseconde contre les attaques volumétriques, indispensable pour serveurs de jeu, API haute fréquence ou infrastructures critiques. Les plateformes SaaS comme PAKKT rendent cette technologie accessible sans expertise eBPF, avec gestion centralisée, métriques temps réel et intégrations tierces. Dans de nombreux cas, hybrider CrowdSec (détection) et XDP (exécution) via API offre le meilleur compromis : intelligence applicative et réactivité kernel, pour un ban IP à la fois proactif et instantané.

FAQ

Puis-je utiliser fail2ban et une solution XDP/eBPF en même temps sur le même serveur ?

Oui, les deux sont parfaitement compatibles. fail2ban gère les bans applicatifs (SSH, HTTP…) via nftables userland, tandis que XDP intervient au niveau driver réseau. Veillez à ce que fail2ban utilise une table nftables distincte (ex : inet filter) et que la plateforme XDP (PAKKT) utilise sa propre table isolée (inet pakkt). Aucun conflit : XDP drop les paquets avant netfilter, les règles fail2ban s'appliquent aux paquets acceptés par XDP.

CrowdSec peut-il détecter des attaques DDoS UDP ou SYN flood sans logs applicatifs ?

Non, CrowdSec repose exclusivement sur l'analyse de logs. Un flood UDP ou SYN flood massif ne génère souvent pas de logs exploitables (ou sature le serveur avant que CrowdSec ne parse les logs). Pour ce type d'attaque, une solution kernel-level (XDP rate-limit pps, nftables conntrack limit) est nécessaire. Vous pouvez hybrider : CrowdSec détecte les scans applicatifs, XDP traite les floods volumétriques.

Quelle est la différence entre un ban IP en XDP et un ban IP en nftables ?

XDP (eBPF) traite le paquet au niveau du driver réseau, avant l'allocation de sk_buff et la montée dans la stack IP. Latence sub-microseconde, débit de plusieurs millions pps, mais stateless (pas de conntrack). nftables (netfilter) traite le paquet après routage IP, avec accès au conntrack, états TCP, rate-limit par connexion. Plus flexible, mais latence ~10-50 µs et débit limité à ~100-500k pps selon le matériel. Une architecture robuste combine les deux : XDP pour blacklist/whitelist et rate-limit pps global, nftables pour filtrage stateful et rate-limit par connexion.