Attaques par force brute sur la page de connexion : les bloquer efficacement

Q: Combien de tentatives de connexion faut-il autoriser avant de bloquer une IP ?

Le réglage recommandé est de 3 tentatives par tranche de 15 minutes. Au-delà, l’IP est verrouillée temporairement (15 minutes au premier verrouillage, puis 24 heures en cas de récidive). Ce seuil laisse une marge d’erreur suffisante pour un utilisateur légitime qui se trompe de mot de passe, tout en bloquant efficacement les bots.

Q: Comment savoir si mon site est actuellement sous attaque par force brute ?

Trois indicateurs principaux : une charge serveur anormalement élevée sans hausse du trafic légitime, des centaines de requêtes POST vers /wp-login.php dans les logs d’accès, et des notifications de verrouillage de compte envoyées par un plugin de sécurité. La commande grep "POST /wp-login.php" access.log | wc -l donne un comptage rapide des tentatives.

Q: La double authentification empêche-t-elle toutes les attaques par force brute ?

La double authentification empêche l’aboutissement d’une attaque par force brute, pas l’attaque elle-même. Les bots continueront d’envoyer des requêtes et de consommer des ressources serveur. C’est pourquoi il faut combiner le 2FA avec une limitation des tentatives et, idéalement, un blocage au niveau serveur pour stopper les requêtes avant qu’elles ne sollicitent PHP.

Protéger la page de connexion WordPress contre les tentatives d'intrusion automatisées

À la une

Les attaques par force brute représentent plus de 80 % des tentatives d’intrusion sur les sites WordPress, selon les données publiées par Wordfence en 2025. Elles ciblent presque toujours le fichier wp-login.php, en testant des milliers de combinaisons identifiant/mot de passe jusqu’à trouver la bonne. Bloquer ces attaques ne demande ni compétences avancées ni budget particulier : cinq mesures superposées suffisent à réduire le risque à un niveau négligeable.

Dans cet article

Une attaque par force brute génère en moyenne 500 à 10 000 requêtes par heure sur wp-login.php
Limiter les tentatives de connexion à 3 essais par tranche de 15 minutes stoppe la majorité des bots
Déplacer ou protéger l’URL de connexion réduit les requêtes parasites de plus de 95 %
La double authentification reste la mesure la plus efficace même si l’identifiant et le mot de passe sont compromis
Un blocage au niveau serveur (Fail2Ban, règle .htaccess) consomme moins de ressources qu’un plugin PHP
Les en-têtes de sécurité et le pare-feu applicatif (WAF) ajoutent une couche complémentaire contre les variantes automatisées

Sommaire

Comment fonctionne une attaque par force brute sur wp-login.php
Trois signes qui révèlent une attaque en cours sur votre site
Limiter les tentatives de connexion : 3 essais, puis verrouillage
Déplacer l’URL de connexion pour supprimer 95 % des requêtes
Blocage au niveau serveur : .htaccess, Fail2Ban et pare-feu
La double authentification : dernière barrière même en cas de fuite
Comparatif des principaux plugins anti brute force en 2026
Checklist complète : sept couches de protection empilées

Comment fonctionne une attaque par force brute sur wp-login.php

Une attaque par force brute consiste à envoyer des requêtes POST répétées au fichier wp-login.php en testant systématiquement des combinaisons d’identifiants et de mots de passe. Les bots utilisent des dictionnaires de mots de passe courants (les fameuses “wordlists”) ou des générateurs qui itèrent toutes les combinaisons possibles. Selon le WordPress Codex, cette méthode reste la plus simple et la plus répandue pour compromettre un site.

Le processus suit toujours le même schéma. Le bot identifie d’abord la page de connexion, généralement accessible à l’adresse /wp-login.php ou /wp-admin/. Il envoie ensuite des requêtes à une cadence pouvant atteindre plusieurs centaines par minute. Chaque requête teste un couple identifiant/mot de passe différent. WordPress répond par un code HTTP 200 avec un message d’erreur en cas d’échec, ou par une redirection 302 vers le tableau de bord en cas de succès.

