{"id":87,"date":"2026-06-12T16:25:12","date_gmt":"2026-06-12T16:25:12","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/12\/fail2ban-proteger-ssh-tutoriel\/"},"modified":"2026-06-12T16:27:10","modified_gmt":"2026-06-12T16:27:10","slug":"fail2ban-proteger-ssh-tutoriel","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/12\/fail2ban-proteger-ssh-tutoriel\/","title":{"rendered":"Fail2ban : prot\u00e9ger SSH en 12 \u00e9tapes, 30 min [2026]"},"content":{"rendered":"\n

Chaque serveur Linux expos\u00e9 sur Internet subit un d\u00e9luge de tentatives de connexion SSH automatis\u00e9es. Une \u00e9tude de pots de miel (honeypots) a enregistr\u00e9 plus de 11 milliards de tentatives d’attaque, dont 7,9 milliards de connexions SSH par force brute sur identifiants et cl\u00e9s. Si votre serveur \u00e9coute 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<\/strong> est la premi\u00e8re ligne de d\u00e9fense que tout administrateur d\u00e9ploie : il lit vos journaux, rep\u00e8re les \u00e9checs d’authentification r\u00e9p\u00e9t\u00e9s et bannit l’adresse IP fautive au niveau du pare-feu, automatiquement.<\/p>\n\n\n\n

Ce tutoriel vous guide pas \u00e0 pas, de l’installation \u00e0 un fichier de configuration pr\u00eat pour la production, sur Debian 12 et Ubuntu 24.04 LTS. Comptez environ 30 minutes. \u00c0 la fin, vous aurez un pare-feu adaptatif qui bloque les attaquants SSH, prot\u00e8ge vos services web et escalade les sanctions contre les r\u00e9cidivistes. Nous couvrons aussi la configuration fail2ban<\/strong> avanc\u00e9e, huit probl\u00e8mes de d\u00e9pannage courants, la faille CVE-2025-45311 et la comparaison avec CrowdSec.<\/p>\n\n\n\n

Qu’est-ce que Fail2ban et comment il bloque la force brute<\/h2>\n\n\n\n

Fail2ban est un d\u00e9mon de pr\u00e9vention d’intrusion \u00e9crit en Python. Son principe est simple et redoutablement efficace : il surveille en continu les fichiers journaux (ou le journal systemd) \u00e0 la recherche de motifs d’\u00e9chec, comme une s\u00e9rie de mauvais mots de passe SSH provenant de la m\u00eame adresse. Quand le nombre d’\u00e9checs d\u00e9passe un seuil dans une fen\u00eatre de temps donn\u00e9e, Fail2ban ajoute une r\u00e8gle au pare-feu (nftables ou iptables) pour rejeter cette adresse pendant une dur\u00e9e d\u00e9finie.<\/p>\n\n\n\n

Trois concepts structurent tout le syst\u00e8me. Le filtre<\/strong> est une expression r\u00e9guli\u00e8re qui identifie une ligne d’\u00e9chec dans un journal. La jail<\/strong> (prison) associe un filtre \u00e0 un service, \u00e0 des seuils et \u00e0 une action. L’action<\/strong> est ce que Fail2ban ex\u00e9cute quand une jail se d\u00e9clenche, le plus souvent un bannissement au pare-feu. Vous configurez les seuils via trois param\u00e8tres cl\u00e9s : maxretry<\/code> (nombre d’\u00e9checs tol\u00e9r\u00e9s), findtime<\/code> (la fen\u00eatre d’observation) et bantime<\/code> (la dur\u00e9e du bannissement).<\/p>\n\n\n\n

La version stable actuelle est Fail2ban 1.1.0, publi\u00e9e en 2024, avec une pr\u00e9version 1.1.1.beta0 disponible en amont mais non recommand\u00e9e en production. Le projet est mature, pr\u00e9sent dans les d\u00e9p\u00f4ts de quasiment toutes les distributions Linux, et reste l’outil de r\u00e9f\u00e9rence pour la protection d’un h\u00f4te unique. Contrairement \u00e0 des syst\u00e8mes plus lourds, il ne d\u00e9pend d’aucun service cloud : tout se passe localement sur votre machine, ce qui en fait un choix id\u00e9al pour un VPS, un serveur d\u00e9di\u00e9 ou un Raspberry Pi auto-h\u00e9berg\u00e9.<\/p>\n\n\n\n

Fail2ban n’est pas un pare-feu en soi : il pilote votre pare-feu existant. Il ne remplace pas non plus une bonne hygi\u00e8ne de s\u00e9curit\u00e9. D\u00e9sactiver l’authentification par mot de passe au profit des cl\u00e9s SSH, changer le port d’\u00e9coute et maintenir le syst\u00e8me \u00e0 jour restent indispensables. Fail2ban ajoute une couche d’automatisation qui transforme un flot continu d’attaques en quelques lignes de journal sans cons\u00e9quence.<\/p>\n\n\n\n

Pr\u00e9requis et versions logicielles<\/h2>\n\n\n\n

Avant d’installer Fail2ban, assurez-vous de disposer de l’environnement suivant. Toutes les commandes de ce tutoriel supposent un acc\u00e8s root ou sudo<\/code> et un serveur accessible en SSH.<\/p>\n\n\n\n

Composant<\/th>Version requise<\/th>V\u00e9rification<\/th><\/tr><\/thead>
Syst\u00e8me<\/td>Debian 12 (Bookworm) ou Ubuntu 24.04 LTS<\/td>cat \/etc\/os-release<\/code><\/td><\/tr>
Fail2ban<\/td>1.0.2 ou sup\u00e9rieur (1.1.0 recommand\u00e9)<\/td>fail2ban-client --version<\/code><\/td><\/tr>
Python<\/td>3.9 ou sup\u00e9rieur (fourni par le syst\u00e8me)<\/td>python3 --version<\/code><\/td><\/tr>
Pare-feu<\/td>nftables (par d\u00e9faut) ou iptables<\/td>nft --version<\/code><\/td><\/tr>
Service de journal<\/td>systemd-journald<\/td>systemctl status systemd-journald<\/code><\/td><\/tr>
Acc\u00e8s<\/td>compte root ou sudo<\/td>sudo -v<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Sur Debian 12 et Ubuntu 24.04, le pare-feu par d\u00e9faut est nftables, et les journaux d’authentification SSH passent par le journal systemd. Ces deux points modifient la configuration fail2ban<\/strong> moderne par rapport aux anciens guides qui supposaient iptables et \/var\/log\/auth.log<\/code>. Nous traiterons les deux cas, mais nous privil\u00e9gierons les r\u00e9glages adapt\u00e9s aux distributions r\u00e9centes.<\/p>\n\n\n\n

Un dernier conseil avant de commencer : ouvrez une seconde session SSH<\/strong> en parall\u00e8le et gardez-la connect\u00e9e pendant toute la dur\u00e9e de la configuration. Une erreur de r\u00e9glage peut vous bannir vous-m\u00eame. Cette session de secours vous \u00e9vitera de perdre l’acc\u00e8s \u00e0 votre propre serveur, un pi\u00e8ge que nous d\u00e9taillerons plus loin.<\/p>\n\n\n\n

\u00c9tapes 1 et 2 : Installer Fail2ban sur Debian et Ubuntu<\/h2>\n\n\n\n

\u00c9tape 1.<\/strong> Mettez \u00e0 jour la liste des paquets puis lancez l’installation. Pour installer fail2ban<\/strong> depuis les d\u00e9p\u00f4ts officiels, une seule commande suffit :<\/p>\n\n\n\n

# Mettre \u00e0 jour l'index des paquets\nsudo apt update\n\n# Installer Fail2ban (tire automatiquement les d\u00e9pendances Python)\nsudo apt install -y fail2ban\n\n# V\u00e9rifier la version install\u00e9e\nfail2ban-client --version<\/code><\/pre>\n\n\n\n
La sortie attendue ressemble \u00e0 Fail2Ban v1.0.2<\/code> sur Debian 12 ou une version sup\u00e9rieure sur Ubuntu 24.04. Si vous voulez imp\u00e9rativement la 1.1.0, vous pouvez la compiler depuis les sources GitHub, mais la version des d\u00e9p\u00f4ts est largement suffisante pour un usage normal et re\u00e7oit les correctifs de s\u00e9curit\u00e9 de la distribution.<\/p>\n\n\n\n
\u00c9tape 2.<\/strong> V\u00e9rifiez que le service est actif. Sur Debian et Ubuntu, le paquet active et d\u00e9marre Fail2ban automatiquement apr\u00e8s l’installation.<\/p>\n\n\n\n
# \u00c9tat du service\nsudo systemctl status fail2ban\n\n# L'activer au d\u00e9marrage si n\u00e9cessaire\nsudo systemctl enable --now fail2ban<\/code><\/pre>\n\n\n\n
Vous devriez voir active (running)<\/code> en vert. \u00c0 ce stade, Fail2ban fonctionne d\u00e9j\u00e0 avec sa configuration par d\u00e9faut, qui inclut une jail sshd<\/code> de base sur la plupart des installations. Mais ne vous arr\u00eatez pas l\u00e0 : la configuration par d\u00e9faut est volontairement prudente, et nous allons la durcir dans les \u00e9tapes suivantes. Ne modifiez jamais directement les fichiers fournis par le paquet, car une mise \u00e0 jour les \u00e9craserait sans pr\u00e9avis.<\/p>\n\n\n\n
\u00c9tapes 3 et 4 : Comprendre jail.conf et jail.local<\/h2>\n\n\n\n
Toute la configuration de Fail2ban vit dans \/etc\/fail2ban\/<\/code>. Le fichier jail.conf<\/code> contient les r\u00e9glages par d\u00e9faut livr\u00e9s par le paquet. La r\u00e8gle d’or, r\u00e9p\u00e9t\u00e9e dans toute la documentation officielle : ne modifiez jamais jail.conf<\/strong>. Vos changements y seraient effac\u00e9s \u00e0 la prochaine mise \u00e0 jour. \u00c0 la place, cr\u00e9ez un fichier jail.local<\/code> qui surcharge uniquement les valeurs que vous voulez changer.<\/p>\n\n\n\n
\u00c9tape 3.<\/strong> Explorez l’arborescence de configuration pour comprendre o\u00f9 vont les choses :<\/p>\n\n\n\n
\/etc\/fail2ban\/\njail.conf          # R\u00e9glages par d\u00e9faut (NE PAS MODIFIER)\njail.local         # Vos surcharges (\u00e0 cr\u00e9er)\njail.d\/            # Fichiers de jails additionnels (.local ou .conf)\nfail2ban.conf      # R\u00e9glages du d\u00e9mon (niveau de log, socket)\nfilter.d\/          # Expressions r\u00e9guli\u00e8res par service (sshd.conf, etc.)\naction.d\/          # D\u00e9finitions d'actions (nftables, iptables, mail)<\/code><\/pre>\n\n\n\n
\u00c9tape 4.<\/strong> Cr\u00e9ez votre fichier jail.local<\/code>. Plut\u00f4t que de copier l’int\u00e9gralit\u00e9 de jail.conf<\/code> (une mauvaise pratique qui rend les mises \u00e0 jour confuses), partez d’un fichier minimal qui ne contient que vos surcharges. Ouvrez-le avec votre \u00e9diteur :<\/p>\n\n\n\n
sudo nano \/etc\/fail2ban\/jail.local<\/code><\/pre>\n\n\n\n
Nous remplirons ce fichier dans les \u00e9tapes suivantes. Sachez que la section [DEFAULT]<\/code> d\u00e9finit les valeurs globales appliqu\u00e9es \u00e0 toutes les jails, tandis que chaque section nomm\u00e9e comme [sshd]<\/code> ne configure qu’un service pr\u00e9cis et peut surcharger les valeurs globales. Cette hi\u00e9rarchie est au c\u0153ur d’une configuration fail2ban<\/strong> propre et maintenable.<\/p>\n\n\n\n
\u00c9tape 5 : Configurer la jail sshd (bantime, findtime, maxretry)<\/h2>\n\n\n\n
C’est le c\u0153ur de la protection SSH. Trois param\u00e8tres gouvernent le comportement de bannissement. Voici leurs valeurs par d\u00e9faut dans Fail2ban et des recommandations durcies pour un serveur de production.<\/p>\n\n\n\n
Param\u00e8tre<\/th>D\u00e9faut Fail2ban<\/th>Recommand\u00e9<\/th>R\u00f4le<\/th><\/tr><\/thead>
maxretry<\/code><\/td>5<\/td>3<\/td>\u00c9checs tol\u00e9r\u00e9s avant bannissement<\/td><\/tr>
findtime<\/code><\/td>10m (600 s)<\/td>10m<\/td>Fen\u00eatre o\u00f9 l’on compte les \u00e9checs<\/td><\/tr>
bantime<\/code><\/td>10m (600 s)<\/td>1h ou plus<\/td>Dur\u00e9e du bannissement<\/td><\/tr>
ignoreip<\/code><\/td>127.0.0.1\/8 ::1<\/td>+ votre IP fixe<\/td>Adresses jamais bannies<\/td><\/tr>
bantime.increment<\/code><\/td>false<\/td>true<\/td>Allonge la peine des r\u00e9cidivistes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Renseignez maintenant votre jail.local<\/code> avec une section globale et une jail sshd<\/code> durcie. Voici un bloc fonctionnel \u00e0 coller :<\/p>\n\n\n\n
[DEFAULT]\n# Bannir pour 1 heure apr\u00e8s 3 \u00e9checs en 10 minutes\nbantime  = 1h\nfindtime = 10m\nmaxretry = 3\n\n# Allonger automatiquement la peine des r\u00e9cidivistes\nbantime.increment = true\nbantime.factor    = 2\nbantime.maxtime   = 1w\n\n# Ne jamais bannir le r\u00e9seau local ni votre IP d'admin\nignoreip = 127.0.0.1\/8 ::1 203.0.113.10\n\n[sshd]\nenabled  = true\nport     = ssh\nmaxretry = 3<\/code><\/pre>\n\n\n\n
Remplacez 203.0.113.10<\/code> par votre adresse IP fixe r\u00e9elle. Le param\u00e8tre bantime.increment = true<\/code> est l’un des r\u00e9glages les plus utiles : un attaquant banni une premi\u00e8re fois pour 1 heure le sera pour 2 heures \u00e0 la r\u00e9cidive, puis 4 heures, et ainsi de suite jusqu’au plafond bantime.maxtime<\/code> d’une semaine. Cette escalade d\u00e9courage les robots persistants sans bloquer d\u00e9finitivement une IP qui pourrait, plus tard, \u00eatre r\u00e9attribu\u00e9e \u00e0 un utilisateur l\u00e9gitime.<\/p>\n\n\n\n
\u00c9tape 6 : Choisir le backend (systemd ou auth.log)<\/h2>\n\n\n\n
Le backend<\/code> indique \u00e0 Fail2ban o\u00f9 lire les \u00e9v\u00e9nements d’authentification. C’est un point de bascule majeur entre les anciens et les nouveaux syst\u00e8mes. Sur Debian 12 et Ubuntu 24.04, les messages SSH sont \u00e9crits dans le journal systemd, pas forc\u00e9ment dans un fichier \/var\/log\/auth.log<\/code>. Si vous utilisez le mauvais backend, Fail2ban ne verra aucun \u00e9chec et ne bannira personne, alors m\u00eame que le service tourne.<\/p>\n\n\n\n
[sshd]\nenabled = true\nport    = ssh\n# Lire directement le journal systemd (recommand\u00e9 sur Debian 12 \/ Ubuntu 24.04)\nbackend = systemd\nmaxretry = 3<\/code><\/pre>\n\n\n\n
Si votre serveur \u00e9crit toujours \/var\/log\/auth.log<\/code> (certaines installations conservent rsyslog), vous pouvez \u00e0 la place pointer un chemin de fichier :<\/p>\n\n\n\n
[sshd]\nenabled  = true\nbackend  = auto\nlogpath  = \/var\/log\/auth.log\nmaxretry = 3<\/code><\/pre>\n\n\n\n
Le r\u00e9glage backend = auto<\/code> tente de d\u00e9tecter la meilleure source, mais sur les distributions r\u00e9centes il est plus fiable de forcer backend = systemd<\/code>. Pour v\u00e9rifier o\u00f9 atterrissent r\u00e9ellement vos journaux SSH, lancez journalctl -u ssh -n 20<\/code> : si des lignes apparaissent, le journal systemd est bien la bonne source. Ce diagnostic r\u00e9sout \u00e0 lui seul la majorit\u00e9 des cas o\u00f9 \u00ab Fail2ban ne bannit rien \u00bb.<\/p>\n\n\n\n
\u00c9tape 7 : Choisir l’action de bannissement (nftables ou iptables)<\/h2>\n\n\n\n
Le banaction<\/code> d\u00e9termine comment Fail2ban ins\u00e8re le blocage dans votre pare-feu. Sur Debian moderne, le pare-feu par d\u00e9faut est nftables, et Fail2ban doit lui parler dans son propre langage. Utiliser une action iptables sur un syst\u00e8me nftables peut sembler fonctionner mais provoquer des incoh\u00e9rences. Forcez l’action adapt\u00e9e dans la section [DEFAULT]<\/code> :<\/p>\n\n\n\n
[DEFAULT]\n# Bannir via nftables, le pare-feu par d\u00e9faut de Debian 12 \/ Ubuntu 24.04\nbanaction          = nftables-multiport\nbanaction_allports = nftables-allports\n# Cha\u00eene de filtrage des connexions entrantes\nchain              = input<\/code><\/pre>\n\n\n\n
banaction<\/th>Pare-feu<\/th>Quand l’utiliser<\/th><\/tr><\/thead>
nftables-multiport<\/code><\/td>nftables<\/td>Debian 12, Ubuntu 24.04, syst\u00e8mes r\u00e9cents<\/td><\/tr>
nftables-allports<\/code><\/td>nftables<\/td>Bloquer tous les ports d’une IP<\/td><\/tr>
iptables-multiport<\/code><\/td>iptables<\/td>Syst\u00e8mes h\u00e9rit\u00e9s ou conteneurs anciens<\/td><\/tr>
ufw<\/code><\/td>UFW<\/td>Serveurs g\u00e9r\u00e9s via UFW<\/td><\/tr>
route<\/code><\/td>table de routage<\/td>Sans pare-feu, blocage par route nulle<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Si vous g\u00e9rez votre pare-feu avec UFW (fr\u00e9quent sur Ubuntu), r\u00e9glez banaction = ufw<\/code> pour que les bannissements apparaissent dans les r\u00e8gles UFW et restent coh\u00e9rents. V\u00e9rifiez ensuite que le pare-feu refl\u00e8te bien les actions de Fail2ban, sinon vous obtiendrez des r\u00e8gles fant\u00f4mes que rien ne supprime.<\/p>\n\n\n\n
\u00c9tape 8 : Appliquer et piloter avec fail2ban-client<\/h2>\n\n\n\n
fail2ban-client<\/code> est l’outil en ligne de commande qui pilote le d\u00e9mon. Apr\u00e8s chaque modification de configuration, rechargez sans red\u00e9marrer pour ne pas perdre les bannissements en cours.<\/p>\n\n\n\n
# Tester la syntaxe de la configuration avant d'appliquer\nsudo fail2ban-client -t\n\n# Recharger la configuration (sans couper les bannissements actifs)\nsudo fail2ban-client reload\n\n# Voir toutes les jails actives\nsudo fail2ban-client status\n\n# D\u00e9tail d'une jail pr\u00e9cise\nsudo fail2ban-client status sshd<\/code><\/pre>\n\n\n\n
La commande fail2ban-client status sshd<\/code> produit une sortie comme celle-ci, qui r\u00e9sume l’\u00e9tat de la surveillance :<\/p>\n\n\n\n
Status for the jail: sshd\n|- Filter\n|  |- Currently failed: 2\n|  |- Total failed:     147\n|  `- File list:        \/var\/log\/auth.log\n`- Actions\n   |- Currently banned: 3\n   |- Total banned:     19\n   `- Banned IP list:   185.142.236.34 218.92.0.112 92.118.39.88<\/code><\/pre>\n\n\n\n
Les compteurs Total failed<\/code> et Total banned<\/code> grimpent vite sur un serveur expos\u00e9, preuve concr\u00e8te que Fail2ban travaille. M\u00e9morisez aussi deux commandes de gestion manuelle : fail2ban-client set sshd unbanip 185.142.236.34<\/code> pour lib\u00e9rer une IP injustement bloqu\u00e9e, et fail2ban-client set sshd banip 1.2.3.4<\/code> pour bannir manuellement une adresse hostile.<\/p>\n\n\n\n
\u00c9tape 9 : Tester le bannissement en conditions r\u00e9elles<\/h2>\n\n\n\n
Ne supposez jamais qu’une protection fonctionne sans la tester. Depuis une machine ext\u00e9rieure (jamais celle list\u00e9e dans ignoreip<\/code>), provoquez d\u00e9lib\u00e9r\u00e9ment des \u00e9checs SSH. Le moyen le plus propre est de tenter quelques connexions avec un utilisateur inexistant.<\/p>\n\n\n\n
# Depuis une autre machine, tenter 4 connexions avec un faux compte\nssh utilisateur-inexistant@VOTRE_SERVEUR\n# (r\u00e9p\u00e9ter, en saisissant n'importe quel mot de passe, jusqu'au bannissement)\n\n# Sur le serveur, v\u00e9rifier que l'IP a bien \u00e9t\u00e9 bannie\nsudo fail2ban-client status sshd\n\n# Inspecter la r\u00e8gle nftables cr\u00e9\u00e9e par Fail2ban\nsudo nft list ruleset | grep -A4 f2b<\/code><\/pre>\n\n\n\n
Apr\u00e8s le quatri\u00e8me \u00e9chec, votre machine de test ne doit plus pouvoir se connecter : la connexion expire ou est refus\u00e9e imm\u00e9diatement. Dans le journal du serveur, vous verrez une ligne de bannissement explicite :<\/p>\n\n\n\n
fail2ban.actions [1234]: NOTICE  [sshd] Ban 203.0.113.55\nfail2ban.actions [1234]: NOTICE  [sshd] 203.0.113.55 already banned<\/code><\/pre>\n\n\n\n
Pour lever le bannissement de test, ex\u00e9cutez sudo fail2ban-client set sshd unbanip 203.0.113.55<\/code>. Ce test de bout en bout est la seule preuve fiable que votre filtre, votre backend et votre banaction<\/code> fonctionnent ensemble. Beaucoup d’administrateurs croient \u00eatre prot\u00e9g\u00e9s alors qu’une simple incompatibilit\u00e9 de backend laisse passer toutes les attaques.<\/p>\n\n\n\n
\u00c9tape 10 : Prot\u00e9ger vos propres acc\u00e8s avec ignoreip<\/h2>\n\n\n\n
Le pi\u00e8ge le plus douloureux de Fail2ban consiste \u00e0 se bannir soi-m\u00eame. Si vous tapez plusieurs fois un mauvais mot de passe ou si votre client de sauvegarde \u00e9choue en boucle, votre propre IP rejoint la liste noire et vous perdez l’acc\u00e8s au serveur. La parade est la directive ignoreip<\/code>, qui d\u00e9finit une liste blanche d’adresses jamais bannies.<\/p>\n\n\n\n
[DEFAULT]\n# R\u00e9seau local, IPv6 locale, votre IP fixe, et un sous-r\u00e9seau d'entreprise\nignoreip = 127.0.0.1\/8 ::1 203.0.113.10 198.51.100.0\/24<\/code><\/pre>\n\n\n\n
Vous pouvez lister des adresses uniques, des plages CIDR, et m\u00eame des noms d’h\u00f4te (Fail2ban les r\u00e9sout au d\u00e9marrage). 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. \u00c9vitez en revanche de mettre en liste blanche des plages enti\u00e8res d’op\u00e9rateurs mobiles, car cela ouvrirait une br\u00e8che b\u00e9ante. Apr\u00e8s modification, rechargez avec sudo fail2ban-client reload<\/code> pour que la liste blanche prenne effet.<\/p>\n\n\n\n
\u00c9tape 11 : Activer la jail recidive contre les r\u00e9cidivistes<\/h2>\n\n\n\n
La jail recidive<\/code> surveille le propre journal de Fail2ban et bannit pour tr\u00e8s longtemps les adresses qui se font bannir de fa\u00e7on r\u00e9p\u00e9t\u00e9e. C’est la sanction des robots les plus tenaces : une IP bannie plusieurs fois en quelques jours est mise \u00e0 l’\u00e9cart pour une semaine enti\u00e8re, tous services confondus. Activez-la dans jail.local<\/code> :<\/p>\n\n\n\n
[recidive]\nenabled   = true\nlogpath   = \/var\/log\/fail2ban.log\nbanaction = nftables-allports\nbantime   = 1w\nfindtime  = 1d\nmaxretry  = 5<\/code><\/pre>\n\n\n\n
Ici, une IP bannie cinq fois en une journ\u00e9e (findtime = 1d<\/code>) est bloqu\u00e9e une semaine (bantime = 1w<\/code>) sur tous les ports gr\u00e2ce \u00e0 nftables-allports<\/code>. Comme la jail recidive<\/code> lit \/var\/log\/fail2ban.log<\/code>, assurez-vous que la journalisation vers ce fichier est active (c’est le cas par d\u00e9faut sur Debian et Ubuntu). Si vous avez activ\u00e9 bantime.increment<\/code> \u00e0 l’\u00e9tape 5, la jail recidive<\/code> vient compl\u00e9ter cette escalade en frappant les cas extr\u00eames encore plus fort.<\/p>\n\n\n\n
\u00c9tape 12 : Recevoir des notifications par e-mail<\/h2>\n\n\n\n
Pour rester inform\u00e9 sans surveiller les journaux en permanence, configurez l’envoi d’un e-mail \u00e0 chaque bannissement. Vous aurez besoin d’un agent de transport de courrier (comme postfix<\/code> en mode satellite ou msmtp<\/code>) d\u00e9j\u00e0 capable d’envoyer du courriel depuis le serveur.<\/p>\n\n\n\n
[DEFAULT]\n# Adresses d'envoi et de r\u00e9ception des alertes\ndestemail = admin@votre-domaine.fr\nsender    = fail2ban@votre-domaine.fr\nmta       = sendmail\n\n# Action : bannir ET envoyer un mail avec les lignes de journal\naction = %(action_mwl)s<\/code><\/pre>\n\n\n\n
L’action action_mwl<\/code> 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\u00e9faut action_<\/code>. Pour un volume d’attaques \u00e9lev\u00e9, attention \u00e0 ne pas vous noyer sous les e-mails : sur un serveur expos\u00e9, des centaines de bannissements quotidiens transformeraient vite cette alerte en bruit. R\u00e9servez les notifications aux jails critiques ou agr\u00e9gez-les via un outil de supervision.<\/p>\n\n\n\n
Le projet complet : un jail.local pr\u00eat pour la production<\/h2>\n\n\n\n
Voici un fichier \/etc\/fail2ban\/jail.local<\/code> complet, regroupant tous les r\u00e9glages de ce tutoriel. Il prot\u00e8ge SSH, durcit les seuils, escalade les peines, active la jail recidive<\/code> et inclut deux jails web courantes (\u00e0 n’activer que si vous faites tourner Nginx). Adaptez les adresses IP et le domaine, puis collez-le tel quel.<\/p>\n\n\n\n
[DEFAULT]\n# --- Politique globale de bannissement ---\nbantime  = 1h\nfindtime = 10m\nmaxretry = 3\n\n# Escalade automatique des peines pour les recidivistes\nbantime.increment = true\nbantime.factor    = 2\nbantime.maxtime   = 1w\n\n# Liste blanche : local + votre IP d'administration fixe\nignoreip = 127.0.0.1\/8 ::1 203.0.113.10\n\n# Pare-feu et source des journaux pour Debian 12 \/ Ubuntu 24.04\nbanaction          = nftables-multiport\nbanaction_allports = nftables-allports\nbackend            = systemd\n\n# Notifications (optionnel : necessite un MTA fonctionnel)\ndestemail = admin@votre-domaine.fr\nsender    = fail2ban@votre-domaine.fr\nmta       = sendmail\naction    = %(action_)s\n\n# --- Protection SSH ---\n[sshd]\nenabled  = true\nport     = ssh\nmaxretry = 3\n\n# --- Recidivistes (tous services) ---\n[recidive]\nenabled   = true\nlogpath   = \/var\/log\/fail2ban.log\nbanaction = nftables-allports\nbantime   = 1w\nfindtime  = 1d\nmaxretry  = 5\n\n# --- Nginx : echecs d'authentification HTTP (si applicable) ---\n[nginx-http-auth]\nenabled  = true\nport     = http,https\nbackend  = systemd\n\n# --- Nginx : recherche de scripts malveillants (si applicable) ---\n[nginx-botsearch]\nenabled  = true\nport     = http,https\nbackend  = systemd<\/code><\/pre>\n\n\n\n
Appliquez ce fichier en deux temps : testez d’abord la syntaxe avec sudo fail2ban-client -t<\/code>, puis rechargez avec sudo fail2ban-client reload<\/code>. Confirmez ensuite que toutes les jails attendues sont charg\u00e9es via sudo fail2ban-client status<\/code>. Vous disposez d\u00e9sormais d’une configuration fail2ban<\/strong> robuste, pr\u00eate \u00e0 encaisser le trafic d’attaque permanent d’Internet.<\/p>\n\n\n\n
Cinq pi\u00e8ges courants \u00e0 \u00e9viter<\/h2>\n\n\n\n
La plupart des configurations Fail2ban qui \u00ab ne fonctionnent pas \u00bb se r\u00e9sument \u00e0 une poign\u00e9e d’erreurs r\u00e9currentes. Les voici, avec leur correctif.<\/p>\n\n\n\n