Installer Fail2ban sur Linux pour bloquer les tentatives SSH répétées

Installer Fail2ban sur Linux permet de surveiller les journaux SSH, de repérer des échecs d’authentification répétés et de bloquer temporairement les adresses IP concernées via le pare-feu. Fail2ban réduit l’exposition aux attaques automatisées par force brute, mais ne remplace ni des clés SSH, ni un pare-feu correctement réglé, ni les mises à jour du système.

Ce tutoriel explique comment installer Fail2ban Linux sur les distributions courantes, créer une configuration SSH locale, contrôler les bannissements et récupérer l’accès après une erreur. L’objectif est simple : mettre en place une protection exploitable sans modifier les fichiers fournis par le paquet ni risquer de couper votre accès d’administration.

Que fait Fail2ban sur un serveur Linux ?

Fail2ban est un outil de sécurité Linux qui analyse les logs système pour détecter les tentatives d’authentification échouées répétées et bloque automatiquement les adresses IP concernées via des règles de pare-feu configurables. Fail2ban fonctionne avec des filtres basés sur des expressions régulières, des jails associées à un service et des actions de bannissement temporaires.

Une jail est une règle de surveillance : elle associe un filtre, un journal ou un backend de lecture, un nombre maximal de tentatives et une action. La jail sshd cible les échecs de connexion SSH. Fail2ban peut lire directement certains fichiers de logs ou exploiter systemd-journald selon la distribution et la configuration retenue.

Fail2ban ralentit les tentatives automatisées visibles dans les journaux ; il ne corrige pas une configuration SSH faible.

À quoi sert Fail2ban pour SSH ?

La protection Fail2ban SSH est particulièrement utile lorsqu’un serveur accepte encore une authentification par mot de passe. Après plusieurs erreurs depuis une même adresse IP durant une période donnée, Fail2ban ajoute une règle de blocage temporaire dans le pare-feu configuré, par exemple avec nftables, iptables ou UFW.

Ce que Fail2ban ne remplace pas

Fail2ban n’empêche pas l’exploitation d’une vulnérabilité applicative, ne chiffre pas les données et ne remplace pas une politique d’accès. Une configuration SSH qui n’accepte que les clés publiques réduit déjà fortement l’intérêt des essais de mots de passe automatisés, sans pour autant rendre la supervision et les mises à jour inutiles.

• Utilisez des clés publiques SSH pour les comptes d’administration.
• Appliquez les mises à jour de sécurité du système et des services exposés.
• Limitez les ports et services accessibles avec un pare-feu Linux.
• Conservez un accès de secours, par exemple une console fournie par l’hébergeur.

Préparer l’installation de Fail2ban sans perdre l’accès SSH

La préparation consiste à identifier le compte d’administration, l’adresse IP utilisée pour se connecter et le système de journalisation de la distribution. Fail2ban doit disposer des privilèges nécessaires pour lire les événements utiles et mettre à jour les règles de pare-feu ; l’installation et l’administration passent donc généralement par sudo ou le compte root.

Le point critique consiste à protéger d’abord votre accès d’administration avant de réduire les seuils de bannissement. Gardez une seconde session SSH ouverte pendant les premières modifications et vérifiez que votre console hors bande fonctionne si votre fournisseur en propose une.

Prérequis précis

• Un serveur Linux avec systemd et un accès administrateur via sudo.
• Une connexion SSH déjà fonctionnelle et une seconde session ouverte pendant les tests.
• L’adresse IP publique ou le sous-réseau d’administration à exclure avec ignoreip.
• Un pare-feu compatible avec l’action choisie par Fail2ban.
• Un service SSH qui écrit bien ses échecs d’authentification dans les journaux système.

Repérer l’adresse à exclure

Ajoutez uniquement une adresse ou un réseau réellement maîtrisé dans ignoreip. Exclure un large sous-réseau d’entreprise, un VPN partagé ou une plage d’adresses publiques réduit la portée de la protection, car toute machine comprise dans cette plage contournera le bannissement.

