Configurer fail2ban pour protéger son VPS Linux

Apprendre à configurer fail2ban VPS est l'une des premières étapes concrètes pour sécuriser un serveur exposé sur Internet. Dès la mise en ligne, les tentatives de brute force SSH commencent en quelques minutes. Ce tutoriel 2026 vous montre comment installer, paramétrer et affiner fail2ban sur un VPS Linux, avec des configurations réelles et exploitables immédiatement en production.
Pourquoi configurer fail2ban sur un VPS Linux
Un VPS accessible en SSH sur Internet est scanné en permanence. Les bots testent des combinaisons login/mot de passe, sondent les ports ouverts et cherchent des services mal protégés. fail2ban agit comme un filtre réactif : il lit les journaux systèmes, détecte les comportements malveillants et bannit temporairement les adresses IP fautives via le pare-feu.
Ce que fail2ban protège et ce qu'il ne remplace pas
Il est important de bien situer l'outil dans une architecture de sécurité. fail2ban gère les attaques applicatives et de type brute force. Il ne remplace pas une protection réseau volumétrique.
- Ce que fail2ban couvre : brute force SSH, tentatives répétées sur des services (SMTP, FTP, panels web), scans applicatifs répétés.
- Ce qu'il ne couvre pas : les attaques DDoS volumétriques (floods UDP/SYN de plusieurs Gbps).
Sur l'infrastructure VPS Linux OmegaCloud, l'anti-DDoS volumétrique est déjà géré au niveau kernel côté réseau, de façon transparente. fail2ban vient donc compléter cette protection en filtrant les abus applicatifs directement sur votre serveur.
Prérequis
- Un VPS Linux (Debian, Ubuntu, Rocky ou Alma).
- Un accès root ou un utilisateur avec droits
sudo. - Un pare-feu actif (nftables, iptables ou ufw).
- Un accès SSH par clé recommandé plutôt que par mot de passe.
Installer et configurer fail2ban VPS pas à pas
La procédure diffère peu selon la distribution. Voici les commandes d'installation pour les familles Debian/Ubuntu et Rocky/Alma.
Installation sur Debian / Ubuntu
sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban
Installation sur Rocky / Alma
sudo dnf install epel-release -y
sudo dnf install fail2ban -y
sudo systemctl enable --now fail2ban
Ne jamais éditer jail.conf directement
Le fichier /etc/fail2ban/jail.conf est écrasé lors des mises à jour du paquet. La bonne pratique consiste à créer un fichier jail.local qui surcharge les valeurs par défaut. C'est une règle systématique en administration système : on ne touche jamais aux fichiers fournis par le paquet.
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
Configuration de base recommandée
Voici une configuration jail.local minimale et saine pour un VPS de production. Adaptez la section [DEFAULT] puis activez explicitement la jail SSH.
[DEFAULT]
# Ignorer vos propres IP de confiance (bureau, VPN interne)
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
# Durée du bannissement (10 minutes)
bantime = 10m
# Fenêtre d'observation
findtime = 10m
# Nombre de tentatives avant bannissement
maxretry = 5
# Backend recommandé sur systemd
backend = systemd
[sshd]
enabled = true
port = ssh
maxretry = 4
bantime = 1h
Sur les distributions récentes utilisant systemd, le backend systemd lit directement le journal via journald, ce qui évite les problèmes liés à la rotation des fichiers de log. Si votre port SSH est personnalisé, remplacez port = ssh par le numéro réel, par exemple port = 2222.
Appliquer la configuration
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd
La commande fail2ban-client status sshd affiche le nombre de tentatives détectées et les IP actuellement bannies. C'est votre point de contrôle principal au quotidien.
Personnaliser les jails et le bantime
Une fois la base opérationnelle, il faut affiner le comportement selon votre usage réel. Un VPS hébergeant un service web n'aura pas les mêmes besoins qu'un serveur mail.
Bannissement progressif avec bantime.increment
fail2ban peut allonger automatiquement la durée de bannissement d'une IP récidiviste. Cette fonctionnalité limite fortement les bots persistants sans surcharger vos règles pare-feu.
[DEFAULT]
bantime.increment = true
bantime.rndtime = 5m
bantime.maxtime = 168h
bantime.factor = 2
Avec cette configuration, une IP bannie une première fois pour 1 heure verra sa peine doubler à chaque récidive, jusqu'à un plafond d'une semaine. C'est une approche pragmatique et efficace contre les scanners récurrents.
Exemple de jail pour un service web
Si vous exposez Nginx ou Apache, vous pouvez protéger contre les tentatives d'authentification répétées et les scans agressifs.
[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 5
[nginx-limit-req]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 60
Choisir la bonne action de bannissement
fail2ban peut interagir avec différents backends de pare-feu. Le choix dépend de ce qui est déjà actif sur votre VPS.
| Contexte | Action recommandée | Remarque |
|---|---|---|
| nftables (moderne) | banaction = nftables-multiport |
Recommandé sur Debian 12+ et distributions récentes |
| iptables (legacy) | banaction = iptables-multiport |
Compatibilité étendue |
| ufw actif | Laisser fail2ban gérer via iptables/nftables | Éviter les conflits de règles |
Pour définir l'action globalement, ajoutez dans la section [DEFAULT] :
[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports
Coordonner fail2ban avec ufw
Beaucoup d'administrateurs utilisent ufw pour la gestion simple des ports. fail2ban et ufw peuvent cohabiter sans problème tant que vous laissez fail2ban insérer ses propres règles. Une configuration ufw de base ressemble à ceci :
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Gérer, tester et surveiller fail2ban au quotidien
Une fois fail2ban configuré, l'exploitation courante repose sur quelques commandes clés et une bonne intégration à votre supervision.
Commandes essentielles de fail2ban-client
# Voir toutes les jails actives
sudo fail2ban-client status
# Détail d'une jail
sudo fail2ban-client status sshd
# Débannir une IP manuellement
sudo fail2ban-client set sshd unbanip 203.0.113.55
# Bannir manuellement une IP
sudo fail2ban-client set sshd banip 198.51.100.20
# Recharger la configuration sans coupure
sudo fail2ban-client reload
Tester une expression de détection
Avant de mettre une jail en production, validez votre filtre avec fail2ban-regex. Cet outil confronte un fichier de log à une expression et affiche le nombre de correspondances.
sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
Vérifier les règles réellement appliquées
fail2ban insère ses bannissements dans le pare-feu. Vous pouvez le vérifier directement côté noyau.
# Avec nftables
sudo nft list ruleset | grep -i f2b
# Avec iptables
sudo iptables -L -n | grep -i f2b
Débannir une IP légitime en urgence
Un cas classique : vous vous bannissez vous-même après plusieurs erreurs de saisie. Si vous perdez l'accès SSH, la console KVM devient indispensable. Depuis le panel OmegaCloud, la console KVM vous donne un accès direct au VPS même quand SSH est inaccessible, ce qui permet de débannir votre IP sans reinstaller quoi que ce soit.
Bonnes pratiques complémentaires
fail2ban est plus efficace lorsqu'il s'inscrit dans une hygiène de sécurité globale :
- Authentification SSH par clé uniquement : désactivez l'authentification par mot de passe dans
/etc/ssh/sshd_configavecPasswordAuthentication no. - Générer une paire de clés robuste :
ssh-keygen -t ed25519 -C "admin@monvps"
- Activer le 2FA sur le panel de gestion pour protéger l'accès à l'infrastructure.
- Limiter les jails actives à vos services réellement exposés pour éviter les faux positifs.
- Sauvegarder régulièrement via snapshots avant toute modification lourde de configuration.
Pour les détails de configuration du démon SSH, la documentation de référence reste la plus fiable : Source.
Persistance des bannissements après reboot
Par défaut, fail2ban conserve son état dans une base SQLite (/var/lib/fail2ban/fail2ban.sqlite3). Les IP bannies avec bantime long sont donc restaurées au redémarrage du service. Vérifiez que cette base est bien active :
grep dbfile /etc/fail2ban/fail2ban.conf
Cette persistance garantit qu'un reboot planifié ou une réinstallation partielle ne remet pas à zéro votre historique de récidivistes.
Conclusion
Bien configurer fail2ban sur un VPS transforme un serveur exposé en cible beaucoup moins rentable pour les bots. En combinant jails ciblées, bantime progressif, clés SSH et pare-feu propre, vous couvrez la majorité des attaques applicatives. Associé à une protection réseau côté infrastructure, cet outil constitue une base solide et maintenable pour n'importe quel environnement de production Linux.
FAQ
fail2ban protège-t-il contre les attaques DDoS volumétriques ?
Non. fail2ban filtre les tentatives applicatives comme le brute force SSH ou les scans répétés, en bannissant les IP au niveau du pare-feu. Il n'est pas conçu pour absorber des floods de plusieurs Gbps. Sur les VPS OmegaCloud, cette mitigation volumétrique est déjà assurée au niveau réseau, de manière transparente.
Comment débannir mon adresse IP si je me suis bloqué en SSH ?
Utilisez la console KVM depuis le panel pour accéder au serveur sans SSH, puis exécutez sudo fail2ban-client set sshd unbanip VOTRE_IP. Ajoutez ensuite votre IP dans ignoreip du fichier jail.local pour éviter que cela se reproduise.
Faut-il modifier jail.conf ou jail.local ?
Toujours jail.local. Le fichier jail.conf est fourni par le paquet et sera écrasé à chaque mise à jour. En plaçant vos surcharges dans jail.local, votre configuration survit aux upgrades et reste facile à maintenir.
Prêt à mettre en pratique ce que vous venez de lire ?
Découvrir nos offres

