Sécuriser WordPress contre les attaques par force brute sur wp-login

La très grande majorité des sites WordPress connectés à Internet reçoivent, chaque jour, des tentatives de connexion automatisées sur leur page d'administration, sans qu'aucun humain ne soit derrière ces essais. Ces attaques par force brute (brute force) restent largement invisibles tant qu'elles n'aboutissent pas, mais elles consomment des ressources serveur, ralentissent le site, et finissent parfois par trouver la faille sur un site mal préparé. La bonne nouvelle : s'en protéger efficacement ne demande ni budget conséquent, ni compétences techniques poussées.

Comprendre l'attaque par force brute sur WordPress

Une attaque par force brute consiste à soumettre, de façon automatisée et répétée, des combinaisons d'identifiant et de mot de passe sur la page /wp-login.php, dans l'espoir de tomber sur la bonne. Les robots utilisés exploitent le plus souvent des listes d'identifiants courants (« admin », « administrateur », le nom de domaine du site) combinées à des mots de passe issus de fuites de données déjà connues.

Ce type d'attaque ne cible pas un site en particulier : des robots explorent Internet en continu à la recherche de toute installation WordPress accessible, et testent systématiquement wp-login.php sur chacune. Un site tout juste mis en ligne, même sans aucun contenu ni visibilité, peut ainsi subir ses premières tentatives dans les heures qui suivent sa publication.

3 réglages simples suffisent à bloquer l'immense majorité des tentatives automatisées : identifiant renommé, tentatives limitées, authentification à deux facteurs

Premiers réflexes : identifiant, tentatives limitées, mots de passe

Trois réglages de base, accessibles sans compétence technique avancée, neutralisent la plupart des attaques automatisées :

1. Ne jamais utiliser « admin » comme identifiant de connexion. Un identifiant personnalisé, distinct du nom affiché publiquement sur le site, oblige l'attaquant à deviner deux informations au lieu d'une seule.
2. Limiter le nombre de tentatives de connexion échouées avant blocage temporaire de l'adresse IP concernée, via une extension dédiée ou une règle au niveau du serveur. Une poignée d'essais autorisés avant blocage suffit à décourager un robot qui en teste normalement des milliers.
3. Exiger un mot de passe robuste et unique pour chaque compte administrateur, généré aléatoirement plutôt que mémorisé, et stocké dans un gestionnaire de mots de passe dédié.

L'authentification à deux facteurs, la protection la plus efficace

L'authentification à deux facteurs (2FA) ajoute une étape de vérification supplémentaire après la saisie du mot de passe, généralement un code temporaire généré par une application dédiée sur le téléphone de l'administrateur. Même si un attaquant parvient à deviner ou à récupérer le mot de passe exact, il ne peut pas se connecter sans ce second facteur.

Un mot de passe seul, aussi complexe soit-il, finit toujours par pouvoir être compromis. Un second facteur rend cette compromission inutile pour l'attaquant.

Cette protection reste la plus efficace contre les attaques par force brute classique, car elle neutralise l'attaque même en cas de succès sur le premier facteur, un principe à généraliser à l'ensemble des accès sensibles d'un site, au même titre que la gestion rigoureuse d'un certificat SSL renouvelé sans coupure pour sécuriser le transport des données de connexion elles-mêmes.

Restreindre l'accès à wp-login et wp-admin au niveau du serveur

Au-delà des réglages propres à WordPress, une protection supplémentaire peut être ajoutée directement au niveau du serveur web, avant même que WordPress ne soit sollicité :

Ces réglages relèvent généralement de la configuration de l'hébergeur ou du serveur, et méritent d'être vérifiés systématiquement lors d'un changement d'hébergeur, une étape où ce type de protection est parfois oublié en cours de migration.

Pare-feu applicatif et mises à jour : la protection de fond

Un pare-feu applicatif web (WAF), qu'il soit fourni par l'hébergeur ou installé sous forme d'extension, filtre le trafic suspect avant qu'il n'atteigne WordPress, et bloque automatiquement les schémas de comportement typiques d'une attaque par force brute (nombre anormal de requêtes, adresses IP déjà signalées comme malveillantes).

Cette protection ne dispense toutefois pas de la mesure la plus fondamentale : maintenir à jour le cœur de WordPress, les thèmes et les extensions. Une part importante des compromissions de sites WordPress n'exploite pas une attaque par force brute réussie, mais une faille connue et déjà corrigée dans une version plus récente, jamais installée sur le site concerné.

Comment repérer qu'une attaque est en cours

Plusieurs signes, souvent négligés, indiquent qu'un site subit une attaque par force brute active :

• Un ralentissement inhabituel du site, en particulier au niveau de la page de connexion, causé par le volume de requêtes automatisées.
• Des journaux de connexion (logs) montrant un grand nombre de tentatives échouées, souvent depuis des adresses IP variées et géographiquement dispersées.
• Des alertes de sécurité envoyées par une extension de protection ou par l'hébergeur, signalant un volume anormal de tentatives de connexion.

En résumé, sécuriser WordPress contre les attaques par force brute repose sur une logique de couches successives : un identifiant non devinable, un nombre de tentatives limité, une authentification à deux facteurs, et si possible une restriction d'accès au niveau du serveur. Aucune de ces mesures n'est complexe à mettre en place isolément ; c'est leur combinaison qui rend un site pratiquement invulnérable à ce type d'attaque automatisée.