Installer Fail2ban sur Debian, Ubuntu et distributions utilisant DNF

L’installation de Fail2ban passe habituellement par le gestionnaire de paquets de la distribution. Sur Debian et Ubuntu, la commande utilise APT ; sur Fedora, Rocky Linux, AlmaLinux et les systèmes comparables, elle utilise généralement DNF. Les environnements plus anciens peuvent encore proposer YUM, mais DNF est la voie habituelle sur les distributions récentes qui l’emploient.

Les chemins de configuration et les commandes de contrôle restent proches entre distributions, mais l’emplacement exact des journaux et l’activation initiale du jail SSH peuvent varier. Ne supposez donc pas qu’une jail est active sans contrôler le statut du service après l’installation.

Étape 1 : installer Fail2ban avec le gestionnaire de paquets

Sur Debian ou Ubuntu, mettez d’abord à jour l’index des paquets puis installez Fail2ban. La commande suivante installe le service et ses fichiers de configuration sans toucher à la politique SSH existante.

sudo apt-get update
sudo apt-get install fail2ban

Sur une distribution utilisant DNF, installez le paquet avec la commande suivante. Le résultat attendu est la présence du service fail2ban et du répertoire /etc/fail2ban.

sudo dnf install fail2ban

Étape 2 : vérifier les fichiers installés

Contrôlez la présence du répertoire de configuration avant toute modification. Fail2ban utilise notamment jail.conf comme base et jail.local pour les réglages locaux qui doivent survivre aux mises à jour du paquet.

sudo ls -la /etc/fail2ban

Le résultat attendu est un répertoire contenant les fichiers de configuration, les filtres et les actions. Ne modifiez pas directement jail.conf : une mise à jour peut remplacer vos changements ou compliquer la comparaison avec la configuration fournie.

Étape 3 : activer et démarrer le service

Démarrez Fail2ban puis activez son lancement automatique au démarrage du serveur. Ces deux commandes sont distinctes : la première agit immédiatement, la seconde assure la persistance via systemd.

sudo systemctl start fail2ban
sudo systemctl enable fail2ban
sudo systemctl status fail2ban

Le résultat attendu est un service indiqué comme actif. Si systemd affiche un échec, passez directement à la consultation des journaux dans la section de dépannage plutôt que de modifier la configuration au hasard.

Comment configurer Fail2ban pour protéger SSH ?

La configuration Fail2ban SSH consiste à créer un fichier jail.local, définir une jail sshd, déclarer les adresses à ne jamais bannir et choisir des seuils adaptés au risque réel. Les paramètres centraux sont maxretry, qui fixe le nombre d’échecs admis, findtime, qui définit la fenêtre d’observation, et bantime, qui fixe la durée du blocage.

Les valeurs courantes souvent citées, comme 3 échecs sur 10 minutes avec un bannissement de 10 minutes, ne constituent pas une règle universelle. Un serveur administré depuis une connexion mobile ou un VPN instable demande souvent des réglages moins agressifs qu’un serveur dont SSH n’accepte que des accès d’exploitation prévisibles.

Étape 4 : créer le fichier jail.local

Créez ou ouvrez le fichier local avec un éditeur de texte exécuté via sudo. Cette méthode isole vos choix de la configuration distribuée par le paquet et facilite un retour en arrière si une règle bloque des utilisateurs légitimes.

sudo nano /etc/fail2ban/jail.local

Ajoutez une configuration de départ prudente. Remplacez l’adresse d’exemple dans ignoreip par votre adresse publique d’administration avant de redémarrer le service.

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

[sshd]
enabled = true

Le résultat attendu est une jail SSH active avec cinq échecs tolérés sur dix minutes et un bannissement d’une heure. L’adresse 203.0.113.10 est réservée à la documentation : ne la conservez pas telle quelle dans une configuration réelle.

Comprendre les paramètres utiles

