Tous les services opérationnels Devise EUR Aucun frais de mise en service Vous êtes à La Réunion ?
Espace client
Se connecter
‹ Serveurs VPS et Docker

Fail2ban : installer et configurer sur Linux

Fail2ban lit les journaux de votre serveur et bannit pour un temps les adresses IP qui accumulent les échecs, typiquement les robots qui essaient des mots de passe sur SSH. Il s'installe en une commande sur Ubuntu ou Debian, puis se règle dans un fichier .local, jamais dans jail.conf. Sur un serveur qui fait tourner Docker, les ports publiés par les conteneurs demandent un réglage à part.

Par Jonathan Dewaele · publié le

Ce guide s'appuie sur le fichier jail.conf livré par le projet et sur le wiki de fail2ban, consultés le 14 octobre 2026.

Ce que fait fail2ban, et ce qu'il ne fait pas

Chaque « prison » (jail) surveille un service : elle lit son journal, compte les échecs d'une même adresse et, au-delà d'un seuil, ajoute une règle de pare-feu qui bloque cette adresse pendant une durée donnée. Fail2ban réduit le bruit et ralentit les attaques par force brute. Il ne remplace ni la connexion SSH par clé, ni des mises à jour régulières.

Installer fail2ban

  1. Installez le paquet : sudo apt update puis sudo apt install fail2ban.
  2. Activez le service au démarrage : sudo systemctl enable --now fail2ban.
  3. Vérifiez qu'il tourne : sudo fail2ban-client status liste les prisons actives.

Par défaut, toutes les prisons sont désactivées, comme le rappelle jail.conf : il faut activer celles dont vous avez besoin.

Régler la prison SSH

Le fichier /etc/fail2ban/jail.conf porte cet avertissement : ne pas le modifier, il sera remplacé à la prochaine mise à jour. Les réglages vont dans jail.local ou dans un fichier de /etc/fail2ban/jail.d/ qui finit par .local.

Créez par exemple /etc/fail2ban/jail.d/ssh.local :

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
bantime.increment = true
  1. `maxretry` et `findtime` fixent le seuil : ici, cinq échecs en dix minutes. Les valeurs par défaut de jail.conf sont les mêmes.
  2. `bantime` fixe la durée du bannissement. La valeur par défaut est de dix minutes, une heure est plus dissuasive.
  3. `bantime.increment` allonge le bannissement des adresses qui reviennent après un premier bannissement, à partir de la base de données de fail2ban.
  4. `backend = systemd` fait lire le journal de systemd plutôt qu'un fichier : c'est ce qu'il faut sur les systèmes récents où SSH n'écrit plus dans /var/log/auth.log.
  5. Rechargez la configuration : sudo fail2ban-client reload.

Pour ne jamais bannir votre propre adresse, ajoutez une ligne ignoreip dans la section, avec les adresses ou plages séparées par des espaces.

Les commandes du quotidien

sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo fail2ban-client unban 203.0.113.10
sudo fail2ban-client -d

La première liste les prisons, la deuxième montre les adresses bannies par la prison SSH, la troisième débannit une adresse partout, la dernière affiche la configuration complète telle que fail2ban la lit, pratique pour vérifier qu'un réglage a bien été pris.

Protéger un service qui tourne dans Docker

Un port publié par un conteneur ne passe pas par la chaîne INPUT du pare-feu du serveur, celle où fail2ban place ses règles par défaut : une adresse bannie de SSH peut donc encore atteindre un service Docker. Le wiki consacré à Docker recommande de régler la chaîne prison par prison, avec chain = DOCKER-USER pour les services en conteneur, et de laisser les autres sur INPUT :

[DEFAULT]
chain = INPUT

[sshd]
enabled = true

[apache-auth]
enabled = true
logpath = /chemin/vers/les/journaux/*error_log
chain = DOCKER-USER

Basculer toutes les prisons sur DOCKER-USER serait l'erreur inverse : SSH, qui tourne directement sur le serveur, ne serait plus protégé. Pour un service en conteneur, la prison doit aussi pouvoir lire ses journaux : montez-les dans un dossier du serveur, ou faites écrire le conteneur dans le journal de systemd.

Sur un VPS Hubspace

Fail2ban est installé et actif à la livraison, avec cette prison SSH (fichier /etc/fail2ban/jail.d/hubspace.local) :

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
bantime.increment = true
  • Cinq essais en dix minutes valent un bannissement d'une heure, qui s'allonge si l'adresse récidive. La connexion se fait par clé seulement : les robots qui essaient des mots de passe échouent de toute façon, fail2ban les écarte plus vite.
  • Vous pouvez ajouter vos propres prisons dans d'autres fichiers .local du même dossier. Le fichier de Hubspace n'est réécrit qu'à une réinstallation du serveur.
  • Le pare-feu réseau, en amont du serveur, n'ouvre que les ports 22, 80 et 443. Les services Docker exposés passent normalement derrière un proxy en HTTPS, sur 443 : c'est là qu'une prison DOCKER-USER prend son sens, en lisant les journaux du proxy.
  • Si vous vous bannissez vous-même, connectez-vous depuis une autre adresse et lancez sudo fail2ban-client unban avec votre adresse, ou attendez la fin du bannissement. En dernier recours, le support peut vous rendre l'accès.

Pour la connexion elle-même, voir se connecter en SSH et la page des serveurs VPS.

Questions fréquentes

Fail2ban suffit-il à protéger SSH ?

Non. La protection principale est la connexion par clé, avec les mots de passe désactivés. Fail2ban s'ajoute par-dessus : il réduit le volume des tentatives et le bruit dans les journaux.

Pourquoi mes bannissements n'empêchent-ils pas l'accès à un conteneur ?

Parce que le trafic vers un port publié par Docker passe par une autre chaîne du pare-feu que celle où fail2ban écrit par défaut. Réglez chain = DOCKER-USER sur la prison qui protège ce service.

Où voir ce que fail2ban a fait ?

sudo fail2ban-client status sshd donne le nombre d'échecs et les adresses bannies. Le détail est dans le journal du service : sudo journalctl -u fail2ban.

Articles liés