Le problème est double. D’une part, chaque tentative de connexion déclenche une requête PHP complète avec interrogation de la base de données, ce qui consomme des ressources serveur. Sur un hébergement mutualisé, quelques milliers de tentatives suffisent à ralentir considérablement le site. D’autre part, si le mot de passe est faible (moins de 8 caractères, mot du dictionnaire, combinaison prévisible), le bot finit par le trouver. Un mot de passe de six caractères en minuscules se casse en quelques minutes avec un script moderne.

Les variantes incluent le credential stuffing, qui réutilise des identifiants volés sur d’autres services, et le reverse brute force, qui teste un mot de passe courant (“admin123”, “password”) contre une liste d’identifiants. Ces deux techniques contournent les protections basées uniquement sur le nombre de tentatives par compte.

Trois signes qui révèlent une attaque en cours sur votre site

Le premier indicateur est une augmentation brutale de la charge serveur sans hausse correspondante du trafic légitime. Les journaux d’accès (access logs) montrent alors des centaines de requêtes POST vers /wp-login.php en provenance d’adresses IP variées. Sur un hébergement mutualisé, l’hébergeur peut même suspendre temporairement le compte pour usage excessif de ressources.

Le deuxième signe est l’apparition de notifications d’échec de connexion dans les journaux WordPress ou dans un plugin de sécurité. Si le site enregistre 200 tentatives échouées en une heure alors qu’une seule personne administre le site, l’attaque est évidente. Certains hébergeurs fournissent un accès aux logs bruts via cPanel ou Plesk ; la commande grep "POST /wp-login.php" access.log | wc -l donne un comptage rapide.

Le troisième signe est un verrouillage de compte inattendu. Si un plugin de limitation des tentatives est déjà actif, l’administrateur légitime peut se retrouver bloqué parce que son adresse IP a été associée à des tentatives échouées, ou parce que le bot utilise la même plage IP. Ce symptôme paradoxal confirme que le mécanisme de défense fonctionne, mais qu’il nécessite un réglage plus fin (liste blanche de l’IP d’administration, par exemple).

Voir aussi Mises à jour automatiques WordPress : lesquelles activer sans risque

Limiter les tentatives de connexion : 3 essais, puis verrouillage

La mesure la plus immédiate consiste à limiter le nombre de tentatives de connexion autorisées avant de verrouiller temporairement l’accès. Le réglage recommandé par la plupart des experts en sécurité WordPress est de 3 tentatives par tranche de 15 minutes, avec un verrouillage progressif : 15 minutes après 3 échecs, puis 24 heures après 3 verrouillages consécutifs.

Plusieurs extensions permettent de mettre en place cette limitation sans toucher au code. Limit Login Attempts Reloaded, avec plus de 2 millions d’installations actives, reste la référence. Elle enregistre chaque tentative, verrouille l’IP après le seuil défini et envoie un e-mail de notification à l’administrateur. La version gratuite suffit pour la majorité des sites.

Pour que cette mesure reste efficace, il faut configurer correctement la détection de l’IP. Derrière un proxy inverse ou un CDN comme Cloudflare, l’IP réelle du visiteur se trouve dans l’en-tête X-Forwarded-For et non dans REMOTE_ADDR. Un mauvais réglage entraîne le verrouillage de l’adresse du proxy (donc de tous les visiteurs) au lieu de celle de l’attaquant. La documentation de chaque plugin précise comment gérer ce cas, et l’article dédié aux CDN explique le fonctionnement de ces en-têtes.

Cette protection présente une limite : les attaques distribuées utilisent des milliers d’adresses IP différentes (botnets), chacune n’effectuant que deux ou trois tentatives. Le verrouillage par IP ne se déclenche alors jamais. C’est pourquoi il faut combiner cette mesure avec les suivantes.

Déplacer l’URL de connexion pour supprimer 95 % des requêtes

