Ce qu’on voit d’abord dans les tickets de support : plusieurs visiteurs signalent un accès bloqué au site, avec un message générique de type « votre adresse IP a été bannie », alors qu’ils n’ont rien fait d’anormal. Douze cas recensés en une semaine, sur un site qui n’en connaissait quasiment aucun auparavant. La cause commune : l’ajout récent de Fail2ban au niveau du serveur, en plus de Wordfence déjà actif depuis longtemps côté WordPress.
Pourquoi c’est un problème : les deux outils surveillent, chacun de leur côté, les tentatives de connexion échouées sur wp-login.php, et bannissent une adresse IP au-delà d’un certain seuil de tentatives. Configurés indépendamment, sans coordination, ils finissent par appliquer des critères de bannissement redondants, voire contradictoires, ce qui multiplie les faux positifs sur des visiteurs qui ont simplement tapé leur mot de passe deux fois de travers.
Ce qu’on observe concrètement
Wordfence, configuré avec un seuil de blocage à cinq tentatives échouées en cinq minutes, bannit l’adresse IP au niveau applicatif WordPress. Fail2ban, configuré séparément par l’équipe système avec son propre filtre sur les journaux d’accès nginx, applique un seuil différent, disons dix tentatives en dix minutes, mais au niveau du pare-feu système, donc plus bas dans la pile réseau.
Un visiteur qui déclenche le seuil Wordfence se retrouve banni côté applicatif, ce qui génère malgré tout des requêtes supplémentaires (tentatives de reconnexion, actualisations de page) qui, cumulées, peuvent également déclencher le seuil Fail2ban peu après. Résultat : la même adresse IP se retrouve doublement bannie, avec deux mécanismes de déblocage différents à gérer pour le support, l’un via l’interface Wordfence, l’autre via fail2ban-client en ligne de commande.
Pourquoi c’est un problème plus profond qu’un simple doublon
Au-delà de la gêne pour le support, ce chevauchement révèle une absence de répartition claire des responsabilités entre les deux couches de sécurité. Sans coordination, chaque outil ajuste ses seuils indépendamment au fil du temps, et personne ne sait plus, en cas d’incident, lequel des deux a réellement bloqué telle adresse IP à quel moment.
# Vérifier côté Fail2ban
fail2ban-client status wordpress-auth
# Vérifier côté Wordfence, via WP-CLI si l'extension le permet
wp wordfence show-options | grep lockout
Quoi faire : répartir les responsabilités
La répartition qui a fonctionné sur ce projet consiste à laisser chaque outil couvrir une couche distincte, sans chevauchement de critère :
- Fail2ban : bannissement réseau générique, basé sur le volume brut de requêtes suspectes tous types confondus (scan de ports, tentatives sur des routes inexistantes), pas spécifiquement sur
wp-login.php - Wordfence : bannissement applicatif spécifique à WordPress, seul responsable du seuil de tentatives de connexion échouées sur le formulaire de connexion
# jail.local, filtre spécifique wp-login désactivé pour éviter le doublon
[wordpress-auth]
enabled = false
Fail2ban conserve ses autres filtres (protection SSH, scan de vulnérabilités générique) qui ne concernent pas l’authentification WordPress, tandis que Wordfence reste seul décisionnaire sur les tentatives de connexion au back-office.
Documenter la répartition pour l’équipe
Deux outils de sécurité qui font le même travail sans le savoir ne protègent pas mieux qu’un seul : ils ajoutent de la confusion en cas d’incident et multiplient les faux positifs sur des visiteurs légitimes. Documenter clairement qui fait quoi évite ce piège dès l’ajout d’un second outil.
Un tableau simple, tenu à jour dans la documentation interne du serveur, listant chaque outil de sécurité actif et son périmètre exact de responsabilité, évite qu’un futur ajout d’outil ne recrée le même chevauchement quelques mois plus tard.
En résumé
Fail2ban et Wordfence actifs simultanément sur les mêmes critères de bannissement finissent par se marcher dessus plutôt que de se compléter, au prix de visiteurs légitimes bloqués à tort. La solution ne consiste pas à retirer l’un des deux outils, mais à répartir clairement leurs responsabilités respectives : le réseau générique pour Fail2ban, l’authentification applicative WordPress pour Wordfence, chacun désactivé sur le périmètre de l’autre.