Paramètre	Rôle	Effet d’un réglage trop strict	Point de contrôle
maxretry	Nombre d’échecs admis	Blocage d’un utilisateur qui se trompe de mot de passe	Comptes administrateurs et automatisations
findtime	Fenêtre de comptage des échecs	Des erreurs espacées peuvent être cumulées trop longtemps	Fréquence réelle des tentatives légitimes
bantime	Durée de blocage	Indisponibilité prolongée d’un accès légitime	Procédure de déblocage disponible
ignoreip	Adresses exclues du bannissement	Zone de confiance trop large	Adresse fixe et réellement maîtrisée

Étape 5 : redémarrer Fail2ban et contrôler la jail SSH

Rechargez le service après l’enregistrement du fichier local, puis affichez son état général. Le résultat attendu est une liste de jails comprenant sshd lorsque la configuration est valide et que le service SSH est détecté.

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

Une jail absente du statut doit être corrigée avant toute tentative de durcissement supplémentaire. Vérifiez d’abord le nom du jail, la syntaxe du fichier local et les journaux du service.

Comment vérifier que Fail2ban bloque réellement les tentatives SSH ?

La vérification repose sur trois contrôles : le service doit être actif, la jail sshd doit apparaître dans fail2ban-client et les logs doivent montrer que Fail2ban lit les événements attendus. Un bannissement réel doit rester un test contrôlé sur votre propre environnement, jamais une tentative contre un serveur tiers.

Fail2ban ne produit aucun résultat utile si le filtre ne trouve pas les événements SSH dans le journal observé. Avant de modifier les seuils, vérifiez donc la source des logs et assurez-vous que des erreurs d’authentification normales sont bien enregistrées par le service SSH.

Étape 6 : contrôler le service, la jail et les adresses bannies

Exécutez les commandes suivantes depuis une session d’administration autorisée. Le résultat attendu est un statut de jail contenant le nombre d’échecs détectés et, lorsqu’un bannissement est intervenu, les adresses IP actuellement bloquées.

sudo fail2ban-client status
sudo fail2ban-client status sshd

Étape 7 : consulter les journaux de Fail2ban

Utilisez le journal systemd pour suivre les démarrages, erreurs de configuration et actions de bannissement. Selon la distribution et la configuration, Fail2ban peut aussi écrire dans un fichier journal dédié sous /var/log.

sudo journalctl -u fail2ban --since "30 minutes ago"

Le résultat attendu est la présence d’événements cohérents avec les actions réalisées. Une absence totale d’événement après un redémarrage indique souvent que le service ne démarre pas, que le niveau de journalisation est insuffisant ou que les événements SSH ne sont pas lus par le backend configuré.

Étape 8 : faire un test contrôlé sans viser un tiers

Testez uniquement depuis une machine, un compte et une adresse IP que vous contrôlez, sans fermer votre session administrateur fonctionnelle. Réalisez quelques authentifications volontairement erronées dans la limite du seuil choisi, puis vérifiez le statut de la jail depuis la session restée ouverte.

Le résultat attendu est une hausse du compteur d’échecs, puis un bannissement si le seuil est réellement atteint. Arrêtez le test dès que le comportement est confirmé : multiplier les essais inutiles ne rend pas la validation plus fiable.

Le bon test ne consiste pas à produire beaucoup d’échecs : il consiste à vérifier que le journal, le filtre, la jail et l’action de pare-feu sont reliés.

Débannir une adresse IP et résoudre les blocages légitimes

Pour débannir une adresse IP, utilisez fail2ban-client avec le nom exact du jail et l’adresse concernée. La commande retire le bannissement appliqué par Fail2ban, mais elle ne corrige pas la cause initiale : erreur de mot de passe, automatisation mal configurée, clé refusée ou seuil trop sévère.

Conservez une trace de la raison du déblocage. Un bannissement légitime mais inattendu peut révéler un script obsolète, un outil de sauvegarde utilisant un ancien mot de passe ou une machine qui tente encore de se connecter avec de mauvais identifiants.