Changer l’adresse de la page de connexion de /wp-login.php vers une URL personnalisée (par exemple /acces-admin-xyz) relève de la sécurité par obscurité. Ce n’est pas une protection absolue, mais elle élimine la quasi-totalité des bots automatisés qui ciblent uniquement les chemins par défaut. Les données de plusieurs WAF montrent une réduction de 95 à 99 % des requêtes malveillantes après ce changement.

L’extension WPS Hide Login, légère et gratuite, effectue ce changement en une ligne de configuration. Elle ne déplace pas physiquement le fichier : elle intercepte les requêtes et redirige. L’ancienne URL /wp-login.php renvoie alors une erreur 404. Il est impératif de noter la nouvelle URL dans un gestionnaire de mots de passe ; l’oublier revient à se verrouiller soi-même hors du site.

Cette mesure se combine parfaitement avec la limitation des tentatives. Un bot qui ne trouve pas la page de connexion ne peut pas lancer d’attaque. Et si un attaquant découvre malgré tout l’URL personnalisée, la limitation des tentatives prend le relais. Les deux couches se complètent sans se gêner.

Attention : certains plugins ou thèmes redirigent automatiquement vers /wp-login.php dans leur code. Après avoir changé l’URL, il faut tester la déconnexion, la réinitialisation de mot de passe et l’inscription (si elle est activée) pour vérifier que tout fonctionne. Une sauvegarde préalable est recommandée avant toute modification de ce type.

Blocage au niveau serveur : .htaccess, Fail2Ban et pare-feu

Bloquer les tentatives avant qu’elles n’atteignent PHP est la méthode la plus économe en ressources. Sur un serveur Apache, une règle dans le fichier .htaccess peut restreindre l’accès à wp-login.php à une ou plusieurs adresses IP précises :

<Files wp-login.php>
  Order Deny,Allow
  Deny from all
  Allow from 203.0.113.42
</Files>

Cette règle refuse toute connexion sauf depuis l’IP 203.0.113.42. Elle est idéale pour les sites administrés depuis un lieu fixe (bureau, domicile avec IP fixe). Pour les IP dynamiques, une protection par mot de passe HTTP (Basic Auth) ajoute une couche supplémentaire devant le formulaire WordPress :

<Files wp-login.php>
  AuthType Basic
  AuthName "Acces restreint"
  AuthUserFile /chemin/vers/.htpasswd
  Require valid-user
</Files>

Sur un serveur Nginx, la directive équivalente utilise auth_basic dans un bloc location. Le fichier .htpasswd se génère avec la commande htpasswd -c /chemin/.htpasswd utilisateur.

Pour les serveurs dédiés ou VPS, Fail2Ban surveille les journaux d’accès en temps réel et bannit automatiquement les IP qui dépassent un seuil de tentatives. La configuration standard pour WordPress détecte les requêtes POST répétées vers wp-login.php et ajoute une règle iptables bloquant l’IP pendant une durée configurable (généralement 10 minutes à 24 heures). Cette méthode est documentée sur la documentation officielle de Fail2Ban. Sur un hébergement mutualisé, Fail2Ban n’est pas accessible ; les plugins PHP restent alors la seule option.

Les pare-feu applicatifs (WAF) comme celui de Cloudflare ou Sucuri ajoutent une couche réseau en amont. Ils identifient les bots connus, bloquent les plages IP suspectes et appliquent des challenges JavaScript ou CAPTCHA avant d’autoriser l’accès à la page de connexion. La version gratuite de Cloudflare inclut déjà des règles de protection contre les attaques par force brute, configurables via le tableau de bord sous “Security > WAF”.

La double authentification : dernière barrière même en cas de fuite

Même si un attaquant découvre le bon identifiant et le bon mot de passe, la double authentification (2FA) l’empêche de se connecter sans le code temporaire généré par une application sur le téléphone de l’administrateur. Cette mesure transforme un mot de passe compromis en information inutile. L’article dédié à la double authentification détaille la mise en place complète.

