À 03:00, fail2ban a banni 200 IP — victoire contre le bruit SSH. À 14:00, personne ne peut se connecter depuis le bureau : l'IP sortante mutualisée du FAI a été flaggée après trop de typos de mot de passe sur le panel admin.
Fail2ban lit les logs, compte les échecs, pousse une règle iptables/nftables. Utile contre le scan opportuniste, insuffisant contre un attaquant qui lit vos seuils.
Ce que fail2ban fait bien
Réduit le bruit sur sshd, postfix, apache auth. Automatise une réponse sans SIEM. Faible coût CPU sur petit VPS.
Configuration : bantime, findtime, maxretry — documentez pourquoi ces chiffres.
Limites structurelles
| Attaque | Efficacité fail2ban |
|---|---|
| Scan SSH massif | Bonne |
| Brute force lent (1 req/min/IP) | Faible |
| Botnet distribué | Faible |
| Exploit app sans log auth | Nulle |
| DDoS volume | Nulle |
Fail2ban ne voit que ce qui est loggé avec le bon format.
Faux positifs d'exploitation
Monitoring externe, scanners sécu, collègues en VPN partagé. Utilisez ignoreip pour ranges stables — pas 0.0.0.0/0 par paresse.
Alertez quand un /16 entier est banni (signe d'attaque ou mauvaise jail).
Durcissement prioritaire
- Désactiver auth password SSH.
- Fermer ports inutiles (ufw/nft).
- MFA ou bastion.
- Mises à jour auto sécurité.
- Fail2ban en couche 5, pas couche 1.
Observabilité
Exporter bans vers Prometheus/Grafana. Corréler avec WAF edge. Runbook déban d'urgence sans désactiver fail2ban globalement.
Couches avant fail2ban
Ordre recommandé : fermer ports inutiles → clés SSH → MFA/bastion → WAF/rate limit edge → fail2ban jails ciblées → SIEM corrélation.
Revoyez jails après chaque deploy nouveau service loggé — format log change = jail morte ou faux positifs.
Tenez registre bans hebdo : IP country ASN répétés = vrai scan ; IP FAI local = probablement l'équipe.
Fail2ban excelle à couper bruit sshd dimanche ; il ne remplace pas patch Tuesday ni WAF sur OWASP top 10.
Quand ajouter une jail
Nouveau service avec auth basic : jail après deux semaines de logs format stables — pas jour J deploy.
Recidive jail : ban long après N bans courts — utile scan persistant, dangereux si IP dynamic FAI.
Alternative modern : CrowdSec partage signaux — complément fail2ban, pas remplacement réflexion.
Attaque credential stuffing sur login web : fail2ban sur nginx 401 peut aider mais WAF règle rate + CAPTCHA après N échecs plus durable.
Log centralisé : enrich ban events avec geo ASN pour décider block permanent firewall vs ban temporaire fail2ban.
Intégration SIEM
Export ban events en JSON : IP, jail, timestamp, country. Corrélez avec WAF block logs — même IP sur les deux = attaque coordonnée.
Playbook : déban IP d'exploitation via script idempotent fail2ban-client unban — pas édition iptables manuelle.
Réévaluez jails après migration IPv6 — beaucoup de configs ignorent sshd [::ffff:] patterns.
Synthèse opérationnelle
Fail2ban reste un outil de confort pour réduire le bruit SSH et les scans opportunistes sur VPS et serveurs dédiés. Il ne constitue pas une ligne de défense contre un attaquant ciblant une vulnérabilité applicative ou utilisant un botnet à faible débit. Placez-le après durcissement SSH, bastion, mises à jour, WAF et monitoring centralisé.
Revoyez trimestriellement chaque jail : logs rotatés, format changé, service supprimé. Une jail orpheline donne fausse sécurité ou bannit le monitoring. Documentez procédure déban et listes blanches d'exploitation. En infogéré, demandez équivalent managé plutôt qu'iptables artisanal.
Support client
Connexion refused ban IP — FAQ support différencie ban fail2ban vs site down.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Couches
Ports, clés, bastion, WAF, fail2ban ciblé, SIEM — ordre documenté.
Décider et avancer sans angle mort
- Fermer les ports inutiles — clés SSH, MFA ou bastion, WAF edge, puis fail2ban ciblé.
- Revoir les jails après chaque deploy — format de log changé = jail morte ou faux positifs.
- Tenir un registre hebdo des bans — ASN répétés vs IP FAI local (équipe légitime).
- Ne pas confondre bruit et attaque — fail2ban coupe le scan dimanche, pas une CVE applicative.
- Couches complémentaires — SIEM, rate limit, patch Tuesday documentés dans le runbook.
Évaluez WAF managé vs VPS nu dans l'annuaire et le comparateur.
Questions fréquentes
Fail2ban bloque-t-il les attaques DDoS ?
Non. Il bannit des IP après patterns dans les logs — inutile contre volumes massifs ou IP rotatives à faible taux.
Risque de s'auto-bannir ?
Oui si seuils agressifs sur HTTP ou si votre IP monitoring partage le même compteur. Listez explicitement les plages stables dans ignoreip.
Quelles jails minimum ?
sshd, nginx-http-auth, recidive — adaptez selon services exposés. Évitez jails génériques sur logs bruyants.
Alternative plus robuste ?
Clés SSH only, port knocking évité, VPN/WireGuard, WAF edge, rate limit nginx — fail2ban est couche complémentaire.
Si votre plan sécurité tient en une jail sshd, relisez la surface exposée — fail2ban ne la réduit pas.