Vous tapez vos identifiants pour la énième fois et plus rien ne répond : Plesk affiche un timeout, le client SFTP tourne dans le vide, le webmail refuse même la page de login. Neuf fois sur dix, ce n'est ni une panne ni un mauvais mot de passe. C'est votre IP publique qui vient de se faire bannir par fail2ban, le garde du corps de nos serveurs. Bonne nouvelle : c'est temporaire, et on va voir comment s'en sortir.
Comment savoir si c'est bien un ban IP
Les symptômes classiques :
- La veille tout marchait, aujourd'hui plus rien, depuis le même poste.
- Timeout complet sur le port concerné (22 pour SSH/SFTP, 8443 pour Plesk, 993/465 pour le mail, 443 pour le webmail).
- Les autres sites web du serveur (en HTTP/HTTPS public) répondent normalement depuis votre navigateur.
- Un collègue sur un autre réseau, lui, se connecte sans souci.
Si tout ça colle, l'hypothèse ban IP est solide.
Le test qui tranche : passer en 4G
Activez le partage de connexion de votre téléphone, basculez votre laptop dessus, retentez l'accès. Si la connexion passe, le problème est bien côté IP de votre bureau ou de votre domicile.
curl ifconfig.me dans un terminal. Copiez la valeur : c'est cette IP qui est bannie, et c'est elle qu'il faudra fournir dans le ticket.
Ce que fait fail2ban, en deux lignes
fail2ban lit en continu les logs d'authentification du serveur (SSH, FTP, Dovecot, Postfix, Plesk, webmail) et compte les échecs. Au delà d'un certain seuil (souvent 3 à 5 tentatives ratées en quelques minutes), il ajoute une règle iptables qui drop le trafic de l'IP fautive pendant une durée variable. Sur nos serveurs, les jails les plus courantes sont :
ssh-iptables— tentatives SSH ratées.plesk-panel— mauvais mot de passe sur:8443.plesk-apache-auth— erreurs d'auth HTTP basique (zones protégées, admin WordPress mal configuré, etc.).dovecot— échecs IMAP/POP.postfix-sasl— échecs SMTP authentifié.plesk-wordpress— bruteforce surwp-login.php.
Le ban est temporaire. Selon la jail et l'historique de récidive, il dure de quelques minutes à quelques heures. Il n'y a jamais de ban définitif automatique.
Les trois solutions côté client
1. Attendre
La plus simple. Prenez un café, revenez dans 20 à 30 minutes, retentez depuis votre réseau habituel. Dans la majorité des cas, c'est réglé.
2. Changer de réseau
Partage de connexion 4G, wifi d'un voisin, café d'à côté : une IP différente = pas de ban. Utile si vous devez absolument pousser un correctif dans la minute.
3. Passer par un VPN
Si vous disposez d'un VPN d'entreprise ou commercial (Proton, Mullvad, etc.), activez-le. Vous sortirez avec une IP différente, non bannie. Attention : certains VPN ont des IP déjà vues comme sources d'attaques, et le ban peut retomber vite. Préférez une localisation France peu fréquentée.
Demander un déblocage via ticket
Si l'attente n'est pas tenable (mise en prod urgente, accès bloqué depuis plusieurs heures, ban répétitif), ouvrez un ticket sur servicedesk.datacampus.fr. Pour qu'on agisse vite, fournissez :
- Votre IP publique exacte, celle qui est bannie (pas l'IP du serveur). Récupérée via
curl ifconfig.medepuis le réseau impacté, ou via ifconfig.me. - Le service concerné : SSH, SFTP, Plesk, webmail IMAP, SMTP, admin WordPress, etc. Plus on est précis, plus on vise la bonne jail.
- Le serveur : nom de domaine de connexion (
votre-serveur.datacampus.fr) ou nom du site concerné. - Une estimation de l'horaire où ça a commencé à bloquer (au quart d'heure près), pour qu'on retrouve rapidement la ligne de log.
- Le contexte si vous le connaissez : migration d'un site avec un script qui a bouclé sur un mot de passe périmé, membre de l'équipe qui a changé son mot de passe sans prévenir le client mail, etc. Ça aide à décider s'il faut aussi whitelister votre IP.
82.xx.yy.zz est bannie sur serveur-mutu-03.datacampus.fr, service SFTP, ça bloque depuis ~14h10. Probablement mon client FileZilla qui a retenté un vieux mot de passe. Merci de débannir. » Tout y est.
Pour aller plus loin sur la manière d'écrire des tickets qui vont vite, voir Ouvrir un ticket support efficace.
Prévenir plutôt que guérir
Quelques réflexes qui éliminent 90 % des bans fail2ban.
Mots de passe propres, stockés dans un gestionnaire
La cause numéro un d'un ban, c'est un client (FileZilla, Outlook, un cron, un script de déploiement) qui retente en boucle un mot de passe obsolète. Dès qu'un mot de passe change, mettez à jour toutes ses copies : gestionnaire (Bitwarden, 1Password), clients mail, favoris FileZilla, variables CI/CD, crons. Un ancien laptop oublié qui synchronise un IMAP tous les quarts d'heure, et c'est le ban garanti.
Clés SSH plutôt que mots de passe
Pour SSH et SFTP, abandonnez le mot de passe au profit des clés publiques. Elles ne déclenchent pas les bans fail2ban en cas de mauvaise config cliente (la tentative échoue en silence, côté protocole, sans figurer comme un échec d'auth bruteforce). Et c'est plus sûr. Voir la doc dédiée Se connecter en SSH/SFTP.
Whitelist d'une IP fixe pour votre agence
Si votre bureau ou votre VPN d'entreprise dispose d'une IP publique fixe, demandez par ticket à la whitelister côté fail2ban. Pratique pour les agences qui déploient souvent, les développeurs qui relancent des scripts, les équipes support qui se reconnectent en boucle. On ne whitelistera pas une IP grand public dynamique (box résidentielle qui change d'IP chaque semaine), mais on peut traiter une plage d'opérateur pro sans souci.
www-data partagé), ce qui limite déjà pas mal les dégâts d'une compromission — mais on ne lâche pas sur ce point là.
Récap express
- Plus d'accès SSH/SFTP/Plesk/mail ? Testez en 4G.
- Si la 4G passe, c'est un ban IP. Récupérez votre IP publique.
- Attendez 20-30 min, ou ouvrez un ticket avec IP + service + horaire.
- Purgez les vieux mots de passe de vos clients, passez à SSH en clé, et whitelist d'IP fixe si vous êtes une agence.