Les applications TOTP (Time-based One-Time Password) comme Google Authenticator, Authy ou FreeOTP génèrent un code à 6 chiffres renouvelé toutes les 30 secondes. L’algorithme est standardisé par la RFC 6238 de l’IETF, ce qui garantit l’interopérabilité entre les applications et les services. Côté WordPress, l’extension WP 2FA ou la fonctionnalité intégrée de Wordfence permettent d’activer le 2FA en quelques minutes.

Il est essentiel de générer et stocker des codes de récupération lors de l’activation. Si le téléphone est perdu ou réinitialisé, ces codes permettent de retrouver l’accès au compte. Sans eux, la seule solution est de désactiver le plugin via FTP ou WP-CLI, ce qui suppose un accès au serveur. Cette procédure est décrite dans le guide sur la marche à suivre en cas de site compromis.

Pour les sites multi-utilisateurs, la double authentification doit être obligatoire pour tous les comptes ayant un rôle éditeur ou supérieur. Un seul compte administrateur sans 2FA suffit à compromettre l’ensemble du site. Certains plugins permettent de forcer l’activation du 2FA lors de la prochaine connexion de chaque utilisateur concerné.

Comparatif des principaux plugins anti brute force en 2026

Le choix d’un plugin dépend du niveau de protection souhaité, de la compatibilité avec l’environnement d’hébergement et du budget. Le tableau suivant compare les solutions les plus utilisées sur le critère de la protection contre les attaques par force brute spécifiquement.

Plugin	Installations actives	Limitation tentatives	2FA intégré	WAF intégré	Prix (version pro)
Limit Login Attempts Reloaded	2 000 000+	Oui	Non	Non	Gratuit / 35 €/an
Wordfence Security	4 000 000+	Oui	Oui	Oui	Gratuit / 119 $/an
WP Cerber Security	200 000+	Oui	Oui	Oui	Gratuit / 99 $/an
iThemes Security (Solid Security)	900 000+	Oui	Oui	Partiel	Gratuit / 99 $/an
Login Armor	50 000+	Oui	Oui	Non	Gratuit / 49 €/an
WPS Hide Login	1 000 000+	Non (URL uniquement)	Non	Non	Gratuit

Pour un site vitrine administré par une seule personne, la combinaison Limit Login Attempts Reloaded + WPS Hide Login + un plugin 2FA offre une protection solide sans surcharge. Pour un site e-commerce ou multi-utilisateurs, une suite complète comme Wordfence ou WP Cerber centralise toutes les fonctions dans une seule interface, avec l’avantage d’un journal de sécurité unifié et de règles de pare-feu mises à jour automatiquement.

Quel que soit le plugin choisi, il faut vérifier sa compatibilité avec la version de PHP en cours et s’assurer qu’il reçoit des mises à jour régulières. Un plugin de sécurité abandonné par son développeur devient lui-même une faille.

Checklist complète : sept couches de protection empilées

La sécurité efficace repose sur la défense en profondeur : chaque couche compense les faiblesses de la précédente. Voici les sept mesures à appliquer dans l’ordre, de la plus simple à la plus avancée :

Mot de passe fort et unique : au minimum 16 caractères, généré par un gestionnaire de mots de passe. Aucun mot du dictionnaire, aucune réutilisation. Cette seule mesure rend une attaque par dictionnaire impraticable.
Identifiant non devinable : supprimer le compte “admin” par défaut, utiliser un pseudonyme différent du nom d’affichage public. WordPress affiche par défaut le login dans l’URL des archives auteur (/?author=1) ; un plugin comme “Edit Author Slug” masque cette information.
Limitation des tentatives de connexion : 3 essais par IP toutes les 15 minutes, verrouillage progressif. Mesure décrite dans la section précédente.
Changement de l’URL de connexion : supprime les requêtes automatisées des bots qui ciblent le chemin par défaut.
Double authentification (2FA) : rend le mot de passe insuffisant à lui seul. Obligatoire pour tous les comptes à privilèges.
Protection au niveau serveur : Basic Auth devant wp-login.php, Fail2Ban sur VPS/dédié, ou WAF cloud (Cloudflare, Sucuri).
Surveillance et journalisation : activer les notifications par e-mail pour chaque verrouillage, consulter régulièrement les journaux. Un nettoyage périodique de la base évite que les tables de logs ne grossissent indéfiniment.

