Chaque serveur Linux exposé sur Internet subit un déluge de tentatives de connexion SSH automatisées. Une étude de pots de miel (honeypots) a enregistré plus de 11 milliards de tentatives d’attaque, dont 7,9 milliards de connexions SSH par force brute sur identifiants et clés. Si votre serveur écoute sur le port 22 avec un mot de passe, ce n’est qu’une question de temps avant qu’un robot ne trouve la bonne combinaison. Fail2ban est la première ligne de défense que tout administrateur déploie : il lit vos journaux, repère les échecs d’authentification répétés et bannit l’adresse IP fautive au niveau du pare-feu, automatiquement.
Ce tutoriel vous guide pas à pas, de l’installation à un fichier de configuration prêt pour la production, sur Debian 12 et Ubuntu 24.04 LTS. Comptez environ 30 minutes. À la fin, vous aurez un pare-feu adaptatif qui bloque les attaquants SSH, protège vos services web et escalade les sanctions contre les récidivistes. Nous couvrons aussi la configuration fail2ban avancée, huit problèmes de dépannage courants, la faille CVE-2025-45311 et la comparaison avec CrowdSec.
Qu’est-ce que Fail2ban et comment il bloque la force brute
Fail2ban est un démon de prévention d’intrusion écrit en Python. Son principe est simple et redoutablement efficace : il surveille en continu les fichiers journaux (ou le journal systemd) à la recherche de motifs d’échec, comme une série de mauvais mots de passe SSH provenant de la même adresse. Quand le nombre d’échecs dépasse un seuil dans une fenêtre de temps donnée, Fail2ban ajoute une règle au pare-feu (nftables ou iptables) pour rejeter cette adresse pendant une durée définie.
Trois concepts structurent tout le système. Le filtre est une expression régulière qui identifie une ligne d’échec dans un journal. La jail (prison) associe un filtre à un service, à des seuils et à une action. L’action est ce que Fail2ban exécute quand une jail se déclenche, le plus souvent un bannissement au pare-feu. Vous configurez les seuils via trois paramètres clés : maxretry (nombre d’échecs tolérés), findtime (la fenêtre d’observation) et bantime (la durée du bannissement).
La version stable actuelle est Fail2ban 1.1.0, publiée en 2024, avec une préversion 1.1.1.beta0 disponible en amont mais non recommandée en production. Le projet est mature, présent dans les dépôts de quasiment toutes les distributions Linux, et reste l’outil de référence pour la protection d’un hôte unique. Contrairement à des systèmes plus lourds, il ne dépend d’aucun service cloud : tout se passe localement sur votre machine, ce qui en fait un choix idéal pour un VPS, un serveur dédié ou un Raspberry Pi auto-hébergé.
Fail2ban n’est pas un pare-feu en soi : il pilote votre pare-feu existant. Il ne remplace pas non plus une bonne hygiène de sécurité. Désactiver l’authentification par mot de passe au profit des clés SSH, changer le port d’écoute et maintenir le système à jour restent indispensables. Fail2ban ajoute une couche d’automatisation qui transforme un flot continu d’attaques en quelques lignes de journal sans conséquence.
Prérequis et versions logicielles
Avant d’installer Fail2ban, assurez-vous de disposer de l’environnement suivant. Toutes les commandes de ce tutoriel supposent un accès root ou sudo et un serveur accessible en SSH.
| Composant | Version requise | Vérification |
|---|---|---|
| Système | Debian 12 (Bookworm) ou Ubuntu 24.04 LTS | cat /etc/os-release |
| Fail2ban | 1.0.2 ou supérieur (1.1.0 recommandé) | fail2ban-client --version |
| Python | 3.9 ou supérieur (fourni par le système) | python3 --version |
| Pare-feu | nftables (par défaut) ou iptables | nft --version |
| Service de journal | systemd-journald | systemctl status systemd-journald |
| Accès | compte root ou sudo | sudo -v |
Sur Debian 12 et Ubuntu 24.04, le pare-feu par défaut est nftables, et les journaux d’authentification SSH passent par le journal systemd. Ces deux points modifient la configuration fail2ban moderne par rapport aux anciens guides qui supposaient iptables et /var/log/auth.log. Nous traiterons les deux cas, mais nous privilégierons les réglages adaptés aux distributions récentes.
Un dernier conseil avant de commencer : ouvrez une seconde session SSH en parallèle et gardez-la connectée pendant toute la durée de la configuration. Une erreur de réglage peut vous bannir vous-même. Cette session de secours vous évitera de perdre l’accès à votre propre serveur, un piège que nous détaillerons plus loin.
Étapes 1 et 2 : Installer Fail2ban sur Debian et Ubuntu
Étape 1. Mettez à jour la liste des paquets puis lancez l’installation. Pour installer fail2ban depuis les dépôts officiels, une seule commande suffit :
# Mettre à jour l'index des paquets
sudo apt update
# Installer Fail2ban (tire automatiquement les dépendances Python)
sudo apt install -y fail2ban
# Vérifier la version installée
fail2ban-client --versionLa sortie attendue ressemble à Fail2Ban v1.0.2 sur Debian 12 ou une version supérieure sur Ubuntu 24.04. Si vous voulez impérativement la 1.1.0, vous pouvez la compiler depuis les sources GitHub, mais la version des dépôts est largement suffisante pour un usage normal et reçoit les correctifs de sécurité de la distribution.
Étape 2. Vérifiez que le service est actif. Sur Debian et Ubuntu, le paquet active et démarre Fail2ban automatiquement après l’installation.
# État du service
sudo systemctl status fail2ban
# L'activer au démarrage si nécessaire
sudo systemctl enable --now fail2banVous devriez voir active (running) en vert. À ce stade, Fail2ban fonctionne déjà avec sa configuration par défaut, qui inclut une jail sshd de base sur la plupart des installations. Mais ne vous arrêtez pas là : la configuration par défaut est volontairement prudente, et nous allons la durcir dans les étapes suivantes. Ne modifiez jamais directement les fichiers fournis par le paquet, car une mise à jour les écraserait sans préavis.
Étapes 3 et 4 : Comprendre jail.conf et jail.local
Toute la configuration de Fail2ban vit dans /etc/fail2ban/. Le fichier jail.conf contient les réglages par défaut livrés par le paquet. La règle d’or, répétée dans toute la documentation officielle : ne modifiez jamais jail.conf. Vos changements y seraient effacés à la prochaine mise à jour. À la place, créez un fichier jail.local qui surcharge uniquement les valeurs que vous voulez changer.
Étape 3. Explorez l’arborescence de configuration pour comprendre où vont les choses :
/etc/fail2ban/
jail.conf # Réglages par défaut (NE PAS MODIFIER)
jail.local # Vos surcharges (à créer)
jail.d/ # Fichiers de jails additionnels (.local ou .conf)
fail2ban.conf # Réglages du démon (niveau de log, socket)
filter.d/ # Expressions régulières par service (sshd.conf, etc.)
action.d/ # Définitions d'actions (nftables, iptables, mail)Étape 4. Créez votre fichier jail.local. Plutôt que de copier l’intégralité de jail.conf (une mauvaise pratique qui rend les mises à jour confuses), partez d’un fichier minimal qui ne contient que vos surcharges. Ouvrez-le avec votre éditeur :
sudo nano /etc/fail2ban/jail.localNous remplirons ce fichier dans les étapes suivantes. Sachez que la section [DEFAULT] définit les valeurs globales appliquées à toutes les jails, tandis que chaque section nommée comme [sshd] ne configure qu’un service précis et peut surcharger les valeurs globales. Cette hiérarchie est au cœur d’une configuration fail2ban propre et maintenable.
Étape 5 : Configurer la jail sshd (bantime, findtime, maxretry)
C’est le cœur de la protection SSH. Trois paramètres gouvernent le comportement de bannissement. Voici leurs valeurs par défaut dans Fail2ban et des recommandations durcies pour un serveur de production.
| Paramètre | Défaut Fail2ban | Recommandé | Rôle |
|---|---|---|---|
maxretry | 5 | 3 | Échecs tolérés avant bannissement |
findtime | 10m (600 s) | 10m | Fenêtre où l’on compte les échecs |
bantime | 10m (600 s) | 1h ou plus | Durée du bannissement |
ignoreip | 127.0.0.1/8 ::1 | + votre IP fixe | Adresses jamais bannies |
bantime.increment | false | true | Allonge la peine des récidivistes |
Renseignez maintenant votre jail.local avec une section globale et une jail sshd durcie. Voici un bloc fonctionnel à coller :
[DEFAULT]
# Bannir pour 1 heure après 3 échecs en 10 minutes
bantime = 1h
findtime = 10m
maxretry = 3
# Allonger automatiquement la peine des récidivistes
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w
# Ne jamais bannir le réseau local ni votre IP d'admin
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
[sshd]
enabled = true
port = ssh
maxretry = 3Remplacez 203.0.113.10 par votre adresse IP fixe réelle. Le paramètre bantime.increment = true est l’un des réglages les plus utiles : un attaquant banni une première fois pour 1 heure le sera pour 2 heures à la récidive, puis 4 heures, et ainsi de suite jusqu’au plafond bantime.maxtime d’une semaine. Cette escalade décourage les robots persistants sans bloquer définitivement une IP qui pourrait, plus tard, être réattribuée à un utilisateur légitime.
Étape 6 : Choisir le backend (systemd ou auth.log)
Le backend indique à Fail2ban où lire les événements d’authentification. C’est un point de bascule majeur entre les anciens et les nouveaux systèmes. Sur Debian 12 et Ubuntu 24.04, les messages SSH sont écrits dans le journal systemd, pas forcément dans un fichier /var/log/auth.log. Si vous utilisez le mauvais backend, Fail2ban ne verra aucun échec et ne bannira personne, alors même que le service tourne.
[sshd]
enabled = true
port = ssh
# Lire directement le journal systemd (recommandé sur Debian 12 / Ubuntu 24.04)
backend = systemd
maxretry = 3Si votre serveur écrit toujours /var/log/auth.log (certaines installations conservent rsyslog), vous pouvez à la place pointer un chemin de fichier :
[sshd]
enabled = true
backend = auto
logpath = /var/log/auth.log
maxretry = 3Le réglage backend = auto tente de détecter la meilleure source, mais sur les distributions récentes il est plus fiable de forcer backend = systemd. Pour vérifier où atterrissent réellement vos journaux SSH, lancez journalctl -u ssh -n 20 : si des lignes apparaissent, le journal systemd est bien la bonne source. Ce diagnostic résout à lui seul la majorité des cas où « Fail2ban ne bannit rien ».
Étape 7 : Choisir l’action de bannissement (nftables ou iptables)
Le banaction détermine comment Fail2ban insère le blocage dans votre pare-feu. Sur Debian moderne, le pare-feu par défaut est nftables, et Fail2ban doit lui parler dans son propre langage. Utiliser une action iptables sur un système nftables peut sembler fonctionner mais provoquer des incohérences. Forcez l’action adaptée dans la section [DEFAULT] :
[DEFAULT]
# Bannir via nftables, le pare-feu par défaut de Debian 12 / Ubuntu 24.04
banaction = nftables-multiport
banaction_allports = nftables-allports
# Chaîne de filtrage des connexions entrantes
chain = input| banaction | Pare-feu | Quand l’utiliser |
|---|---|---|
nftables-multiport | nftables | Debian 12, Ubuntu 24.04, systèmes récents |
nftables-allports | nftables | Bloquer tous les ports d’une IP |
iptables-multiport | iptables | Systèmes hérités ou conteneurs anciens |
ufw | UFW | Serveurs gérés via UFW |
route | table de routage | Sans pare-feu, blocage par route nulle |
Si vous gérez votre pare-feu avec UFW (fréquent sur Ubuntu), réglez banaction = ufw pour que les bannissements apparaissent dans les règles UFW et restent cohérents. Vérifiez ensuite que le pare-feu reflète bien les actions de Fail2ban, sinon vous obtiendrez des règles fantômes que rien ne supprime.
Étape 8 : Appliquer et piloter avec fail2ban-client
fail2ban-client est l’outil en ligne de commande qui pilote le démon. Après chaque modification de configuration, rechargez sans redémarrer pour ne pas perdre les bannissements en cours.
# Tester la syntaxe de la configuration avant d'appliquer
sudo fail2ban-client -t
# Recharger la configuration (sans couper les bannissements actifs)
sudo fail2ban-client reload
# Voir toutes les jails actives
sudo fail2ban-client status
# Détail d'une jail précise
sudo fail2ban-client status sshdLa commande fail2ban-client status sshd produit une sortie comme celle-ci, qui résume l’état de la surveillance :
Status for the jail: sshd
|- Filter
| |- Currently failed: 2
| |- Total failed: 147
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 3
|- Total banned: 19
`- Banned IP list: 185.142.236.34 218.92.0.112 92.118.39.88Les compteurs Total failed et Total banned grimpent vite sur un serveur exposé, preuve concrète que Fail2ban travaille. Mémorisez aussi deux commandes de gestion manuelle : fail2ban-client set sshd unbanip 185.142.236.34 pour libérer une IP injustement bloquée, et fail2ban-client set sshd banip 1.2.3.4 pour bannir manuellement une adresse hostile.
Étape 9 : Tester le bannissement en conditions réelles
Ne supposez jamais qu’une protection fonctionne sans la tester. Depuis une machine extérieure (jamais celle listée dans ignoreip), provoquez délibérément des échecs SSH. Le moyen le plus propre est de tenter quelques connexions avec un utilisateur inexistant.
# Depuis une autre machine, tenter 4 connexions avec un faux compte
ssh utilisateur-inexistant@VOTRE_SERVEUR
# (répéter, en saisissant n'importe quel mot de passe, jusqu'au bannissement)
# Sur le serveur, vérifier que l'IP a bien été bannie
sudo fail2ban-client status sshd
# Inspecter la règle nftables créée par Fail2ban
sudo nft list ruleset | grep -A4 f2bAprès le quatrième échec, votre machine de test ne doit plus pouvoir se connecter : la connexion expire ou est refusée immédiatement. Dans le journal du serveur, vous verrez une ligne de bannissement explicite :
fail2ban.actions [1234]: NOTICE [sshd] Ban 203.0.113.55
fail2ban.actions [1234]: NOTICE [sshd] 203.0.113.55 already bannedPour lever le bannissement de test, exécutez sudo fail2ban-client set sshd unbanip 203.0.113.55. Ce test de bout en bout est la seule preuve fiable que votre filtre, votre backend et votre banaction fonctionnent ensemble. Beaucoup d’administrateurs croient être protégés alors qu’une simple incompatibilité de backend laisse passer toutes les attaques.
Étape 10 : Protéger vos propres accès avec ignoreip
Le piège le plus douloureux de Fail2ban consiste à se bannir soi-même. Si vous tapez plusieurs fois un mauvais mot de passe ou si votre client de sauvegarde échoue en boucle, votre propre IP rejoint la liste noire et vous perdez l’accès au serveur. La parade est la directive ignoreip, qui définit une liste blanche d’adresses jamais bannies.
[DEFAULT]
# Réseau local, IPv6 locale, votre IP fixe, et un sous-réseau d'entreprise
ignoreip = 127.0.0.1/8 ::1 203.0.113.10 198.51.100.0/24Vous pouvez lister des adresses uniques, des plages CIDR, et même des noms d’hôte (Fail2ban les résout au démarrage). Si vous n’avez pas d’IP fixe, deux solutions existent : utiliser un VPN avec une adresse de sortie stable que vous placez en liste blanche, ou vous appuyer sur un bastion. Évitez en revanche de mettre en liste blanche des plages entières d’opérateurs mobiles, car cela ouvrirait une brèche béante. Après modification, rechargez avec sudo fail2ban-client reload pour que la liste blanche prenne effet.
Étape 11 : Activer la jail recidive contre les récidivistes
La jail recidive surveille le propre journal de Fail2ban et bannit pour très longtemps les adresses qui se font bannir de façon répétée. C’est la sanction des robots les plus tenaces : une IP bannie plusieurs fois en quelques jours est mise à l’écart pour une semaine entière, tous services confondus. Activez-la dans jail.local :
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = nftables-allports
bantime = 1w
findtime = 1d
maxretry = 5Ici, une IP bannie cinq fois en une journée (findtime = 1d) est bloquée une semaine (bantime = 1w) sur tous les ports grâce à nftables-allports. Comme la jail recidive lit /var/log/fail2ban.log, assurez-vous que la journalisation vers ce fichier est active (c’est le cas par défaut sur Debian et Ubuntu). Si vous avez activé bantime.increment à l’étape 5, la jail recidive vient compléter cette escalade en frappant les cas extrêmes encore plus fort.
Étape 12 : Recevoir des notifications par e-mail
Pour rester informé sans surveiller les journaux en permanence, configurez l’envoi d’un e-mail à chaque bannissement. Vous aurez besoin d’un agent de transport de courrier (comme postfix en mode satellite ou msmtp) déjà capable d’envoyer du courriel depuis le serveur.
[DEFAULT]
# Adresses d'envoi et de réception des alertes
destemail = [email protected]
sender = [email protected]
mta = sendmail
# Action : bannir ET envoyer un mail avec les lignes de journal
action = %(action_mwl)sL’action action_mwl bannit l’IP, envoie un courriel et y joint un rapport WHOIS ainsi que les lignes de journal incriminantes (mwl = mail with logs). Si vous voulez seulement bannir sans alerte, gardez l’action par défaut action_. Pour un volume d’attaques élevé, attention à ne pas vous noyer sous les e-mails : sur un serveur exposé, des centaines de bannissements quotidiens transformeraient vite cette alerte en bruit. Réservez les notifications aux jails critiques ou agrégez-les via un outil de supervision.
Le projet complet : un jail.local prêt pour la production
Voici un fichier /etc/fail2ban/jail.local complet, regroupant tous les réglages de ce tutoriel. Il protège SSH, durcit les seuils, escalade les peines, active la jail recidive et inclut deux jails web courantes (à n’activer que si vous faites tourner Nginx). Adaptez les adresses IP et le domaine, puis collez-le tel quel.
[DEFAULT]
# --- Politique globale de bannissement ---
bantime = 1h
findtime = 10m
maxretry = 3
# Escalade automatique des peines pour les recidivistes
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w
# Liste blanche : local + votre IP d'administration fixe
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
# Pare-feu et source des journaux pour Debian 12 / Ubuntu 24.04
banaction = nftables-multiport
banaction_allports = nftables-allports
backend = systemd
# Notifications (optionnel : necessite un MTA fonctionnel)
destemail = [email protected]
sender = [email protected]
mta = sendmail
action = %(action_)s
# --- Protection SSH ---
[sshd]
enabled = true
port = ssh
maxretry = 3
# --- Recidivistes (tous services) ---
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = nftables-allports
bantime = 1w
findtime = 1d
maxretry = 5
# --- Nginx : echecs d'authentification HTTP (si applicable) ---
[nginx-http-auth]
enabled = true
port = http,https
backend = systemd
# --- Nginx : recherche de scripts malveillants (si applicable) ---
[nginx-botsearch]
enabled = true
port = http,https
backend = systemdAppliquez ce fichier en deux temps : testez d’abord la syntaxe avec sudo fail2ban-client -t, puis rechargez avec sudo fail2ban-client reload. Confirmez ensuite que toutes les jails attendues sont chargées via sudo fail2ban-client status. Vous disposez désormais d’une configuration fail2ban robuste, prête à encaisser le trafic d’attaque permanent d’Internet.
Cinq pièges courants à éviter
La plupart des configurations Fail2ban qui « ne fonctionnent pas » se résument à une poignée d’erreurs récurrentes. Les voici, avec leur correctif.
- Mauvais backend. Sur Debian 12 et Ubuntu 24.04, oublier
backend = systemdalors qu’aucun/var/log/auth.logn’existe fait que Fail2ban ne lit rien et ne bannit personne. Vérifiez avecjournalctl -u ssh. - Se bannir soi-même. Ne pas renseigner son IP dans
ignoreipavant de tester est le classique des classiques. Gardez toujours une seconde session SSH ouverte. - Modifier jail.conf. Vos réglages disparaissent à la prochaine mise à jour du paquet. Tout doit aller dans
jail.localoujail.d/. - Action iptables sur un système nftables. Les bannissements semblent créés mais n’aboutissent pas toujours. Alignez
banactionsur le pare-feu réel de la machine. - Redémarrer au lieu de recharger.
systemctl restart fail2banefface les bannissements en cours. Préférezfail2ban-client reloadpour conserver l’état.
Dépannage : huit problèmes fréquents et leurs solutions
Quand Fail2ban se comporte mal, ce tableau vous oriente vers la cause la plus probable et la commande de diagnostic à lancer.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Aucune IP n’est bannie | Mauvais backend ou logpath | Forcer backend = systemd et vérifier journalctl -u ssh |
fail2ban-client -t échoue | Erreur de syntaxe dans jail.local | Lire le message, corriger la ligne indiquée |
| Le service ne démarre pas | Filtre ou action introuvable | Consulter journalctl -u fail2ban -n 50 |
| Jail sshd absente du status | enabled = true manquant | Activer explicitement la jail |
| IP bannie toujours connectée | Connexion établie avant le ban | Normal : nftables coupe les nouvelles connexions |
| Vous êtes bloqué dehors | Auto-bannissement | Console fournisseur puis unbanip votre IP |
| Erreurs « no logpath » | backend fichier sans fichier | Passer en backend = systemd |
| Bannissements perdus au reboot | Persistance non configurée | Activer la base SQLite (par défaut récent) |
Si vous êtes verrouillé hors du serveur, n’attendez pas l’expiration du bannissement : la plupart des hébergeurs (OVHcloud, Scaleway, Hetzner) offrent une console web ou un mode rescue qui contourne SSH. Depuis cette console, lancez sudo fail2ban-client set sshd unbanip VOTRE_IP, ou arrêtez temporairement le service avec sudo systemctl stop fail2ban le temps de corriger votre ignoreip. Pour un diagnostic général, les journaux du démon dans /var/log/fail2ban.log et la commande journalctl -u fail2ban contiennent presque toujours la réponse.
Astuces avancées pour aller plus loin
Créer un filtre personnalisé
Fail2ban protège n’importe quel service qui écrit des échecs dans un journal, pas seulement SSH. Pour une application maison, créez un filtre dans /etc/fail2ban/filter.d/monapp.conf avec une failregex qui capture l’adresse fautive via le marqueur <HOST> :
[Definition]
failregex = ^.*Authentication failure for .* from <HOST>.*$
ignoreregex =Testez votre expression régulière sur un journal réel avant de l’activer, grâce à l’outil intégré fail2ban-regex :
sudo fail2ban-regex /var/log/monapp.log /etc/fail2ban/filter.d/monapp.confLa sortie indique combien de lignes correspondent et quelles adresses seraient bannies. C’est l’outil indispensable pour mettre au point un filtre sans risquer de bannir de vrais utilisateurs.
IPv6 et services derrière un proxy
Fail2ban gère IPv6 nativement avec nftables, à condition que votre pare-feu accepte les deux familles d’adresses. Attention en revanche aux services placés derrière un proxy ou un CDN comme Cloudflare : Fail2ban verrait l’IP du proxy, pas celle du visiteur réel, et risquerait de bannir le CDN tout entier. Dans ce cas, lisez l’en-tête X-Forwarded-For dans vos journaux applicatifs et écrivez un filtre qui extrait la vraie adresse, ou utilisez l’intégration native du proxy pour bloquer en amont.
Fail2ban face à CrowdSec : lequel choisir
Depuis quelques années, CrowdSec se positionne comme l’alternative moderne à Fail2ban. La différence de philosophie est nette. Fail2ban est un moniteur de journaux et un moteur de bannissement local : il observe les logs de votre seule machine et applique des règles de pare-feu. CrowdSec ajoute une dimension collaborative : les adresses détectées comme malveillantes sont partagées dans une base de réputation communautaire, si bien qu’une IP repérée sur un serveur peut être bloquée préventivement sur les autres.
| Critère | Fail2ban | CrowdSec |
|---|---|---|
| Architecture | Hôte unique, autonome | Agent + base de réputation partagée |
| Renseignement | Local uniquement | Communautaire et multi-signaux |
| Langage | Python | Go |
| Dépendance réseau | Aucune | Optionnelle (liste noire en ligne) |
| Complexité | Faible, fichiers de config | Plus riche, scénarios et parseurs |
| Idéal pour | VPS, auto-hébergement, simplicité | Parc de serveurs, défense mutualisée |
Pour un serveur unique, un VPS personnel ou un projet auto-hébergé, Fail2ban reste le choix le plus léger, le plus simple à comprendre et sans dépendance externe. Pour un parc de machines ou une organisation qui veut bénéficier d’un renseignement de menace partagé, CrowdSec apporte une couche supplémentaire. Les deux ne sont d’ailleurs pas exclusifs : certains administrateurs font tourner Fail2ban pour SSH et CrowdSec pour le web. Le bon réflexe reste de maîtriser d’abord Fail2ban, dont les concepts (filtre, jail, action) éclairent ensuite tout outil de prévention d’intrusion.
Sécuriser Fail2ban lui-même : la faille CVE-2025-45311
Un outil de sécurité doit lui-même être sûr. En 2025, la vulnérabilité CVE-2025-45311 a été publiée concernant fail2ban-client sur d’anciennes versions (autour de la branche 0.11.2), liée à des permissions trop permissives qui pouvaient, dans certaines configurations, permettre à un utilisateur disposant de droits sudo limités d’effectuer des opérations root arbitraires. La leçon est simple : maintenez Fail2ban à jour via le gestionnaire de paquets de votre distribution, qui rétroporte les correctifs de sécurité.
- Restreignez l’accès au socket. Le socket de contrôle dans
/var/run/fail2ban/ne doit être accessible qu’à root. - Auditez vos règles sudo. N’accordez jamais un accès
fail2ban-clienttrop large à des comptes non administrateurs. - Surveillez les CVE. Consultez régulièrement les annonces de sécurité de votre distribution et du projet sur GitHub.
- Mettez à jour. Une simple commande
sudo apt update && sudo apt upgradeapplique les correctifs disponibles.
Fail2ban réduit considérablement la surface d’attaque SSH, mais il s’inscrit dans une stratégie de défense en profondeur. Combinez-le avec l’authentification par clés, la désactivation du login root direct, un pare-feu correctement configuré et des mises à jour régulières. Aucun outil unique ne remplace cet empilement de protections.
Pour aller plus loin (Related Coverage)
- VPN WireGuard sur Linux : 12 étapes, 30 min
- Certificat SSL gratuit avec Certbot : 11 étapes
- Authentification JWT en Node.js : 12 étapes
- VeraCrypt : chiffrer un disque en 12 étapes
- Sécurité des mots de passe : longueur, hachage et gestionnaires
- Sécurité en ligne : protéger ses données et ses comptes
Questions fréquentes sur Fail2ban
Fail2ban ralentit-il mon serveur ?
Non, l’impact est négligeable. Fail2ban lit les journaux de façon incrémentale et n’intervient sur le pare-feu qu’au moment d’un bannissement. Sur un serveur recevant des milliers d’attaques par jour, sa consommation processeur et mémoire reste minime. C’est l’une des raisons de sa popularité durable.
Quelle est la bonne durée de bannissement (bantime) ?
Le défaut de Fail2ban est de 10 minutes, ce qui est court. Pour un serveur de production, 1 heure est un bon compromis, complété par bantime.increment = true qui allonge automatiquement la peine des récidivistes jusqu’à une semaine. Bannir définitivement est déconseillé, car les adresses IP peuvent être réattribuées à des utilisateurs légitimes.
Fail2ban fonctionne-t-il sans /var/log/auth.log ?
Oui. Sur Debian 12 et Ubuntu 24.04, les journaux SSH passent souvent par le journal systemd. Réglez backend = systemd dans votre jail pour que Fail2ban lise directement journald. C’est même la configuration recommandée sur les distributions récentes.
Comment débloquer une adresse IP bannie ?
Utilisez sudo fail2ban-client set sshd unbanip 1.2.3.4 en remplaçant le nom de la jail et l’adresse. Pour éviter qu’elle soit rebannie, ajoutez-la à ignoreip dans jail.local puis rechargez la configuration.
Fail2ban remplace-t-il un pare-feu ?
Non. Fail2ban pilote un pare-feu existant (nftables, iptables ou UFW) ; il n’en est pas un. Il faut donc disposer d’un pare-feu fonctionnel pour que les bannissements s’appliquent. Considérez Fail2ban comme la couche de décision et le pare-feu comme la couche d’exécution.
Faut-il choisir Fail2ban ou CrowdSec ?
Pour un serveur unique ou un projet auto-hébergé, Fail2ban est plus simple et sans dépendance externe. CrowdSec apporte une réputation partagée entre serveurs, intéressante pour un parc de machines. Les deux peuvent cohabiter. Commencer par Fail2ban est le meilleur moyen de comprendre les concepts de prévention d’intrusion.
Comment protéger d’autres services que SSH ?
Fail2ban inclut des filtres prêts à l’emploi pour Nginx, Apache, Postfix, Dovecot et bien d’autres dans /etc/fail2ban/filter.d/. Activez la jail correspondante dans jail.local, ou créez votre propre filtre avec fail2ban-regex pour une application maison. Le principe (filtre, jail, action) reste identique.
Quelle est la dernière version de Fail2ban ?
La version stable est Fail2ban 1.1.0, publiée en 2024, avec une préversion 1.1.1.beta0 disponible en amont. Pour un serveur de production, la version fournie par les dépôts de Debian ou Ubuntu (par exemple 1.0.2 sur Debian 12) est parfaitement adaptée et reçoit les correctifs de sécurité.
Sources et références
- Site officiel de Fail2ban
- Dépôt GitHub et notes de version
- Manuel jail.conf (paramètres de configuration)
- CVE-2025-45311 (fail2ban-client)
- CrowdSec, l’alternative collaborative
- OpenSSH, le service à protéger en priorité
Article mis à jour le 12 juin 2026. Les commandes ont été testées sur Debian 12 et Ubuntu 24.04 LTS. Vérifiez toujours la configuration sur un serveur de test avant un déploiement en production.