Étape 9 : débannir une adresse IP

Remplacez ADRESSE_IP par l’adresse à retirer et conservez le nom sshd seulement si la jail concernée protège SSH. Le résultat attendu est la suppression immédiate de l’adresse dans la liste des IP bannies de cette jail.

sudo fail2ban-client set sshd unbanip ADRESSE_IP

Étape 10 : vérifier l’exclusion avant un prochain incident

Ajoutez l’adresse d’administration dans ignoreip uniquement après avoir confirmé sa stabilité et sa légitimité. Redémarrez ensuite Fail2ban et vérifiez la syntaxe du fichier : une exclusion mal écrite peut donner un faux sentiment de sécurité ou empêcher le service de démarrer.

Erreurs fréquentes lors de l’installation de Fail2ban Linux

Les difficultés viennent rarement de l’installation du paquet. Les incidents apparaissent plutôt lors du raccordement entre les journaux, le filtre, le jail et le pare-feu. Une approche prudente consiste à modifier un seul élément, redémarrer le service et lire son statut avant de poursuivre.

• Modifier directement jail.conf : les changements risquent d’être écrasés par une mise à jour. Créez jail.local ou un fichier local dédié.
• Oublier ignoreip : une faute de mot de passe ou un test depuis votre IP peut couper votre accès. Gardez une seconde session SSH et une console de secours.
• Activer une jail sans vérifier les logs : Fail2ban ne peut pas détecter des motifs absents ou stockés dans une source non lue. Contrôlez journald ou les fichiers de logs.
• Régler maxretry trop bas : un seuil très faible augmente les faux positifs, notamment avec des comptes techniques ou des réseaux instables.
• Considérer Fail2ban comme un pare-feu complet : Fail2ban agit sur des événements détectés ; il complète le filtrage réseau, il ne le remplace pas.

Fail2ban, UFW et nftables : quelles alternatives ou compléments ?

Fail2ban ne remplace pas UFW, nftables ou firewalld : ces outils définissent la politique de filtrage réseau, tandis que Fail2ban ajoute ou retire dynamiquement des blocages selon les événements repérés. Le choix dépend donc moins d’une compétition entre outils que de leur intégration dans une chaîne de sécurité cohérente.

UFW convient souvent à une administration simple sur Debian ou Ubuntu, nftables constitue le mécanisme moderne de filtrage sur de nombreux systèmes Linux, et firewalld apporte une gestion par zones fréquente dans les environnements Red Hat. Pour comparer leurs usages et leurs limites, consultez les pare-feu Linux selon votre usage.

Outil	Fonction principale	Usage recommandé	Limite à connaître
Fail2ban	Détecter les échecs répétés dans les journaux	Réduire les essais automatisés contre SSH ou un service authentifié	Dépend de journaux, filtres et actions correctement raccordés
UFW	Simplifier des règles de pare-feu	Administrer rapidement les ports autorisés ou refusés	Ne détecte pas seul les échecs de connexion applicatifs
nftables	Filtrage réseau par règles	Politiques réseau détaillées et intégration système	Demande une bonne maîtrise de la politique de filtrage

Protéger d’autres services avec prudence

Fail2ban peut surveiller d’autres services qui produisent des journaux d’échecs exploitables, notamment certains serveurs FTP ou services HTTP exposant des événements d’authentification. N’activez pas une jail uniquement parce qu’elle existe : vérifiez le filtre, le format réel des logs et les conséquences d’un blocage pour vos utilisateurs.

Un filtre personnalisé par expressions régulières demande une validation rigoureuse sur des extraits de logs représentatifs. Une expression trop large peut bannir des visiteurs légitimes ; une expression trop étroite ne détectera rien. Pour une politique de protection plus large, l’usage d’outils open source doit rester aligné avec les services réellement exposés et leur surface d’attaque.

Surveiller Fail2ban et renforcer SSH au-delà du bannissement