Ces sept couches fonctionnent ensemble. Un attaquant devrait simultanément trouver l’URL masquée, ne pas être bloqué par la limitation de tentatives, deviner un mot de passe de 16 caractères et posséder le téléphone de l’administrateur pour obtenir le code 2FA. La probabilité combinée est statistiquement négligeable.

Pour maintenir cette protection dans le temps, il est recommandé de versionner les fichiers de configuration avec Git et de tester la restauration d’une sauvegarde complète au moins une fois par trimestre.

À retenir

Configurez la limitation à 3 tentatives par 15 minutes avec verrouillage progressif dès aujourd’hui
Changez l’URL de wp-login.php vers une adresse personnalisée pour éliminer 95 % des bots
Activez la double authentification TOTP sur tous les comptes éditeur et administrateur
Ajoutez une protection .htaccess ou Fail2Ban pour bloquer les requêtes avant qu’elles n’atteignent PHP
Vérifiez que vos plugins de sécurité sont à jour et compatibles avec votre version de PHP

Questions fréquentes

Combien de tentatives de connexion faut-il autoriser avant de bloquer une IP ?

Le réglage recommandé est de 3 tentatives par tranche de 15 minutes. Au-delà, l’IP est verrouillée temporairement (15 minutes au premier verrouillage, puis 24 heures en cas de récidive). Ce seuil laisse une marge d’erreur suffisante pour un utilisateur légitime qui se trompe de mot de passe, tout en bloquant efficacement les bots.

Changer l’URL de wp-login.php est-il suffisant pour stopper les attaques ?

Non. Cette mesure relève de la sécurité par obscurité : elle élimine les bots automatisés qui ciblent le chemin par défaut, mais un attaquant déterminé peut retrouver la nouvelle URL. Il faut combiner cette mesure avec la limitation des tentatives, la double authentification et un mot de passe fort pour obtenir une protection réelle.

Un plugin de sécurité ralentit-il le site ?

Un plugin léger comme Limit Login Attempts Reloaded a un impact négligeable sur les performances. Les suites complètes (Wordfence, WP Cerber) consomment davantage de ressources, notamment lors des analyses de fichiers. Sur un hébergement mutualisé, il est préférable de désactiver les scans automatiques aux heures de pointe et de privilégier un WAF externe comme Cloudflare.

Comment savoir si mon site est actuellement sous attaque par force brute ?

Trois indicateurs principaux : une charge serveur anormalement élevée sans hausse du trafic légitime, des centaines de requêtes POST vers /wp-login.php dans les logs d’accès, et des notifications de verrouillage de compte envoyées par un plugin de sécurité. La commande grep "POST /wp-login.php" access.log | wc -l donne un comptage rapide des tentatives.

Fail2Ban fonctionne-t-il sur un hébergement mutualisé ?

Non. Fail2Ban nécessite un accès root au serveur et la possibilité de modifier les règles iptables. Il n’est disponible que sur les VPS et serveurs dédiés. Sur un hébergement mutualisé, les plugins WordPress (Limit Login Attempts Reloaded, Wordfence) ou un WAF externe (Cloudflare) assurent une protection équivalente au niveau applicatif.

La double authentification empêche-t-elle toutes les attaques par force brute ?

La double authentification empêche l’aboutissement d’une attaque par force brute, pas l’attaque elle-même. Les bots continueront d’envoyer des requêtes et de consommer des ressources serveur. C’est pourquoi il faut combiner le 2FA avec une limitation des tentatives et, idéalement, un blocage au niveau serveur pour stopper les requêtes avant qu’elles ne sollicitent PHP.

Damien Roux

Damien Roux est spécialiste de l'hébergement web. Fondateur de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress.