WordPress alimente plus de 43 % du web mondial — ce qui en fait la cible numéro un des attaques automatisées. Selon Wordfence, plus de 90 milliards de requêtes malveillantes de connexion sont bloquées chaque mois sur les sites WordPress protégés par leur pare-feu. La grande majorité sont des attaques brute force : des bots qui testent des milliers de combinaisons identifiant/mot de passe jusqu’à trouver la bonne.
Ces attaques ciblent principalement trois points d’entrée :
Un serveur sans protection peut recevoir des dizaines de milliers de tentatives par heure, saturant les ressources et augmentant le risque de compromission. C’est là qu’intervient Fail2Ban : en analysant vos logs en temps réel, il identifie les IP agressives et les bannit automatiquement au niveau du pare-feu — avant même que PHP ou WordPress ne soit sollicité.
Fail2Ban s’installe sur le serveur qui héberge votre WordPress. Vous avez besoin :
⚠️ Hébergement mutualisé : Fail2Ban nécessite un accès système complet. Il n’est pas disponible sur les hébergements mutualisés classiques. Dans ce cas, des alternatives comme les plugins WordPress (Limit Login Attempts Reloaded, WP Cerber) ou un pare-feu applicatif (Cloudflare, Sucuri) offrent une protection similaire.
sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2bansudo dnf install epel-release -y
sudo dnf install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2banVérifiez que Fail2Ban est bien actif :
sudo fail2ban-client statusLa configuration de Fail2Ban repose sur deux types de fichiers :
/etc/fail2ban/filter.d/) — définissent les patterns à détecter dans les logs/etc/fail2ban/jail.local) — définissent les actions à prendre et les seuils de bannissementToujours créer un fichier jail.local plutôt que de modifier jail.conf directement — ce dernier peut être écrasé lors des mises à jour.
Créez le fichier /etc/fail2ban/filter.d/wordpress.conf :
[Definition]
failregex = ^<HOST> .* "POST .*wp-login\.php.*" (200|403|404) .*$
^<HOST> .* "POST .*xmlrpc\.php.*" (200|403) .*$
ignoreregex =Ce filtre détecte toutes les requêtes POST vers wp-login.php et xmlrpc.php — les deux cibles principales des attaques brute force.
Si vous utilisez Nginx, le format des logs est légèrement différent. Créez /etc/fail2ban/filter.d/wordpress-nginx.conf :
[Definition]
failregex = ^<HOST> - .* "POST .*wp-login\.php.*" (200|403|404|429) .*$
^<HOST> - .* "POST .*xmlrpc\.php.*" (200|403|429) .*$
^<HOST> - .* "POST .*/wp-json/.*authentication.*" 4[0-9]{2} .*$
ignoreregex =Éditez (ou créez) /etc/fail2ban/jail.local et ajoutez :
[DEFAULT]
# Bannissement de 1 heure par défaut
bantime = 3600
# Fenêtre d'observation : 10 minutes
findtime = 600
# Nombre max de tentatives avant bannissement
maxretry = 5
# Votre IP de gestion (ne jamais se bannir soi-même !)
ignoreip = 127.0.0.1/8 ::1 VOTRE_IP_ADMIN
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/apache2/access.log
maxretry = 5
bantime = 7200
findtime = 300
[wordpress-nginx]
enabled = true
filter = wordpress-nginx
logpath = /var/log/nginx/access.log
maxretry = 5
bantime = 7200
findtime = 300Paramètres clés :
maxretry = 5 → bannissement après 5 tentatives échouéesfindtime = 300 → les 5 tentatives doivent se produire dans une fenêtre de 5 minutesbantime = 7200 → l’IP est bannie pendant 2 heures⚠️ Important : Renseignez impérativement votre propre IP dans ignoreip pour ne pas vous bannir accidentellement lors d’une fausse manœuvre. Vous pouvez connaître votre IP avec : curl ifconfig.me
sudo systemctl restart fail2ban
sudo fail2ban-client status wordpress
sudo fail2ban-client status wordpress-nginxVous devriez voir la jail active avec le nombre d’IPs actuellement bannies.
Pour les attaquants récidivistes, un bannissement temporaire ne suffit pas. Vous pouvez configurer un bannissement progressif avec le module recidive de Fail2Ban :
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
filter = recidive
bantime = 604800 ; 7 jours
findtime = 86400 ; 24 heures
maxretry = 3 ; 3 bannissements en 24h → ban 7 joursCe mécanisme fonctionne en cascade : si une IP se fait bannir 3 fois en 24 heures (par n’importe quelle jail), elle est automatiquement bannie pour 7 jours entiers. Les attaquants les plus persistants peuvent ainsi être bannis de façon permanente en ajoutant des entrées directement dans iptables.
Fail2Ban agit au niveau du serveur, mais une défense en profondeur nécessite aussi des protections côté WordPress :
wp-login.php par une URL personnalisée avec WPS Hide Login réduit drastiquement les tentatives automatisées.Pour une protection complète contre les bots, consultez également notre guide sur la protection WordPress contre les bots malveillants qui couvre les solutions WAF, Cloudflare et les règles .htaccess.
# Toutes les jails actives
sudo fail2ban-client status
# IPs bannies pour la jail WordPress
sudo fail2ban-client status wordpresssudo fail2ban-client set wordpress unbanip VOTRE_IP# Tester le filtre contre un fichier de log existant
sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress-nginx.confCette commande affiche le nombre de lignes matchées par votre filtre — si le résultat est 0, vérifiez le format de vos logs et ajustez le regex en conséquence.
sudo tail -f /var/log/fail2ban.logVous verrez défiler les bannissements en direct. Un volume élevé d’IPs bannies indique une attaque en cours.
Oui, si vous oubliez de renseigner votre IP dans ignoreip et que vous effectuez plusieurs tentatives de connexion échouées (par exemple après un changement de mot de passe oublié). C’est pourquoi il est impératif de toujours ajouter votre IP d’administration dans la directive ignoreip de jail.local. En cas de bannissement accidentel, débannissez-vous depuis une autre IP ou directement en console serveur avec la commande fail2ban-client set wordpress unbanip VOTRE_IP.
Idéalement oui. Fail2Ban bannit les IP après X tentatives, mais une attaque multicall XML-RPC peut tester des milliers de mots de passe en une seule requête — avant que Fail2Ban n’ait le temps de réagir. La combinaison optimale : désactiver XML-RPC si vous ne l’utilisez pas + Fail2Ban pour wp-login.php et l’API REST. Selon Patchstack, XML-RPC est responsable de près de 20 % des compromissions WordPress liées aux brute force.
Oui, mais avec une subtilité importante : si vous utilisez Cloudflare comme proxy, les logs de votre serveur afficheront les IP des serveurs Cloudflare plutôt que les vraies IP des attaquants. Vous devez configurer votre serveur web pour restaurer les vraies IP (via le module mod_remoteip sur Apache ou ngx_http_realip_module sur Nginx). Sans cette configuration, Fail2Ban risquerait de bannir les IP Cloudflare — coupant tout votre trafic.
Les plugins WordPress (Limit Login Attempts, WP Cerber) agissent au niveau applicatif : ils bloquent les tentatives après X essais, mais PHP et WordPress sont quand même chargés à chaque requête. Fail2Ban agit en amont, au niveau du pare-feu système : une fois une IP bannie, ses requêtes sont rejetées sans aucune charge serveur. Sur un site sous attaque intense, la différence de charge peut être considérable.
Configurer Fail2Ban pour WordPress est une des mesures de sécurité les plus efficaces et les moins coûteuses que vous puissiez mettre en place sur un serveur dédié ou VPS. En bannissant automatiquement les attaquants au niveau du pare-feu, vous réduisez non seulement le risque de compromission mais aussi la charge serveur générée par ces attaques.
Récapitulatif des étapes clés :
wordpress.conf et wordpress-nginx.confjail.local avec vos seuils et votre IP en whitelistrecidive pour les attaquants persistants/var/log/fail2ban.log régulièrementVous êtes sur hébergement mutualisé ou vous souhaitez une protection clé en main ? Contactez notre équipe SecuriteWP — nous configurons et supervisons la sécurité de votre site WordPress de A à Z.
En avril 2026, plus de 20 plugins du vendeur EssentialPlugin ont été compromis via une attaque supply chain. Un acquéreur malveillant avait planté une backdoor dormante 7 mois avant son activation. 200 000+ sites WordPress exposés.
Découvrez comment configurer Cloudflare pour protéger votre site WordPress : WAF, protection DDoS, règles de sécurité et intégration optimale avec vos plugins.
Découvrez comment implémenter une Content Security Policy (CSP) sur WordPress pour bloquer les attaques XSS. Guide complet 2026 avec directives, exemples de code et dépannage.
Les attaques supply chain WordPress ciblent la chaîne de distribution des plugins et thèmes. Découvrez comment elles fonctionnent, les IOC à surveiller et les mesures concrètes pour protéger votre site.
Votre base de données MySQL est le cœur de WordPress : elle contient tout. Découvrez comment la sécuriser avec 8 techniques concrètes pour 2026.
Découvrez quelles permissions de fichiers appliquer sur WordPress (644, 755, 600) pour sécuriser votre installation et éviter les intrusions. Guide complet 2026 avec commandes SSH.
Nos experts français assurent un support et une prestation de qualité.
