Installer et configurer Fail2ban sur Ubuntu : guide pas à pas pour protéger SSH

Pour installer Fail2ban sur Ubuntu 20.04 et protéger SSH, installez le paquet avec sudo apt install fail2ban, créez une configuration locale dans /etc/fail2ban/jail.local, activez la prison sshd, puis contrôlez son état avec fail2ban-client status sshd. Fail2ban bloque temporairement une adresse IP après plusieurs échecs d’authentification selon les seuils que vous définissez.

Fail2ban est un outil de sécurité qui lit les journaux système afin de repérer des échecs de connexion répétés et d’appliquer un bannissement temporaire. Ce tutoriel cible Ubuntu 20.04 amd64 avec Fail2ban 0.11.x issu des dépôts Ubuntu, un accès SSH fonctionnel et un utilisateur disposant de droits sudo.

À quoi sert Fail2ban sur Ubuntu ?

Fail2ban analyse les fichiers de journalisation de services exposés, notamment SSH, et recherche des motifs d’échec répétés. Lorsqu’une même adresse IP atteint le seuil prévu pendant une période donnée, Fail2ban demande au système d’appliquer un bannissement temporaire. Fail2ban n’empêche donc pas une première tentative : il réduit surtout la répétition rapide de tentatives infructueuses.

Fail2ban est une couche de réaction aux échecs visibles dans les journaux, pas un pare-feu complet ni une protection absolue. Un serveur Ubuntu reste dépendant d’un système à jour, d’identifiants robustes et, pour SSH, d’une politique d’accès cohérente.

Fail2ban ne remplace ni les mises à jour de sécurité, ni les clés SSH, ni la maîtrise des comptes autorisés à se connecter au serveur.

Le présent guide se concentre volontairement sur la prison SSH. N’activez pas des prisons pour Apache, FTP ou un autre service si ce service n’est pas réellement installé et journalisé sur le serveur. Une règle sans service correspondant complique le diagnostic sans améliorer la sécurité.

Quels prérequis vérifier avant l’installation ?

Avant d’installer Fail2ban sur Ubuntu, vérifiez que le serveur répond au réseau, que SSH fonctionne déjà et que vous utilisez un compte non-root ayant accès à sudo. Gardez une seconde session SSH ouverte pendant la configuration : cette précaution permet de corriger un réglage si la session principale rencontre un problème.

Le tutoriel cible le port SSH standard, généralement le port 22. Si votre serveur utilise un autre port, la valeur port = ssh peut ne plus correspondre à votre configuration ; adaptez alors ce point après avoir vérifié la configuration réelle du service SSH.

• Un serveur Ubuntu 20.04 sur architecture amd64.
• Un utilisateur non-root disposant de droits sudo.
• Une connexion réseau vers les dépôts Ubuntu.
• Un service SSH actif et une session d’administration de secours.
• Un accès hors bande ou une console fournie par l’hébergeur, utile en cas de bannissement accidentel.

Étape 1 : vérifier les droits administrateur et le réseau

Ouvrez un terminal sur le serveur Ubuntu et lancez la commande suivante. La commande demande votre mot de passe si nécessaire, puis valide la possibilité d’exécuter les commandes administratives.

sudo -v

Vérifiez ensuite que le serveur peut joindre le miroir de paquets Ubuntu. La commande doit recevoir des réponses réseau ; une absence de réponse impose de résoudre le problème réseau avant toute installation.

ping -c 3 archive.ubuntu.com

Étape 2 : identifier le port SSH autorisé

Si UFW est installé et utilisé sur le serveur, contrôlez la présence d’une règle liée au port SSH. Cette vérification ne doit pas conduire à désactiver le pare-feu : Fail2ban et le pare-feu ont des rôles différents et complémentaires.

sudo ufw status | grep 22

Le résultat attendu est une règle autorisant le port 22 si SSH écoute sur son port par défaut. Si votre service SSH écoute sur un port différent, vérifiez d’abord ce port dans la configuration SSH avant de modifier la future prison Fail2ban.

Comment installer Fail2ban sur Ubuntu 20.04 ?

