Installer Fail2ban sur Ubuntu 24.04 pour bloquer SSH

Ce que fait réellement Fail2ban

Fail2ban est un daemon qui lit les journaux. Il surveille les messages d’authentification SSH et, après plusieurs échecs provenant d’une même adresse dans un court intervalle, exécute une commande du firewall qui bloque cette adresse pendant un certain temps. C’est tout le principe. Sa configuration tient dans une trentaine de lignes réparties dans un seul fichier et, sur Ubuntu 24.04, l’installation se fait avec une seule commande apt. Votre serveur est ainsi protégé avant même que vous ayez modifié quoi que ce soit.

Il faut bien comprendre ce que Fail2ban fait et ne fait pas. Fail2ban n’authentifie personne, ne chiffre rien et n’empêche pas une tentative de connexion isolée et déterminée. Il bloque uniquement les tentatives répétées provenant de la même source. C’est un filtre contre le bruit et un limiteur de débit, pas une serrure. Son rôle est d’éviter que le scan permanent du port 22 consomme inutilement votre CPU, votre bande passante et l’espace de vos journaux, et de ralentir un attaquant qui doit procéder depuis une 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 à effectuer des tentatives, car chaque adresse reste sous votre seuil de bannissement et ne le déclenche jamais. La véritable protection consiste à utiliser une authentification par clé uniquement. Les tentatives de deviner un mot de passe deviennent alors impossibles, quel que soit le nombre d’essais. Fail2ban apporte deux avantages complémentaires lorsqu’il est associé à l’authentification par clé uniquement : il réduit le bruit des attaques par force brute dans vos journaux et écarte rapidement les scanners, qui cessent ainsi de marteler le port. Considérez-le comme une défense en profondeur. Il intervient après l’authentification par clé et après le pare-feu, jamais avant eux.

Prérequis et réalité d’Ubuntu 24.04

Vous avez besoin d’un VPS sous Ubuntu 24.04 avec un accès root ou sudo, ainsi que d’un accès SSH déjà fonctionnel, idéalement avec une authentification par clé. Fail2ban consomme peu de ressources : quelques dizaines de mégaoctets de RAM, sans réglage particulier des limites.

Passons maintenant au point que les anciens guides présentent souvent mal. Pendant des années, la recommandation standard consistait à « installer Fail2ban, puis ajouter backend = systemd, car Ubuntu n’écrivait plus dans /var/log/auth.log ». Cette recommandation décrit un changement réel : les images modernes de serveurs et de cloud sont livrées sans rsyslog. SSH écrit donc uniquement dans le journal systemd, et ce fichier texte n’existe plus. Cependant, sous Ubuntu 24.04, le paquet Fail2ban en tient déjà compte. Le paquet installe /etc/fail2ban/jail.d/defaults-debian.conf, et c’est ce fichier, et non les valeurs par défaut en amont, que votre serveur utilise réellement :

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

[sshd]
enabled = true

Lisez attentivement ce fichier, car il répond à deux questions avant toute modification. backend = systemd signifie que la jail SSH lit le journal, donc l’absence de auth.log n’a aucune importance. banaction = nftables signifie que les bannissements sont appliqués via nftables, le pare-feu réellement utilisé par Ubuntu 24.04, et non via l’ancien iptables. Enfin, [sshd] enabled = true signifie que la jail est activée dès le premier démarrage. En pratique, une installation standard de apt install fail2ban sous Ubuntu 24.04 bloque les attaques par force brute contre SSH sans configuration supplémentaire. Votre travail consiste surtout à le confirmer, à ajuster la politique et à vérifier que vous ne pouvez pas vous verrouiller vous-même hors du serveur.

L’ancien piège de auth.log se présente encore dans trois situations, qu’il est utile de savoir reconnaître : vous avez installé Fail2ban avec pip au lieu de apt, et defaults-debian.conf n’existe donc pas ; vous êtes dans un conteneur non privilégié sans journal systemd à consulter ; ou vous avez suivi un ancien tutoriel et copié backend = auto dans votre propre jail.local, ce qui remplace la configuration par défaut fonctionnelle. La section consacrée aux modes de défaillance montre exactement à quoi correspond chaque cas.

Étape 1 : Installer Fail2ban et vérifier qu’il bloque déjà les tentatives

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 fournit Fail2ban 1.0.2. Le paquet installe aussi python3-systemd comme dépendance obligatoire. Le backend journal dispose donc de tout ce dont il a besoin. Le service s’active et démarre automatiquement :

sudo systemctl status fail2ban

Vous devez obtenir active (running). Examinez ensuite la jail qui fonctionne déjà :

sudo fail2ban-client status sshd