La surveillance utile repose sur les statuts de jail, les journaux Fail2ban et les alertes adaptées à votre environnement. Fail2ban peut déclencher des actions autres qu’un simple blocage, y compris des notifications par courriel, mais une alerte SMTP n’a de valeur que si elle arrive à une boîte réellement surveillée et si son envoi est testé.

Une alerte de bannissement doit déclencher une vérification, pas une conclusion automatique sur l’origine ou la gravité d’un incident. Une IP bloquée peut correspondre à une attaque automatisée, mais aussi à un utilisateur légitime, un script défaillant ou une erreur de configuration.

Mesurer la charge sans surinterpréter

Fail2ban lit les journaux et applique des actions à chaque détection. L’impact dépend du volume de logs, du nombre de jails actives, de la complexité des expressions régulières et de la fréquence des attaques observées. Sur un serveur chargé, activez seulement les jails liées à des services exposés et examinez les journaux avant d’ajouter des filtres coûteux ou redondants.

Durcir l’accès SSH

• Privilégiez les clés publiques plutôt que les mots de passe pour les accès d’administration.
• Supprimez les comptes inutilisés et limitez les droits accordés par sudo.
• Contrôlez régulièrement les mises à jour du serveur et du service SSH.
• Chiffrez les supports contenant des clés ou sauvegardes sensibles ; le guide pour protéger un disque avec LUKS couvre cette couche distincte.

Sources utiles à consulter

La documentation officielle du projet Fail2ban sur GitHub décrit le fonctionnement général, les exigences d’installation depuis les sources et les mécanismes de configuration. Consultez-la pour vérifier une option spécifique à la version installée sur votre serveur.

La documentation de votre distribution complète cette source pour les chemins de journaux, les paquets et les mécanismes de pare-feu disponibles. L’ArchWiki consacrée à Fail2ban détaille également plusieurs options de backend et d’action, à adapter avant emploi à votre environnement réel.

Verdict : une couche défensive utile, à condition de la vérifier

Fail2ban apporte une réponse pragmatique aux répétitions d’échecs visibles dans les logs SSH : détecter, bloquer temporairement, puis surveiller. La configuration minimale avec une jail SSH, une exclusion d’administration et un contrôle via fail2ban-client suffit pour démarrer proprement. Le verdict est net : installez-le si SSH est exposé, mais ne le confondez jamais avec une stratégie de sécurisation complète.

Questions fréquentes sur Fail2ban sous Linux

Fail2ban est-il indispensable pour sécuriser SSH ?

Fail2ban est une couche de protection utile contre les tentatives répétées visibles dans les journaux SSH, surtout si l’authentification par mot de passe reste autorisée. Il ne suffit pas seul : les clés publiques, les mises à jour et un pare-feu restent nécessaires.

Comment savoir si la jail SSH est active ?

Exécutez sudo fail2ban-client status, puis sudo fail2ban-client status sshd. La sortie doit afficher la jail sshd, les échecs suivis et, s’il y en a, les adresses actuellement bannies.

Quelle durée de bannissement choisir avec bantime ?

La durée dépend de votre exposition, des risques de faux positifs et de votre capacité à débannir rapidement une adresse légitime. Commencez avec une durée modérée et adaptez-la après observation des journaux, plutôt que d’adopter une valeur très longue sans procédure de récupération.

Comment débannir une adresse IP bloquée par erreur ?

Utilisez sudo fail2ban-client set sshd unbanip ADRESSE_IP en remplaçant l’adresse par celle à retirer. Vérifiez ensuite la cause du blocage et ajoutez une exclusion ciblée uniquement si l’adresse d’administration est stable et maîtrisée.

Fail2ban fonctionne-t-il avec IPv6 ?

Fail2ban prend en charge IPv6 depuis la version 0.10. Vérifiez tout de même que le pare-feu, les journaux SSH et l’action de bannissement configurée sur votre distribution traitent correctement les connexions IPv6.