Pour installer Fail2ban sur Ubuntu 20.04, actualisez d’abord l’index des paquets, puis installez le paquet depuis les dépôts officiels de la distribution. Cette méthode évite l’ajout de dépôts inutiles et conserve le logiciel dans le circuit de mises à jour d’Ubuntu.

La documentation communautaire Ubuntu consacrée à Fail2ban décrit le principe des prisons et de la surveillance des journaux. Le paquet fourni par Ubuntu 20.04 correspond généralement à la branche Fail2ban 0.11.x ; ne mélangez pas ce guide avec des fichiers prévus pour une autre version ou une autre distribution.

Étape 3 : actualiser la liste des paquets

Lancez la mise à jour de l’index APT. Attendez la fin de la commande et corrigez toute erreur d’accès aux dépôts avant de continuer.

sudo apt update

Le résultat attendu est une commande terminée sans erreur bloquante. Cette étape ne met pas à niveau tous les paquets du serveur : elle actualise uniquement la liste des versions disponibles.

Étape 4 : installer le paquet Fail2ban

Installez ensuite Fail2ban avec APT. Le gestionnaire de paquets télécharge les dépendances nécessaires et installe les fichiers de configuration dans /etc/fail2ban.

sudo apt install fail2ban

Le résultat attendu est une installation terminée sans message d’erreur. Après l’installation, le service peut être présent sans être activé au démarrage : la vérification et l’activation interviennent plus loin, après la configuration locale.

Comment créer une configuration Fail2ban sûre et durable ?

Une configuration Fail2ban sûre se place dans /etc/fail2ban/jail.local ou dans un fichier local du répertoire /etc/fail2ban/jail.d/. Le fichier jail.conf sert de base fournie par le paquet ; une modification directe peut être remplacée lors d’une mise à jour.

Le fichier de configuration Fail2ban utilise notamment quatre variables : bantime pour la durée du bannissement, findtime pour la fenêtre d’observation, maxretry pour le nombre maximal d’échecs et ignoreip pour les adresses exemptées. Les valeurs proposées ci-dessous constituent un exemple prudent à comprendre avant de l’appliquer.

Une adresse placée dans ignoreip ne sera pas bannie par Fail2ban : cette exception doit rester limitée aux adresses réellement maîtrisées.

Étape 5 : créer le fichier local à partir de la configuration fournie

Créez une copie locale du fichier principal. Cette copie permet de partir de la structure connue du paquet tout en préservant vos changements lors des futures mises à jour.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Le résultat attendu est la présence du fichier /etc/fail2ban/jail.local. Ne supprimez pas jail.conf et ne modifiez pas ce fichier d’origine pour personnaliser la configuration.

Étape 6 : définir les paramètres généraux dans jail.local

Ouvrez le fichier local avec l’éditeur Nano. Recherchez la section [DEFAULT], puis adaptez ou ajoutez les lignes suivantes dans cette section.

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
bantime = 3600m
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 <votre_IP_administration_stable>

Dans cet exemple, cinq échecs sur dix minutes déclenchent un bannissement de 3 600 minutes, soit 60 heures. Remplacez uniquement <votre_IP_administration_stable> par une adresse IP que vous contrôlez réellement et qui ne change pas fréquemment. N’ajoutez jamais une plage universelle telle que 0.0.0.0/0, car elle neutraliserait la fonction de bannissement.

Paramètre	Exemple du guide	Effet concret	Point de vigilance
bantime	3600m	Durée pendant laquelle l’IP reste bannie	Une durée longue augmente le risque de bloquer un administrateur légitime.
findtime	10m	Période durant laquelle Fail2ban compte les échecs	Une fenêtre courte détecte moins les tentatives lentes.
maxretry	5	Nombre d’échecs avant bannissement	Une valeur trop basse peut pénaliser une erreur de saisie légitime.
ignoreip	Loopback + IP stable	Adresse exclue des bannissements	Ne mettez que des adresses de confiance nécessaires.

Comment activer la prison SSH dans Fail2ban ?

Pour protéger SSH sur Ubuntu, activez la prison nommée sshd dans jail.local. La prison SSH lit les événements d’authentification et compare les échecs observés aux valeurs findtime et maxretry définies dans la configuration.

