Fail2ban Ubuntu 24.04 : stopper les attaques SSH

Ce que fait vraiment Fail2ban

Fail2ban est un démon qui lit les journaux. Il surveille les messages d'authentification SSH et, après une poignée d'échecs venant d'une même adresse dans un court laps de temps, exécute une commande de pare-feu qui bloque cette adresse pendant un moment. C'est toute l'idée. Cela représente environ trente lignes de configuration dans un seul fichier, et sur Ubuntu 24.04 l'installation tient en une seule commande apt qui vous protège avant même que vous ayez modifié quoi que ce soit.

Soyez au clair sur ce qu'il est et ce qu'il n'est pas. Fail2ban n'authentifie personne, ne chiffre rien, et n'arrête pas une seule tentative de connexion déterminée : seulement les tentatives répétées venant de la même source. C'est un filtre à bruit et un limiteur de débit, pas un verrou. Son rôle est de faire cesser le balayage de fond permanent du port 22 qui gaspille votre CPU, votre bande passante et votre espace de journaux, et de ralentir tout attaquant obligé de venir depuis une seule adresse à la fois.

Ce que Fail2ban ne remplace pas

Fail2ban est la troisième couche, pas la première. Si votre serveur accepte encore les mots de passe SSH, un botnet réparti sur des milliers d'adresses peut continuer à deviner, car chaque adresse reste sous votre seuil de bannissement et ne le déclenche jamais. La vraie défense contre cela, c'est l'authentification par clé uniquement, qui rend le devinage de mot de passe impossible quel que soit le nombre de tentatives. Fail2ban par-dessus l'authentification par clé fait deux choses utiles : il élague le bruit des attaques par force brute de vos journaux, et il expulse les scanners tôt pour qu'ils cessent de marteler le port. Considérez-le comme une défense en profondeur. Il se place derrière l'authentification par clé et derrière un pare-feu, jamais devant eux.

Prérequis, et la réalité d'Ubuntu 24.04

Il vous faut un VPS sous Ubuntu 24.04 avec root ou sudo, et SSH déjà fonctionnel, idéalement en authentification par clé. Fail2ban est frugal : quelques dizaines de mégaoctets de RAM, aucun réglage de limites requis.

Voici maintenant le point sur lequel tous les anciens guides se trompent. Pendant des années, le conseil standard était « installez Fail2ban, puis ajoutez backend = systemd, car Ubuntu a cessé d'écrire /var/log/auth.log. » Ce conseil décrit un vrai changement : les images serveur et cloud modernes sont livrées sans rsyslog, donc SSH ne journalise plus que dans le journal systemd et ce fichier texte a disparu. Mais sur Ubuntu 24.04, le paquet Fail2ban en tient déjà compte. Le paquet dépose /etc/fail2ban/jail.d/defaults-debian.conf, et c'est ce fichier, et non les valeurs par défaut en amont, que votre serveur exécute réellement :

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

Lisez ceci attentivement, car cela règle deux questions avant même que vous touchiez à quoi que ce soit. backend = systemd signifie que la prison SSH lit le journal, donc l'absence d'auth.log n'a aucune importance. banaction = nftables signifie que les bannissements sont appliqués via nftables, le pare-feu qu'Ubuntu 24.04 utilise réellement, plutôt que l'ancien iptables. Et [sshd] enabled = true signifie que la prison est active dès le premier démarrage. En résumé : un apt install fail2ban standard sur Ubuntu 24.04 bannit d'emblée les attaques SSH par force brute. L'essentiel de votre travail consiste à le confirmer, à ajuster la politique, et à vous assurer que vous ne pouvez pas vous verrouiller dehors.

Le vieux piège de l'auth.log mord encore dans trois situations, et il vaut la peine de les reconnaître : vous avez installé Fail2ban avec pip au lieu d'apt, il n'y a donc pas de defaults-debian.conf ; vous êtes à l'intérieur d'un conteneur non privilégié sans journal systemd à lire ; ou vous avez suivi un vieux tutoriel et collé backend = auto dans votre propre jail.local, écrasant la valeur par défaut qui fonctionnait. La section sur les modes de défaillance montre exactement à quoi ressemble chacun.

