WordPress est un socle solide, mais le back-office reste une cible très rentable. Les attaques ne se limitent pas aux “mauvaises intentions” : il y a aussi le bruit permanent du scan automatisé, des comptes compromis ailleurs, des tentatives de force brute qui tournent jour et nuit, et parfois des erreurs de configuration qui transforment un site en exercice de devinettes.
Le durcissement WordPress ne consiste pas à “rendre impossible” toute connexion. Ce n’est pas réaliste. L’objectif pratique, c’est de réduire la surface d’attaque, ralentir les attaques automatisées, et surtout empêcher que quelques secondes d’erreur ou de faiblesse ne deviennent un accès administrateur complet.
Dans cet article, je détaille des méthodes concrètes pour verrouiller les tentatives de connexion au back-office, avec leurs limites et leurs effets de bord. L’idée est simple : chaque couche doit rendre l’attaque moins profitable, sans casser l’usage normal pour les vrais humains.
Pourquoi les attaques visent le /wp-admin plutôt que le site public
La partie publique de WordPress peut être attaquée, bien sûr. Mais le back-office attire parce qu’il concentre l’impact. Une fois connecté en administrateur, l’attaquant peut modifier des thèmes, injecter du code, créer des comptes, ouvrir des redirections, et effacer ses traces.
Sur le terrain, on observe souvent un schéma récurrent :
- des scans répétés sur des URL connues (wp-login.php, wp-admin, parfois des endpoints additionnels), des essais de mots de passe très courts ou issus de fuites, des rafales sur quelques IP, puis une dispersion (botnets ou services proxy), et des pics qui coïncident avec des campagnes, ou avec l’expiration de certaines listes de credentials.
Même si votre site n’a aucun contenu “sensible”, l’accès admin reste un coffre fort. Et le back-office, avec ses formulaires et ses réponses, fournit suffisamment d’informations pour qu’un script automatisé ajuste sa stratégie.
Ce que “verrouiller” veut dire, concrètement
Verrouiller ne veut pas dire “fermer hermétiquement”. Dans la vraie vie, vous devez choisir des compromis.
Un verrouillage utile se matérialise par trois effets :
Décourager la force brute avec un ralentissement ou un blocage temporaire. Réduire la probabilité qu’un attaquant teste au bon endroit, au bon moment, depuis une source fiable. Garder un accès légitime pour vos équipes, vos clients, ou vous-même.Le bon durcissement WordPress, c’est celui qui tient six mois en production sans créer des “surprises” lors d’une rotation de mots de passe, d’un déplacement, ou d’un changement d’IP chez un prestataire.
Commencer par un état des lieux : logs, traces, et symptômes
Avant de modifier quoi que ce soit, je recommande de regarder deux choses, parce que ça pilote le choix des mesures :
- Vos logs d’accès au niveau serveur ou reverse proxy : fréquence des requêtes sur wp-login.php, distribution par IP, temps moyen entre tentatives. Vos logs WordPress ou votre journalisation applicative : événements d’échec, réponses au login, éventuellement des plugins de sécurité déjà en place.
Sur un exemple classique, vous pouvez avoir des tentatives d’échec toutes les 30 secondes sur une même IP. À côté, vous pouvez avoir des vagues plus rapides, mais beaucoup plus dispersées. Dans le premier cas, un blocage temporaire par IP marche très bien. Dans le second, il faut penser plus large, par exemple au niveau réseau (reverse proxy, WAF) ou à l’authentification renforcée.
Cette étape évite un piège fréquent : ajouter un durcissement strict, puis découvrir que vos propres partenaires ne peuvent plus se connecter parce qu’ils passent par des IP dynamiques ou des VPN qui changent toutes les heures.
La base incontournable : durcir l’authentification avant même le “verrouillage” des échecs
Avant de penser aux tentatives, sécurisez la clé qui les rend dangereuses. Deux points font la différence, et ce sont souvent les plus rentables :
Mots de passe et comptes : supprimer les fragilités inutiles
Si votre site a encore des comptes “anciens” créés pour une maintenance ponctuelle, gardez à l’esprit qu’un attaquant ne cherche pas la complexité, il cherche un point faible. Supprimer les comptes inutiles, appliquer des mots de passe longs (idéalement via un gestionnaire), et éviter la réutilisation d’identifiants est un préalable.
Je me méfie aussi des scénarios où “tout le monde a les mêmes droits” ou “le même compte admin est utilisé à plusieurs endroits”. Une fois qu’un identifiant fuit, le rayon d’impact augmente.
L’authentification à deux facteurs (2FA) pour le back-office
Le 2FA, lui, ne bloque pas la tentative brute. Mais il rend la tentative beaucoup moins utile. Les bots qui tentent uniquement des mots de passe échouent après le premier écran, et vous gagnez du temps pour absorber des vagues d’attaque.
Le bon compromis consiste souvent à activer la 2FA pour les rôles sensibles uniquement, ou à exiger la 2FA pour tout compte ayant accès à wp-admin. Selon vos contraintes, cela peut demander un peu d’organisation, par exemple pour les comptes de test ou les comptes de prestation.
Verrouiller les tentatives de connexion : stratégies et choix réalistes
Une fois l’authentification renforcée, on passe au verrouillage proprement dit. Le principe : quand trop d’échecs se produisent, on applique une punition progressive.
Approche par IP : simple, efficace, parfois injuste
Beaucoup de solutions bloquent après N tentatives depuis la même adresse IP. C’est efficace contre une majorité d’automates, surtout quand ils opèrent depuis une plage stable.
Mais il faut accepter une contrainte : vous pouvez bloquer un utilisateur légitime si son IP change souvent, si un NAT d’entreprise partage une adresse, ou si un fournisseur mobile redonne des IP dynamiques. Dans la pratique, je préfère les blocages temporaires plutôt que des exclusions longues, et je vérifie que les mécanismes de “déblocage” sont prévisibles.
Pour limiter les effets de bord, les solutions avancées combinent parfois l’IP, le username, et d’autres signaux. Ce n’est pas parfait, mais c’est souvent plus robuste que le “par IP seulement”.
Approche par nom d’utilisateur : utile quand l’attaquant énumère
Certains attaques commencent par déterminer des noms d’utilisateur, puis enchaînent des mots de passe. Un verrouillage qui tient compte du couple “username + IP” réduit l’efficacité de ces scripts.
Sur WordPress, attention toutefois : afficher trop d’informations sur l’existence du compte peut aider à l’énumération. De nombreux réglages de sécurité visent à rendre les messages plus neutres et à réduire le feedback à l’attaquant.
Approche par challenge : ralentir plutôt que bloquer
La stratégie de ralentissement consiste à imposer des délais progressifs après échec, au lieu de bannir directement. C’est très utile pour éviter les blocages injustes. L’inconvénient est que les bots peuvent continuer leur travail, mais à un coût plus élevé.
En production, j’aime bien une combinaison : petite friction immédiate, blocage temporaire seulement au-delà d’un certain seuil, et détection plus forte si d’autres signaux sont présents.
Déploiement pratique : plugin, pare-feu, reverse proxy, ce que j’ai vu marcher
Vous avez plusieurs chemins. Le plus souvent, vous choisissez selon votre architecture :
- WordPress en direct, avec un serveur web simple, WordPress derrière un reverse proxy (Nginx, Caddy, HAProxy, load balancer), WordPress derrière un WAF ou un service cloud, WordPress sur hébergement managé qui propose déjà des règles.
Plugins WordPress : rapides à mettre en place, mais à surveiller
Un plugin de sécurité peut ajouter de la limitation de tentatives, des règles de blocage, et parfois des pages de challenge. L’avantage, c’est la mise en œuvre rapide. Le risque, c’est l’interaction avec d’autres composants et la maintenance.
Sur des sites existants, j’ai déjà vu des “doublons” entre un plugin de sécurité et des règles au niveau serveur, ce qui crée des blocages trop agressifs. D’où l’importance d’observer les logs après chaque changement, même si le plugin est réputé.
Niveau serveur ou reverse proxy : plus stable, souvent moins intrusif
Quand vous contrôlez Nginx ou un reverse proxy, vous pouvez appliquer des règles sur l’URL de login et sur les erreurs. L’intérêt est de gérer la demande avant d’atteindre WordPress.
En pratique, je considère cette approche comme très “propre” : moins de charge applicative, et une logique claire côté infrastructure. Le revers, c’est que le détail des chemins et de la gestion des sessions dépend de votre configuration (et du fait que vous soyez derrière un load balancer).
WAF ou service cloud : excellent contre le bruit, à configurer soigneusement
Les WAF savent filtrer, rate limit, et challenge. Ils sont puissants contre les scans et la force brute.
Mais ils peuvent aussi bloquer des flux légitimes si vous êtes trop strict, surtout si votre équipe utilise des VPN, des proxies d’entreprise, ou si vous gérez des accès clients distants. Là encore, il faut tester avec un scénario réaliste, pas seulement avec votre propre navigateur.
Un réglage qui change tout : le plafond de tentatives et la durée de blocage
C’est le cœur du verrouillage. Les chiffres exacts dépendent du niveau d’attaque et du rythme normal de votre équipe.
- Si vos administrateurs se connectent rarement, une politique modérée suffit. Si vous avez un support qui se connecte souvent depuis des machines partagées, un blocage trop strict vous harassera rapidement.
Une règle que je trouve saine consiste à combiner un seuil pas trop bas avec une durée pas trop longue. L’objectif est d’empêcher la “rafale” automatisée sans punir les erreurs humaines.
Par exemple, un blocage trop court peut être contourné, un blocage trop long crée des tickets internes. Et comme les attaques tournent, vous ne pouvez pas supposer que l’attaquant “abandonne”. Il s’adapte, change d’IP, reprend ailleurs.
Le bon indicateur, c’est la friction que vous êtes prêt à absorber.
Exemple de politique de verrouillage (sans casser l’usage)
Sur un site d’entreprise standard, je vise un comportement où :
- les erreurs de l’utilisateur déclenchent une friction, les excès déclenchent une mise à l’écart temporaire, et la récupération se fait sans action manuelle compliquée.
Voici un schéma de décision simple que j’utilise pour cadrer les réglages (à adapter à vos logs et à votre organisation).
Une approche graduelle, en pratique
Limiter l’essai d’erreur : après quelques échecs rapprochés, ajouter un délai. Bloquer temporairement si le pattern continue, plutôt que bannir définitivement. Exclure les IP fiables si vous avez des plages d’entreprise stables (à condition de les documenter). Réduire l’énumération en limitant le feedback sur le login. Activer 2FA pour rendre les mots de passe volés moins utilisables.Je sais, ça ressemble à une règle générale, mais sur le terrain, ce sont ces cinq choix qui évitent la plupart des incidents.
Check-list rapide avant d’activer un verrouillage agressif
Avant de durcir fortement la limitation, je fais toujours un point. Cette étape ne prend que quelques minutes, mais elle évite des nuits à débloquer un accès.
- Vérifier que la connexion admin fonctionne depuis vos postes habituels, en environnement “réel” (VPN, réseau d’entreprise, mobile si pertinent). Contrôler la présence d’une 2FA ou d’une alternative d’authentification, et prévoir la récupération de compte. Examiner les logs sur wp-login.php pour estimer le volume actuel de tentatives et la dispersion des IP. Coordonner avec les règles existantes côté serveur ou WAF pour éviter les blocages en double. Prévoir un moyen de récupération (accès via canal admin du hébergeur, procédure de contournement, ou déblocage temporaire encadré).
Cette check-list m’a évité plusieurs cascades d’incidents, notamment quand un plugin mettait en place une logique, pendant qu’un autre faisait déjà du rate limiting au même endroit.
Les effets de bord les plus fréquents, et comment les éviter
Le verrouillage a un revers : il touche le trafic. Si votre trafic légitime ressemble au trafic malveillant, vous risquez de punir vos utilisateurs.
Utilisateurs derrière un NAT ou une entreprise
Si plusieurs personnes sortent via la même IP (NAT d’entreprise), un échec d’un seul utilisateur peut faire “tomber” tout le groupe. La solution n’est pas forcément de désactiver le verrouillage, mais de choisir une logique qui inclut une dimension supplémentaire, comme le couple identifiant et IP, ou une durée de blocage qui reste courte.
VPN et IP mobiles
Les IP mobiles changent. Les VPN changent aussi, et parfois avec une granularité qui rend les règles “par IP” trop dures. Dans ces cas, je privilégie les délais progressifs, et j’observe l’impact sur les connexions légitimes avant de monter le niveau de blocage.
Comptes de service et automatisations
Certaines organisations utilisent des comptes pour automatiser des actions dans l’admin, comme l’intégration via des outils, des scripts, ou des connexions API qui finissent par déclencher des flux d’authentification. Si votre verrouillage est basé sur wp-login.php uniquement, vous pouvez être tranquille côté API, mais ce n’est pas garanti si l’architecture passe par le même point d’auth.
Le point clé, c’est de vérifier comment vos outils se connectent. Là aussi, les logs https://gardewp.fr/securite-wordpress/ de WordPress et du serveur vous éclairent rapidement.
Réduire l’attrait de WordPress pour les robots
Verrouiller les tentatives est indispensable, mais vous pouvez aussi réduire l’intérêt des attaques en diminuant les signaux utiles.
Je pense à trois leviers, qui ne remplacent pas le verrouillage, mais le rendent plus efficace :
- Limiter les surfaces exposées : désactiver ce qui n’est pas utilisé, retirer les extensions orphelines, réduire les routes inutiles. Rendre les messages moins informatifs : WordPress par défaut reste assez neutre, mais certains thèmes ou plugins déforment l’affichage ou ajoutent du détail. Maintenir WordPress et les extensions à jour : un attaquant peut essayer de “forcer” ou simplement de profiter d’une faille. Le verrouillage ne protège pas contre tout le reste.
Ce sont des sujets classiques, mais l’efficacité globale vient de la combinaison. Un bon verrouillage sans hygiène applicative restera une défense partielle.
Concrètement, comment choisir un niveau de blocage compatible avec votre équipe
Je conseille de raisonner en “rythme humain”, pas seulement en “rythme bot”.
Posez-vous la question suivante : combien de tentatives d’échec avez-vous déjà vues dans la réalité sur votre back-office, sur une semaine normale ?
Si vous ne voyez quasiment rien, vous pouvez accepter une politique plus stricte. Si vous voyez déjà des échecs dus à des mots de passe oubliés, à des utilisateurs qui testent, ou à des changements de navigateur, vous devez garder une politique qui n’ajoute pas de frictions trop longues.
Le durcissement WordPress doit être piloté par des observations, pas par une recette universelle. Dans les attaques, la variabilité est énorme, et les comportements des utilisateurs aussi.
Garder le contrôle : surveiller et ajuster après mise en place
Un verrouillage n’est pas un réglage “une fois pour toutes”. Dès que vous l’activez, surveillez.
Regardez :
- l’évolution des tentatives sur wp-login.php, la proportion d’IP qui déclenchent des blocages, et les éventuels tickets internes ou rapports d’impossibilité de connexion.
Quand ça déraille, les indices sont visibles. Parfois ce sont des blocages massifs sur un même endpoint. Parfois ce sont des erreurs “inattendues” à des heures précises, liées à des scripts de maintenance.
L’ajustement fait partie du travail d’exploitation. Les meilleurs résultats viennent de petites retouches, pas de grands réglages initiaux.
Et si vous devez aller plus loin : une logique de confiance
Selon votre contexte, vous pouvez introduire une logique de confiance, par exemple en acceptant plus facilement des connexions depuis des plages connues (bureaux, bastion, bastion VPN).
Cela se fait souvent au niveau reverse proxy ou WAF, plutôt qu’au niveau WordPress, parce que c’est plus simple à raisonner.
Le piège, c’est de croire qu’une plage IP d’entreprise restera stable pendant des mois. En pratique, elle évolue, et les équipes changent. La meilleure approche consiste à documenter ces plages, et à prévoir une procédure de mise à jour.
Où mettre le curseur final : sécurité vs confort
Verrouiller les tentatives de connexion, c’est toujours un arbitrage.
Un verrouillage trop strict peut bloquer des utilisateurs légitimes, surtout en mobilité et en entreprise avec NAT. Un verrouillage trop permissif laisse les bots travailler et augmente la charge sur votre infrastructure, même si WordPress ne se “fait” pas pirater.
Mon conseil pratique, c’est de construire votre politique comme un système en couches :
- 2FA pour empêcher l’accès par mot de passe seul, limitation et ralentissement pour casser la force brute, blocage temporaire plutôt que banni définitive, règles cohérentes entre WordPress, reverse proxy et WAF, et une surveillance simple pour ajuster.
Ce n’est pas spectaculaire, mais c’est ce qui résiste dans le temps.
Un point de méthode : tester avant, puis simuler un incident
Le test “sur votre machine” ne suffit pas. Faites un test qui ressemble à votre réalité :
- connexion depuis un réseau externe, connexion via VPN si vous l’utilisez, connexion avec un navigateur “propre” après un nouvel essai de mot de passe.
Puis imaginez un incident. Par exemple, un administrateur est bloqué après plusieurs échecs, et son téléphone est en panne. Quelle est la procédure de récupération prévue ? Est-ce que l’accès de secours existe, est-ce que vous avez un canal de déblocage ?
Le durcissement WordPress, s’il n’a pas de plan B, devient une source de stress au lieu d’une protection.
Si vous me dites votre configuration (hébergement, reverse proxy ou non, présence d’un WAF, et si vous utilisez déjà un plugin de sécurité), je peux vous proposer une politique de verrouillage réaliste, avec des seuils et des durées cohérents avec votre niveau de trafic et le comportement de vos utilisateurs.