La journalisation SSH constitue la base du mécanisme : si Fail2ban ne lit pas le bon journal, aucun bannissement ne peut être déclenché. Sur Ubuntu 20.04, le chemin attendu dans cet exemple est /var/log/auth.log.

Étape 7 : activer et paramétrer la prison sshd

Dans le même fichier /etc/fail2ban/jail.local, recherchez la section [sshd]. Vérifiez ou ajoutez le bloc complet suivant, puis enregistrez le fichier dans Nano avec Ctrl+O, confirmez avec Entrée et quittez avec Ctrl+X.

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Le résultat attendu est une section [sshd] contenant enabled = true. La valeur port = ssh correspond au service SSH standard ; ne la conservez que si la définition de service et le port effectif correspondent à votre installation.

Étape 8 : activer le service et appliquer la configuration

Activez Fail2ban au démarrage du serveur et lancez-le immédiatement. Cette commande applique la configuration enregistrée et garantit que le service sera relancé après un redémarrage normal d’Ubuntu.

sudo systemctl enable --now fail2ban

Le résultat attendu est un service actif. Si vous modifiez ultérieurement jail.local, appliquez les changements avec la commande suivante, puis contrôlez de nouveau la prison SSH.

sudo systemctl restart fail2ban

Comment vérifier que Fail2ban protège réellement SSH ?

La vérification de Fail2ban commence par l’état du service, puis par la liste des prisons activées. Une installation réussie ne suffit pas : la présence de sshd dans la liste des prisons confirme que la règle SSH est chargée par Fail2ban.

Un bannissement ne prouve pas à lui seul que la configuration est saine. Le contrôle utile consiste à vérifier le journal surveillé, le nombre d’échecs observés et la liste d’adresses actuellement bannies.

Étape 9 : contrôler l’état général du service

Exécutez la commande suivante. La sortie doit indiquer que le service est actif, généralement avec l’état active (running).

systemctl status fail2ban

Si le service est en échec, ne répétez pas les redémarrages sans lire le message affiché. Une erreur de syntaxe dans jail.local ou un journal introuvable dans la prison SSH explique souvent ce type de panne.

Étape 10 : vérifier la liste des prisons et le statut SSH

Interrogez d’abord Fail2ban pour obtenir les prisons actives. La sortie doit contenir une ligne de type Jail list: sshd si la protection SSH est correctement chargée.

sudo fail2ban-client status

Demandez ensuite le détail de la prison SSH. La commande affiche notamment les éléments surveillés et le nombre d’adresses bannies, qui peut rester à zéro sur un serveur sans échecs récents.

sudo fail2ban-client status sshd

La présence de sshd dans l’état général et l’absence d’erreur de service sont les deux premiers contrôles avant tout test de bannissement. Consultez aussi le journal de Fail2ban si un résultat semble incohérent avec les tentatives observées.

Étape 11 : tester le bannissement depuis une autre machine

Effectuez ce test uniquement depuis une autre machine que votre poste d’administration principal, avec une console de secours disponible. Lancez des tentatives SSH volontairement échouées jusqu’au seuil maxretry, puis contrôlez le statut de la prison depuis votre session d’administration restée ouverte.

ssh utilisateur@serveur_fail2ban

Le résultat attendu est l’apparition de l’adresse de la machine de test dans le statut de sshd après le nombre d’échecs configuré. N’utilisez pas ce test sur votre unique adresse d’administration : vous risqueriez de vous exclure du serveur sans moyen immédiat de récupération.

Comment débannir une adresse IP et annuler un blocage ?

Pour débannir une adresse IP avec Fail2ban, utilisez la commande cliente sur la prison concernée, ici sshd. Le déblocage manuel retire immédiatement l’adresse de la liste active, mais ne modifie pas les règles permanentes de configuration.

Une IP débannie qui continue à générer trop d’échecs peut être bloquée de nouveau. Si le blocage concernait un administrateur légitime, corrigez la cause : mauvaise saisie, valeur maxretry trop basse ou omission d’une IP stable dans ignoreip.

Étape 12 : retirer une IP de la liste des bannissements

Remplacez <IP_bannie> par l’adresse IPv4 ou IPv6 exacte à débannir. Vérifiez ensuite le statut de la prison afin de confirmer que l’adresse ne figure plus dans la liste.

sudo fail2ban-client set sshd unbanip <IP_bannie>

sudo fail2ban-client status sshd

Pour bannir manuellement une adresse dans la même prison, la commande correspondante est disponible ci-dessous. Cette action est temporaire : les modifications réalisées via fail2ban-client disparaissent après un redémarrage du service ou du serveur.

sudo fail2ban-client set sshd banip <IP>

Erreurs fréquentes lors de la configuration Fail2ban

Les problèmes rencontrés après une installation Fail2ban Ubuntu viennent le plus souvent d’une prison non activée, d’un fichier de journal absent ou d’une modification faite seulement en mémoire. Le diagnostic doit partir du message de service et du statut précis de sshd, plutôt que d’un changement aléatoire de paramètres.

Un réglage plus sévère ne constitue pas automatiquement un réglage plus sûr. Un temps de bannissement excessif ou un seuil trop bas peut bloquer un utilisateur réel sans réduire les risques qui relèvent d’une mauvaise politique SSH.

• Modifier directement jail.conf : une mise à jour peut écraser la modification. Corrigez toujours jail.local ou un fichier local dans jail.d.
• Oublier enabled = true dans [sshd] : Fail2ban peut démarrer sans charger la prison SSH. Vérifiez avec sudo fail2ban-client status.
• Indiquer un mauvais logpath : Fail2ban ne détecte aucun échec si le journal SSH attendu est absent. Vérifiez le chemin, notamment /var/log/auth.log dans l’exemple Ubuntu 20.04.
• Ajouter une plage trop large à ignoreip : la protection est contournée pour toutes les adresses incluses. Limitez l’exception à l’adresse d’administration réellement nécessaire.
• Changer une règle avec fail2ban-client et croire le réglage permanent : le changement est perdu au redémarrage. Enregistrez les règles durables dans jail.local.

Fail2ban ne démarre pas ou affiche un état failed

Un service en échec signale fréquemment une erreur dans le fichier jail.local. Relisez les dernières lignes modifiées, vérifiez les noms de sections et les valeurs, corrigez le fichier puis relancez le service avec sudo systemctl restart fail2ban.

Le statut système fournit le premier indice exploitable. Une fois la correction appliquée, le résultat attendu est le retour de l’état active (running) dans systemctl status fail2ban.

La prison SSH ne détecte aucune tentative échouée

Une prison SSH inactive ou un chemin de journal erroné empêche Fail2ban de compter les échecs. Contrôlez que la section [sshd] comporte bien enabled = true, puis vérifiez que le journal prévu existe et correspond au service SSH en activité.

Le journal Fail2ban peut aider à comprendre le chargement des prisons. Consultez-le après un redémarrage si l’état de sshd ne correspond pas à la configuration attendue.

cat /var/log/fail2ban.log

Une adresse légitime est bannie

Débannissez l’adresse avec la commande de l’étape 12, puis examinez le nombre d’échecs qui a déclenché le blocage. Ajoutez une adresse stable à ignoreip seulement lorsqu’elle doit réellement être exemptée ; une adresse résidentielle ou mobile qui change régulièrement n’est pas toujours un bon candidat.

Pour une administration plus sûre, évitez de dépendre d’un seul accès. Gardez une console de récupération et une seconde session SSH active pendant les ajustements de bantime, findtime ou maxretry.

Fail2ban, UFW ou clés SSH : que choisir pour sécuriser un serveur Ubuntu ?

Fail2ban, UFW et les clés SSH ne remplissent pas la même fonction. Fail2ban réagit aux échecs visibles dans les journaux, UFW contrôle les flux réseau autorisés et les clés SSH remplacent ou renforcent l’authentification par mot de passe. Une protection SSH cohérente combine ces mécanismes plutôt que de leur demander le même travail.

Le choix dépend de la menace traitée. Fail2ban limite les répétitions d’échecs, tandis qu’une clé SSH réduit l’intérêt d’attaquer un mot de passe et qu’un pare-feu restreint les ports exposés.