Étape 1 : installer et confirmer qu'il bannit déjà

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 fournit Fail2ban 1.0.2, et le paquet tire python3-systemd comme dépendance obligatoire, donc le backend journal a tout ce qu'il lui faut. Le service s'active et se démarre tout seul :

sudo systemctl status fail2ban

Vous voulez voir active (running). Regardez ensuite la prison qui fait déjà son travail :

sudo fail2ban-client status sshd

Sur un VPS public accessible depuis ne serait-ce que quelques minutes, vous verrez souvent déjà des échecs comptabilisés et des adresses bannies : internet balaie le port 22 en permanence. C'est la preuve que la configuration standard fonctionne. À partir d'ici, vous l'affinez, vous ne la construisez pas à partir de rien.

Étape 2 : modifier jail.local, jamais jail.conf

Fail2ban conserve ses valeurs par défaut en amont dans /etc/fail2ban/jail.conf. Ne modifiez pas ce fichier. Chaque apt upgrade du paquet peut le remplacer, et vos changements disparaissent sans avertissement. Fail2ban lit les fichiers dans un ordre fixe : d'abord jail.conf, puis tout ce qui se trouve dans jail.d/, puis jail.local, et la dernière valeur l'emporte. Le fichier .local est le vôtre, et les mises à jour du paquet n'y touchent jamais. La même règle s'applique aux filtres, où un fichier *.local écrase le filter.d/*.conf livré.

Vous écrivez donc un petit jail.local qui ne surcharge que la poignée de réglages qui vous importent, et vous laissez jail.conf comme le jail.d/defaults-debian.conf du paquet intacts, à titre de référence.

Étape 3 : écrire /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Mettez-y ceci, en remplaçant l'adresse de la ligne ignoreip par votre propre IP publique :

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

Chaque ligne a sa raison d'être :

• bantime, findtime, maxretry sont la politique. Le bantime par défaut livré n'est que de dix minutes ; une heure est un plancher plus raisonnable. Cinq échecs venant d'une même adresse en dix minutes valent le bannissement. Une vraie personne se trompe de mot de passe une ou deux fois ; cinq échecs en dix minutes, c'est un script.
• ignoreip est votre ceinture de sécurité. Mettez-y l'adresse publique depuis laquelle vous vous connectez, pour que Fail2ban ne puisse jamais vous verrouiller hors de votre propre serveur. Une connexion domestique dont l'IP change est une raison de préférer l'approche VPN présentée à la fin, pas une raison de sauter cette ligne.
• bantime.increment = true rend chaque bannissement répété plus long que le précédent : une heure, puis deux, puis quatre, jusqu'à bantime.maxtime. Les adresses qui reviennent sans cesse se retrouvent verrouillées de plus en plus longtemps.

Trouvez l'adresse à mettre en liste blanche depuis la machine depuis laquelle vous faites du SSH, pas depuis le serveur :

curl -s ifconfig.me

Vous pouvez générer ici un jail.local ajusté à vos ports et à votre politique de bannissement, puis le coller dans le fichier :

Étape 4 : redémarrer et vérifier qu'il lit le journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Le -t lance d'abord un test de configuration, de sorte qu'une faute de frappe dans jail.local échoue bruyamment ici au lieu de laisser le service mort. Un statut de prison sain ressemble à ceci :

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

Le nombre qui prouve que Fail2ban lit véritablement vos connexions est Total failed. S'il est supérieur à zéro, ou s'il grimpe lorsque vous échouez volontairement une connexion depuis une autre machine, le journal est bien lu et vous avez terminé. S'il reste à 0 quel que soit le nombre d'échecs, et que vous êtes sûr de ne pas tester depuis l'adresse présente dans ignoreip, passez aux modes de défaillance ci-dessous.

Remarquez que la ligne Journal matches nomme toujours sshd.service. Sur Ubuntu, l'unité SSH est en réalité ssh.service, mais le filtre livré correspond aussi à _COMM=sshd, et OpenSSH sur 24.04 journalise ses échecs depuis un processus nommé sshd, donc la correspondance fonctionne. Ce détail ne compte que si vous êtes sur un OpenSSH plus récent (9.8 ou ultérieur, où le processus par connexion est sshd-session) ; les modes de défaillance couvrent ce cas.

Étape 5 : observer un vrai bannissement, ou en forcer un pour tester

De vrais bannissements arrivent d'eux-mêmes en quelques minutes sur n'importe quel VPS public. Pour en observer un, suivez le journal avec tail :

sudo tail -f /var/log/fail2ban.log

Un bannissement ressemble à ceci :

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

Pour prouver le mécanisme de bout en bout sans attendre, bannissez à la main une adresse de documentation, jamais la vôtre :

sudo fail2ban-client set sshd banip 10.0.0.66

Elle affiche 1, et l'adresse apparaît sous Banned IP list dans fail2ban-client status sshd. Confirmez maintenant que le blocage existe réellement dans le pare-feu. Sur Ubuntu 24.04, c'est nftables, pas iptables :

sudo nft list table inet f2b-table

Vous verrez un ensemble nommé addr-set-sshd contenant 10.0.0.66, et une chaîne f2b-chain qui rejette toute source présente dans cet ensemble. Si fail2ban-client indique qu'une adresse est bannie mais que rien n'apparaît dans nft list, votre action de bannissement ne correspond pas à votre pare-feu ; voyez la note nftables/iptables dans les modes de défaillance.

Étape 6 : se débannir, et récupérer si vous êtes verrouillé dehors

Si vous avez banni une adresse que vous n'auriez pas dû, la vôtre, retirez-la :

sudo fail2ban-client set sshd unbanip 10.0.0.66

Elle renvoie 1 en cas de succès. Pour effacer tous les bannissements de toutes les prisons :

sudo fail2ban-client unban --all

Ne comptez pas sur une session SSH déjà ouverte pour vous sauver : le bannissement nftables rejette chaque paquet venant de l'adresse bannie vers le port 22, connexions établies comprises, donc une session existante se fige à l'instant où le bannissement tombe. Si vous vous bannissez vous-même sans entrée ignoreip, vous êtes verrouillé dehors jusqu'à l'expiration du bannissement : récupérez via la console web de votre hébergeur (VNC ou série), qui ne passe pas par SSH, et attendez la fin du bantime ou lancez-y la commande de débannissement.

Étape 7 : rendre les bannissements persistants et progressifs

Fail2ban conserve les bannissements actifs dans une petite base SQLite à /var/lib/fail2ban/fail2ban.sqlite3, ils survivent donc à un redémarrage du service ou de la machine ; vous ne les perdez pas. Les lignes bantime.increment que vous avez déjà ajoutées transforment chaque récidiviste en un problème croissant pour lui-même, doublant à peu près d'une heure vers une semaine.

Pour une politique « trois avertissements » à l'échelle du système par-dessus cela, Fail2ban fournit une prison recidive qui surveille son propre /var/log/fail2ban.log et distribue de longs bannissements à toute adresse bannie à répétition dans l'ensemble des prisons. Comme votre [DEFAULT] utilise désormais le backend systemd, réancrez cette prison sur le fichier de journal qu'elle est conçue pour lire :

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

backend = auto avec le logpath explicite maintient recidive sur la lecture du simple fail2ban.log, là où apparaissent réellement les lignes Ban qu'elle compte ; la valeur systemd par défaut que vous avez définie globalement la pointerait vers le journal, où elles n'apparaissent pas.

Étape 8 : l'associer à un SSH par clé uniquement, et mieux encore à un VPN

Fail2ban ne justifie sa place qu'aux côtés de l'authentification par clé. Dans un fichier drop-in sous /etc/ssh/sshd_config.d/, disons /etc/ssh/sshd_config.d/00-hardening.conf, définissez :

PasswordAuthentication no
KbdInteractiveAuthentication no

Puis sudo systemctl restart ssh. Avec les mots de passe désactivés, la force brute ne peut tout simplement pas aboutir ; Fail2ban sert alors à couper le bruit des journaux et à expulser les scanners tôt. Plus fort encore : gardez SSH totalement hors de l'internet public : placez SSH derrière un VPN WireGuard auto-hébergé et filtrez le port 22 pour qu'il ne réponde que sur le tunnel. Personne ne peut forcer par force brute un port qu'il ne peut pas atteindre, et Fail2ban devient un filet de sécurité plutôt qu'une ligne de front.

Fail2ban n'est pas réservé à SSH. Tout service qui journalise des échecs de connexion peut recevoir une prison : un serveur de messagerie, un site nginx, ou un gestionnaire de mots de passe Vaultwarden auto-hébergé dont vous préférez ne pas laisser la connexion web ouverte au bourrage d'identifiants. Une fois qu'une application web se trouve derrière un site nginx avec un certificat Let's Encrypt, pointez un filtre Fail2ban vers son journal d'accès de la même façon que la prison SSH pointe vers le journal.

Modes de défaillance, avec les chaînes exactes que vous verrez

« Have not found any log file for sshd jail », et Fail2ban ne démarre pas. C'est le vieux problème de l'auth.log, et sur Ubuntu 24.04 vous ne le rencontrez que si quelque chose a écrasé la valeur par défaut du paquet : une installation pip sans defaults-debian.conf, un conteneur sans journal, ou un backend = auto égaré que vous avez collé dans jail.local. Avec un backend fichier sans /var/log/auth.log, la prison sshd ne trouve pas son journal et tout le démon s'interrompt. fail2ban.log affiche :

ERROR   Failed during configuration: Have not found any log file for sshd jail

Comme cette erreur est fatale, le service ne démarre jamais, et fail2ban-client status signale alors le symptôme en aval :

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

Cette ligne « socket path » ne signifie pas que Fail2ban est cassé : elle signifie qu'il n'a jamais démarré parce qu'une prison n'a pas trouvé son journal. Définir backend = systemd dans [DEFAULT], ce que le paquet Ubuntu fait déjà pour vous, corrige les deux messages d'un coup.

La prison est active mais Total failed ne bouge jamais. Le démon tourne et le journal est lu, pourtant de vrais échecs s'accumulent dans journalctl -u ssh tandis que le compteur reste à 0. Écartez d'abord l'évidence : vous testez depuis une adresse listée dans ignoreip, donc vos propres échecs sont exemptés par conception. Si ce n'est pas cela, vous êtes sur une version d'OpenSSH où le processus par connexion est sshd-session (9.8 et ultérieur), dont le _COMM du journal est sshd-session, pas sshd, si bien que la correspondance livrée le manque. Élargissez la correspondance dans le bloc [sshd] :

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Redémarrez, échouez volontairement une connexion depuis une adresse absente d'ignoreip, et confirmez que Total failed grimpe enfin.

Vous vous êtes banni vous-même : Connection refused. Vous avez laissé votre propre adresse hors d'ignoreip, testé quelques mauvaises connexions, et maintenant :

ssh: connect to host 10.0.0.10 port 22: Connection refused

Le refus, plutôt qu'un délai d'attente silencieux, est le verdict reject par défaut de l'action nftables qui fait son travail, sur vous. Corrigez comme à l'étape 6 : débannissez depuis une session sur une autre adresse non bannie, ou depuis la console de l'hébergeur ; une session déjà ouverte depuis l'adresse bannie se fige elle aussi. Ajoutez ensuite votre adresse à ignoreip pour que cela ne se reproduise pas.

Fail2ban dit qu'une adresse est bannie, mais elle peut encore se connecter. Le compteur de status sshd augmente, pourtant l'adresse atteint toujours le port 22. C'est une incohérence entre l'action de bannissement et le pare-feu, et sur Ubuntu 24.04 cela signifie presque toujours que vous avez écrasé le banaction = nftables fonctionnel par banaction = iptables-multiport copié d'un ancien guide, sur une machine sans couche iptables. fail2ban.log affiche :

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

Supprimez cette surcharge et laissez en place l'action nftables du paquet, ou, si vous gérez le pare-feu entièrement via ufw et voulez que les bannissements y apparaissent, définissez banaction = ufw dans [DEFAULT]. Redémarrez et confirmez que la règle apparaît avec sudo nft list ruleset | grep f2b.

Fail2ban ne démarre plus après modification de jail.local. Une faute de frappe, un en-tête égaré ou une mauvaise valeur de temps, fait que le service refuse de démarrer. Demandez à Fail2ban de vérifier la configuration avant qu'il ne tourne :

sudo fail2ban-client -t

Il nomme le fichier et la prison en cause, par exemple Errors in jail 'sshd'. Skipping..., pour que vous corrigiez la source plutôt que de deviner.

FAQ

L'installation standard de Fail2ban sur Ubuntu 24.04 bannit-elle vraiment les attaques SSH ?

Oui. Le paquet livre /etc/fail2ban/jail.d/defaults-debian.conf, qui active la prison sshd, définit backend = systemd pour qu'elle lise le journal systemd au lieu de l'auth.log manquant, et définit banaction = nftables pour que les bannissements soient appliqués par le vrai pare-feu d'Ubuntu. Un simple apt install fail2ban protège SSH dès le premier démarrage. Confirmez-le avec sudo fail2ban-client status sshd et cherchez un Total failed non nul.

Pourquoi Fail2ban ne bannit-il rien sur ma machine ?

Écartez les trois causes courantes dans l'ordre. Vous testez peut-être depuis une adresse présente dans ignoreip, qui est exemptée par conception. Vous avez peut-être écrasé la valeur par défaut fonctionnelle en collant backend = auto dans jail.local depuis un vieux guide, ce qui casse la lecture du journal sur une image sans auth.log. Ou vous êtes peut-être dans un conteneur sans aucun journal systemd à lire. Vérifiez Total failed dans fail2ban-client status sshd : s'il ne grimpe jamais alors que journalctl -u ssh montre de vrais échecs, la prison lit au mauvais endroit.

Comment débannir ma propre adresse IP ?

Lancez sudo fail2ban-client set sshd unbanip VOTRE.IP.ICI, qui renvoie 1 en cas de succès, ou sudo fail2ban-client unban --all pour effacer tous les bannissements. Si vous êtes verrouillé hors de SSH, utilisez la console web ou VNC de votre hébergeur pour lancer la même commande : le bannissement rejette chaque paquet venant de votre adresse vers le port 22, si bien que même une session déjà ouverte cesse de fonctionner. Ajoutez ensuite votre adresse à ignoreip pour que cela ne se reproduise pas.

Quelle est la différence entre jail.conf et jail.local ?

jail.conf contient les valeurs par défaut en amont de Fail2ban et est écrasé à chaque mise à jour du paquet, donc toute modification y est finalement perdue. Le paquet Debian/Ubuntu superpose ses propres réglages par-dessus via jail.d/defaults-debian.conf. Vos changements ont leur place dans jail.local, qui est lu en dernier et l'emporte sur les deux, et auquel les mises à jour ne touchent jamais. Laissez jail.conf comme référence en lecture seule.

Fail2ban remplace-t-il l'authentification SSH par clé ?

Non. Fail2ban limite le débit des échecs répétés venant d'une même adresse ; il ne fait rien contre un devinage lent et distribué où chaque adresse reste sous le seuil. L'authentification par clé uniquement (PasswordAuthentication no) rend le devinage de mot de passe carrément impossible, et Fail2ban élague alors le bruit des journaux et expulse les scanners tôt. Utilisez les deux, et idéalement gardez SSH totalement hors de l'internet public.