fail2ban : bloquer les IP malveillantes

fail2ban est l’outil de référence pour bannir automatiquement les IP malveillantes sur un serveur Linux. Son principe est simple : il analyse en continu les fichiers de log (SSH, Apache, Nginx, Postfix, etc.) et, quand une même IP enchaîne trop d’échecs d’authentification ou de tentatives suspectes, il ajoute une règle de pare-feu pour la bannir pendant une durée définie. Indispensable sur tout serveur exposé à internet. Ce guide explique son fonctionnement, son installation, sa configuration et les jails les plus utiles.

Qu’est-ce que fail2ban ?

fail2ban est un service open source écrit en Python, distribué depuis 2004. Il combine deux composants : des filtres (expressions régulières qui détectent des événements suspects dans les logs) et des actions (qui modifient iptables/nftables, envoient un mail, etc.). L’ensemble d’un filtre + actions s’appelle une jail (prison).

Contrairement à un pare-feu classique (statique), fail2ban réagit dynamiquement au comportement. Une IP normale n’est jamais bloquée. Une IP qui tente 20 mots de passe SSH différents en 10 minutes l’est, automatiquement. Cela complète bien un audit avec nmap et la lecture des connexions actives avec netstat.

Installation

• Debian / Ubuntu : sudo apt install fail2ban
• Fedora / RHEL : sudo dnf install fail2ban
• Démarrer + activer au boot : sudo systemctl enable --now fail2ban
• Vérifier l’état : sudo systemctl status fail2ban

Configuration : jail.local

Convention : ne jamais modifier /etc/fail2ban/jail.conf directement (écrasé à chaque mise à jour). À la place, créer un fichier /etc/fail2ban/jail.local qui surcharge les paramètres voulus :

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = systemd

• bantime : durée du bannissement (1h, 24h, ou -1 pour permanent).
• findtime : fenêtre de temps pour compter les échecs.
• maxretry : nombre d’échecs avant ban.
• ignoreip : whitelist (votre LAN, vos serveurs). Crucial pour ne pas vous bannir vous-même.
• backend : auto, systemd (logs via journald), polling.

Recharger après modification : sudo systemctl reload fail2ban.

Jails utiles à activer

• sshd : protège SSH contre le brute force. Activer en priorité sur tout serveur.
• apache-auth : tentatives d’auth HTTP basic sur Apache.
• nginx-http-auth : équivalent sur Nginx.
• nginx-limit-req : couplé à limit_req de Nginx, bannit les abus de cadence.
• postfix et postfix-sasl : protège SMTP contre les tentatives d’envoi mail spam ou brute force.
• dovecot : auth IMAP/POP.
• wordpress-hard : combiné au plugin WP fail2ban, bannit les attaques XML-RPC, brute force wp-login.
• recidive : meta-jail qui bannit (longtemps) les IP qui ont déjà été bannies plusieurs fois.

Commandes fail2ban-client utiles

• sudo fail2ban-client status — liste les jails actives.
• sudo fail2ban-client status sshd — détail d’une jail (IPs bannies, tentatives détectées).
• sudo fail2ban-client set sshd unbanip 1.2.3.4 — débannir manuellement.
• sudo fail2ban-client set sshd banip 1.2.3.4 — bannir manuellement.
• sudo fail2ban-client reload — recharger la config.
• sudo tail -F /var/log/fail2ban.log — suivre les actions en direct.

Choisir bantime et maxretry

• Serveur perso, peu d’attaques : bantime 1h, maxretry 5 — suffisant.
• Serveur exposé, attaques fréquentes : bantime 24h, maxretry 3 — plus agressif.
• Bantime incrémental (recommandé) : bantime.increment = true, multiplier le ban à chaque récidive (1h, 6h, 24h, 7j…).
• Toujours mettre ignoreip sur votre IP perso ou votre VPN admin, sinon une fausse manip vous coupe l’accès SSH.

Cas d’usage et stratégies avancées

• SSH key only + fail2ban : couper la connexion par mot de passe (PasswordAuthentication no), garder fail2ban pour gérer les scans agressifs.
• Couplé à un changement de port SSH : pas une protection réelle (un scan nmap trouve toujours), mais réduit le bruit dans les logs.
• WordPress : plugin « WP fail2ban » qui écrit des entrées de log spécifiques exploitables.
• Géolocalisation : combiner avec geoip dans iptables / nftables pour bloquer certains pays en amont.
• Notification : action %(action_mwl)s envoie un mail avec whois + log à chaque ban (utile pour audit). Voir aussi localiser une IP pour identifier la provenance.
• Plusieurs serveurs : partager une liste de bans via fail2ban-shared ou crowdsec.

Alternatives et compléments à fail2ban

• CrowdSec : alternative moderne avec une base de bans partagée par la communauté. Plus moderne mais plus complexe à mettre en place.
• SSHGuard : équivalent fail2ban plus léger, focalisé SSH.
• Cloudflare WAF : protège côté CDN avant que le trafic atteigne votre serveur. Complémentaire (les attaques par IP directe passent au travers).
• iptables rate limiting : --limit, brut mais efficace pour cas simples.
• OS hardening : SELinux/AppArmor, audit, mises à jour. fail2ban ne remplace pas une configuration soigneuse.

FAQ : fail2ban

fail2ban remplace-t-il un pare-feu ?

Non. fail2ban manipule les règles iptables/nftables pour bannir des IP en plus du pare-feu existant. La règle de base reste : pare-feu strict (tout fermé sauf l’indispensable), puis fail2ban pour les services exposés. Voir aussi port forwarding.

fail2ban fonctionne-t-il sous Windows ?

Non, fail2ban est Linux only (Python + dépendance à iptables/firewalld). Sur Windows Server, regarder RdpGuard (RDP), SmartRDP, ou des règles GPO de verrouillage de compte. Sur Windows desktop, le pare-feu Windows fait déjà du basique anti-brute force.

Je me suis banni moi-même, comment récupérer l’accès ?

Passer par la console du fournisseur (OVH, Scaleway, AWS, etc.) ou un accès KVM/IPMI, lancer sudo fail2ban-client unban --all ou sudo iptables -F en urgence. Pour éviter la récidive, mettre votre IP fixe ou un préfixe permanent dans ignoreip.

Comment voir les IP actuellement bannies ?

sudo fail2ban-client status sshd liste les IP bannies pour la jail SSH. Pour l’historique complet, regarder /var/log/fail2ban.log ou journalctl -u fail2ban.

fail2ban ralentit-il le serveur ?

Impact négligeable sur des serveurs modestes (lecture de logs + maj iptables). Sur des serveurs très chargés avec beaucoup de jails actives, basculer en backend systemd et désactiver les jails inutiles suffit à le tenir efficace.

Pages liées : nmap, netstat, port forwarding, encyclopédie IP.