Solution	Rôle principal	Limite à connaître	Usage recommandé
Fail2ban	Bannir temporairement après des échecs répétés	Repose sur des journaux correctement lus	Complément pour SSH exposé sur Internet
UFW	Autoriser ou refuser des flux réseau	Ne compte pas les tentatives d’authentification	Réduire les ports accessibles
Clés SSH	Renforcer l’authentification SSH	Demande une gestion rigoureuse des clés	Administration régulière du serveur

Une distribution différente implique parfois des chemins, des versions de paquets ou des comportements de journalisation différents. Pour comparer avec une autre approche de poste Linux, consultez notre article sur l’installation et l’usage de Manjaro Linux, sans transposer automatiquement ses méthodes à Ubuntu Server.

Renforcer SSH au-delà de Fail2ban

Fail2ban protège un serveur Ubuntu contre une partie des tentatives répétées, mais son mécanisme intervient après des échecs d’authentification. La réduction de surface d’attaque commence avant : comptes d’administration identifiés, mises à jour appliquées, accès SSH limité et méthode d’authentification maîtrisée.

La mesure la plus utile reste celle qui élimine une faiblesse précise, vérifiée sur votre serveur, plutôt qu’un empilement de réglages non compris. Pour une situation d’entreprise, un serveur exposé à des données sensibles ou un incident actif, demandez l’avis d’un administrateur système ou d’un professionnel de la cybersécurité compétent.

1. Appliquez les mises à jour de sécurité Ubuntu selon votre politique d’exploitation.
2. Utilisez des comptes nominatifs plutôt qu’un accès partagé entre plusieurs administrateurs.
3. Privilégiez les clés SSH et conservez un moyen de récupération avant toute modification de l’authentification.
4. Limitez les ports réellement nécessaires avec le pare-feu déjà configuré sur le serveur.
5. Contrôlez régulièrement les journaux et les adresses bannies pour détecter un réglage inadapté.

Sources utiles à consulter

La page Fail2ban de la documentation Ubuntu-fr explique le rôle des prisons et les fichiers de configuration associés. Utilisez-la pour vérifier la logique générale des règles, tout en contrôlant les chemins et la version réellement installée sur votre serveur.

La documentation officielle d’Ubuntu et la documentation du projet Fail2ban restent les références à privilégier avant de modifier des options non couvertes par ce guide. Les interfaces, paquets et mécanismes de journalisation peuvent évoluer ; vérifiez toujours le comportement réel de votre machine avant une mise en production.

Questions fréquentes sur Fail2ban et Ubuntu

Fail2ban est-il indispensable sur un serveur Ubuntu ?

Fail2ban n’est pas indispensable dans tous les contextes, mais il ajoute une protection utile contre les tentatives répétées visibles dans les journaux. Fail2ban ne remplace pas un pare-feu, les mises à jour ni une authentification SSH correctement configurée.

Comment savoir si Fail2ban protège réellement SSH ?

Exécutez sudo fail2ban-client status et vérifiez que sshd apparaît dans la liste des prisons. Exécutez ensuite sudo fail2ban-client status sshd pour consulter le statut détaillé et les adresses éventuellement bannies.

Comment modifier la durée d’un bannissement ?

Modifiez la valeur bantime dans la section [DEFAULT] de /etc/fail2ban/jail.local, puis redémarrez le service. Une durée élevée peut bloquer longtemps une adresse légitime ; adaptez-la à votre méthode de récupération d’accès.

Pourquoi une modification faite avec fail2ban-client disparaît-elle ?

Les commandes fail2ban-client modifient l’état en cours d’exécution et ne remplacent pas la configuration enregistrée. Pour rendre un réglage durable, inscrivez-le dans jail.local ou dans un fichier local de /etc/fail2ban/jail.d/.

Puis-je appliquer ce tutoriel directement sur un serveur de production ?

Ce guide vise précisément Ubuntu 20.04 amd64 avec Fail2ban 0.11.x fourni par les dépôts Ubuntu et un service SSH journalisé. Rejouez toute la procédure sur une machine vierge ou un environnement de test avant la mise en production, puis conservez un accès de récupération indépendant de SSH.