Sur un VPS public accessible depuis quelques minutes seulement, vous verrez souvent déjà des échecs comptabilisés et des adresses bloquées. Internet scanne en permanence le port 22. Cela confirme que la configuration par défaut fonctionne. Vous allez maintenant l’affiner, et non la construire à partir de rien.

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

Fail2ban conserve ses valeurs par défaut fournies par l’éditeur dans /etc/fail2ban/jail.conf. Ne modifiez pas ce fichier. Chaque apt upgrade du paquet peut le remplacer, et vos modifications disparaîtraient sans avertissement. Fail2ban lit les fichiers dans un ordre fixe : d’abord jail.conf, puis tous les fichiers de jail.d/, et enfin jail.local. La dernière valeur lue est prioritaire. Le fichier .local vous appartient, et les mises à niveau du paquet ne le modifient jamais. La même règle s’applique aux filtres : un fichier *.local remplace le fichier filter.d/*.conf fourni avec le paquet.

Vous devez donc créer un petit jail.local qui remplace uniquement les quelques paramètres qui vous intéressent, et laisser jail.conf ainsi que le fichier jail.d/defaults-debian.conf fourni avec le paquet inchangés pour référence.

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

sudo nano /etc/fail2ban/jail.local

Insérez ce contenu et remplacez l’adresse de la ligne ignoreip par votre propre adresse 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 son utilité :

• bantime, findtime et maxretry définissent la policy. La valeur par défaut fournie, bantime, est de seulement dix minutes ; une heure constitue une valeur minimale plus raisonnable. Cinq échecs depuis une même adresse en dix minutes déclenchent le ban. Une personne réelle saisit parfois un mauvais mot de passe une ou deux fois ; cinq échecs en dix minutes indiquent un script.
• ignoreip est votre filet de sécurité. Ajoutez ici l’adresse publique depuis laquelle vous vous connectez afin que Fail2ban ne puisse jamais vous bloquer l’accès à votre propre serveur. Une connexion domestique avec une adresse IP variable est une raison de préférer l’approche VPN présentée à la fin, pas de supprimer cette ligne.
• bantime.increment = true rend chaque ban répété plus long que le précédent : une heure, puis deux, puis quatre, jusqu’à bantime.maxtime. Les adresses qui reviennent régulièrement sont progressivement bloquées plus longtemps.

Trouvez l’adresse à mettre sur la liste blanche depuis la machine à partir de laquelle vous vous connectez en SSH, et non depuis le serveur :

curl -s ifconfig.me

Vous pouvez générer ici un jail.local adapté à vos ports et à votre policy, puis le coller dans le fichier :

Étape 4 : redémarrer et vérifier que le journal est bien lu

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

La commande -t commence par tester la configuration. Une erreur de syntaxe dans jail.local échoue donc clairement à cette étape, au lieu de laisser le service arrêté. L’état d’une jail fonctionnelle 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 réellement vos tentatives de connexion est Total failed. S’il est supérieur à zéro ou augmente lorsque vous provoquez volontairement l’échec d’une connexion depuis une autre machine, le journal est bien lu et vous avez terminé. S’il reste à 0 quel que soit le nombre de vos tentatives infructueuses, et si vous avez vérifié que vous ne testez pas depuis l’adresse indiquée dans ignoreip, consultez les modes d’échec ci-dessous.

Notez que la ligne Journal matches désigne toujours sshd.service. Sur Ubuntu, l’unité SSH est en réalité ssh.service, mais le filtre fourni correspond également à _COMM=sshd. De plus, OpenSSH 24.04 journalise ses échecs depuis un processus nommé sshd. La correspondance fonctionne donc. Ce détail ne concerne que les versions plus récentes d’OpenSSH (9.8 ou ultérieures), dans lesquelles le worker par connexion est sshd-session. Les modes d’échec couvrent ce cas.

Étape 5 : observer l’application d’un ban réel ou en forcer un pour tester

Les bans réels apparaissent spontanément en quelques minutes sur tout VPS public. Pour en observer un, suivez le log :

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

Un ban 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 vérifier le fonctionnement de bout en bout sans attendre, bannissez manuellement une adresse utilisée pour la documentation, jamais la vôtre :

sudo fail2ban-client set sshd banip 10.0.0.66

La commande affiche 1, et l’adresse apparaît sous Banned IP list dans fail2ban-client status sshd. Vérifiez maintenant que le blocage existe bien dans le firewall. Sur Ubuntu 24.04, il s’agit de nftables, pas d’iptables :

sudo nft list table inet f2b-table

Vous verrez un set nommé addr-set-sshd contenant 10.0.0.66, ainsi qu’une chain f2b-chain qui rejette toute source présente dans ce set. Si fail2ban-client indique qu’une adresse est bannie, mais que rien n’apparaît dans nft list, votre action de ban ne correspond pas à votre firewall. Consultez la note sur nftables et iptables dans la section consacrée aux modes d’échec.

Étape 6 : vous débannir et récupérer l’accès si vous êtes bloqué

Si vous avez banni une adresse qui ne devait pas l’être, notamment la vôtre, supprimez le bannissement :

sudo fail2ban-client set sshd unbanip 10.0.0.66

La commande renvoie 1 en cas de succès. Pour supprimer tous les bannissements dans toutes les jails :

sudo fail2ban-client unban --all

Ne comptez pas sur une session SSH déjà ouverte pour vous protéger : le bannissement nftables rejette tous les paquets provenant de l’adresse bannie vers le port 22, y compris ceux des connexions déjà établies. Une session existante se fige donc dès que le bannissement est appliqué. Si vous vous bannissez et qu’aucune entrée ignoreip n’est présente, vous perdez l’accès jusqu’à l’expiration du bannissement. Récupérez l’accès via la console web de votre fournisseur (VNC ou console série), qui ne passe pas par SSH, puis attendez l’expiration de bantime ou exécutez la commande de débannissement depuis cette console.

Étape 7 : Rendre les bannissements persistants et les faire monter en puissance

Fail2ban conserve les bannissements actifs dans une petite base SQLite située dans /var/lib/fail2ban/fail2ban.sqlite3. Ils survivent ainsi au redémarrage du service ou du serveur. Vous ne les perdez pas. Les lignes bantime.increment que vous avez déjà ajoutées transforment chaque récidiviste en problème croissant pour lui-même, avec une durée qui double approximativement, d’une heure jusqu’à environ une semaine.

Pour appliquer en plus une règle système des « trois avertissements », Fail2ban fournit une jail recidive qui surveille son propre /var/log/fail2ban.log et applique de longs bannissements à toute adresse déjà bannie à plusieurs reprises dans l’ensemble des jails. Comme votre [DEFAULT] utilise maintenant le backend systemd, forcez cette jail à lire le fichier journal prévu à cet effet :

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

backend = auto avec le logpath explicite permet à recidive de lire le fail2ban.log classique. C’est là qu’apparaissent réellement les lignes Ban qu’il compte. La valeur systemd définie globalement le dirigerait vers le journal, qui ne contient pas ces lignes.

Étape 8 : associez-le à l’authentification SSH par clé, ou mieux encore à un VPN

Fail2ban n’est réellement utile qu’avec l’authentification par clé. Dans un fichier drop-in sous /etc/ssh/sshd_config.d/, par exemple /etc/ssh/sshd_config.d/00-hardening.conf, définissez :

PasswordAuthentication no
KbdInteractiveAuthentication no

Puis sudo systemctl restart ssh. Lorsque les mots de passe sont désactivés, une attaque par force brute ne peut pas aboutir ; Fail2ban sert alors à réduire le bruit dans les journaux et à expulser rapidement les scanners. Une protection encore plus forte consiste à ne pas exposer SSH à Internet : placez SSH derrière un VPN WireGuard auto-hébergé et configurez le pare-feu pour que le port 22 ne réponde que sur le tunnel. Personne ne peut lancer une attaque par force brute contre un port inaccessible, et Fail2ban devient une protection de secours plutôt que la première ligne de défense.

Fail2ban ne sert pas uniquement pour SSH. Tout service qui journalise les échecs de connexion peut utiliser une jail : 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 exposée au credential stuffing. Lorsqu’une application web se trouve derrière un site nginx avec un certificat Let's Encrypt, faites pointer un filtre Fail2ban vers son access log, de la même manière que la jail SSH pointe vers le journal.

Modes de défaillance, avec les chaînes exactes affichées

« Have not found any log file for sshd jail », et Fail2ban ne démarre pas. Il s’agit de l’ancien problème auth.log. Sur Ubuntu 24.04, il ne se produit que si quelque chose a remplacé la valeur par défaut du paquet, en cas d’installation de pip sans defaults-debian.conf, dans un conteneur sans journal, ou à cause d’un backend = auto isolé collé dans jail.local. Avec un backend fichier sans /var/log/auth.log, la jail sshd ne trouve pas son journal et le daemon s’arrête. fail2ban.log affiche :

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

Cette erreur étant fatale, le service ne démarre jamais. fail2ban-client status signale alors le symptôme qui en découle :

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

La ligne « socket path » ne signifie pas que Fail2ban est défaillant. Elle signifie qu’il n’a jamais démarré, car une jail ne trouvait pas son journal. Définir backend = systemd dans [DEFAULT], ce que le paquet Ubuntu fait déjà pour vous, corrige les deux messages en même temps.

La jail est active, mais Total failed n’évolue jamais. Le daemon fonctionne et le journal est bien lu, mais les échecs réels s’accumulent dans journalctl -u ssh tandis que le compteur reste à 0. Commencez par écarter la cause évidente : vous testez depuis une adresse figurant dans ignoreip. Vos propres échecs sont donc volontairement exemptés. Si ce n’est pas la cause, vous utilisez une version d’OpenSSH dans laquelle le worker par connexion est sshd-session (9.8 et versions ultérieures). Dans ce cas, son journal _COMM est sshd-session, et non sshd. Le filtre fourni ne le détecte donc pas. Élargissez la correspondance dans le bloc [sshd] :

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

Redémarrez, provoquez volontairement un échec de connexion depuis une adresse absente de ignoreip, puis vérifiez que Total failed augmente enfin.

Vous vous êtes banni : Connection refused. Vous avez omis votre propre adresse dans ignoreip, effectué quelques tentatives de connexion incorrectes, et vous obtenez 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. Il s’applique à votre adresse. Corrigez la situation comme à l’étape 6 : retirez le ban depuis une session ouverte sur une autre adresse, non bannie, ou depuis la console du fournisseur. Une session déjà ouverte depuis l’adresse bannie se bloque également. Ajoutez ensuite votre adresse à ignoreip pour éviter que cela se reproduise.

Fail2ban indique qu’une adresse est bannie, mais elle peut toujours se connecter. Le compteur dans status sshd augmente, mais l’adresse atteint toujours le port 22. Il s’agit d’une incompatibilité entre l’action de ban et le firewall. Sur Ubuntu 24.04, cela signifie presque toujours que vous avez remplacé banaction = nftables, qui fonctionne, par banaction = iptables-multiport, copié depuis 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 l’action nftables fournie par le paquet s’appliquer. Si vous gérez entièrement le firewall avec ufw et souhaitez que les bans y apparaissent, définissez banaction = ufw dans [DEFAULT]. Redémarrez, puis vérifiez que la règle apparaît avec sudo nft list ruleset | grep f2b.

Fail2ban ne démarre pas après la modification de jail.local. Une faute de frappe, un en-tête isolé ou une valeur de durée incorrecte peut empêcher le service de démarrer. Demandez à Fail2ban de vérifier la configuration avant de lancer le service :

sudo fail2ban-client -t

La commande indique le fichier et la jail concernés, par exemple Errors in jail 'sshd'. Skipping.... Vous pouvez ainsi corriger la source au lieu de procéder par essais.

FAQ

L’installation standard de Fail2ban sur Ubuntu 24.04 bloque-t-elle réellement les attaques SSH ?

Oui. Le paquet fournit /etc/fail2ban/jail.d/defaults-debian.conf, qui active la jail sshd, définit backend = systemd pour lire le journal systemd au lieu du fichier /var/log/auth.log absent, et définit banaction = nftables afin que les bannissements soient appliqués par le véritable firewall 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 vérifiez la présence d’une valeur non nulle pour Total failed.

Pourquoi Fail2ban ne bloque-t-il rien sur mon serveur ?

É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 remplacé la configuration par défaut fonctionnelle en copiant backend = auto dans jail.local depuis un ancien guide, ce qui empêche la lecture du journal sur une image dépourvue de auth.log. Vous êtes peut-être aussi dans un conteneur sans journal systemd exploitable. Vérifiez Total failed dans fail2ban-client status sshd : si cette valeur n’augmente jamais alors que journalctl -u ssh affiche de véritables échecs, la jail lit au mauvais endroit.

Comment débloquer ma propre adresse IP ?

Exécutez sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, qui renvoie 1 en cas de réussite, ou sudo fail2ban-client unban --all pour supprimer tous les bannissements. Si vous n’avez plus accès à SSH, utilisez la console web ou VNC de votre fournisseur pour exécuter la même commande : le bannissement rejette tous les paquets provenant de votre adresse vers le port 22. Même une session déjà ouverte cesse donc de fonctionner. Ajoutez ensuite votre adresse à ignoreip pour éviter que le problème se reproduise.

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

jail.conf contient les valeurs par défaut fournies par Fail2ban et est remplacé à chaque mise à niveau du paquet. Toute modification qui y est apportée finit donc par être perdue. Le paquet Debian/Ubuntu ajoute ses propres paramètres par-dessus via jail.d/defaults-debian.conf. Placez vos modifications dans jail.local : ce fichier est lu en dernier, prévaut sur les deux autres et n’est jamais modifié lors des mises à niveau. Utilisez 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 provenant d’une même adresse. Il ne bloque pas une tentative lente et distribuée si chaque adresse reste sous le seuil. L’authentification avec clés uniquement (PasswordAuthentication no) rend les tentatives par mot de passe impossibles. Fail2ban réduit alors le bruit dans les journaux et expulse rapidement les scanners. Utilisez les deux mécanismes et, idéalement, n’exposez pas du tout SSH à Internet.