Sur un site WordPress laissé dans sa configuration par défaut, la page de connexion est probablement la ressource la plus sollicitée du serveur, non pas par de vrais visiteurs, mais par des robots qui testent en continu des combinaisons d'identifiants. Cette activité, appelée attaque par force brute, exploite le fait que l'URL de connexion est identique sur des millions d'installations WordPress dans le monde. La bonne nouvelle est qu'une poignée de mesures simples suffit à écarter la grande majorité de ces tentatives, sans nécessiter de compétences avancées.
Pourquoi cette menace touche autant WordPress
WordPress fait fonctionner une part très importante des sites web dans le monde, ce qui en fait une cible privilégiée pour des scripts automatisés qui ne visent pas un site en particulier, mais balaient l'ensemble d'internet à la recherche d'installations mal protégées. Une part significative de ces tentatives de connexion utilise des mots de passe déjà compromis lors de fuites de données ailleurs sur le web, ce qui rend la réutilisation d'un mot de passe entre plusieurs services particulièrement risquée pour un compte administrateur.
Changer le nom d'utilisateur admin
Si votre compte administrateur principal s'appelle encore admin, la moitié du travail d'un attaquant est déjà faite : il ne lui reste plus qu'à deviner le mot de passe. WordPress ne permet pas de renommer un identifiant existant, mais il est simple de créer un nouvel utilisateur avec un nom distinct et les droits d'administrateur, de transférer les contenus existants vers ce nouveau compte, puis de supprimer l'ancien compte admin.
Limiter le nombre de tentatives de connexion
Sans restriction, un robot peut tester plusieurs milliers de combinaisons par minute. Une extension de limitation des tentatives, comme Limit Login Attempts Reloaded ou les fonctionnalités équivalentes intégrées à des suites de sécurité plus larges, bloque temporairement une adresse IP après un nombre défini d'échecs, généralement cinq tentatives suivies d'un blocage de quelques minutes à quelques heures. Cette seule mesure suffit à rendre une attaque automatisée beaucoup trop lente pour être rentable.
Ajouter une double authentification
WordPress ne propose pas nativement d'authentification à deux facteurs dans son cœur logiciel, cette fonctionnalité doit être ajoutée par une extension dédiée. Une fois activée, elle demande, en plus du mot de passe, un code temporaire généré par une application sur smartphone, ce qui rend un mot de passe volé inutilisable seul pour un attaquant. Cette protection devrait être imposée à tous les comptes disposant de droits d'administrateur ou d'édition, pas seulement au compte principal.
Changer l'URL de connexion
Les robots ciblent systématiquement les adresses par défaut, wp-login.php et wp-admin. Une extension comme WPS Hide Login permet de remplacer cette adresse par une URL personnalisée, connue de vous seul. Cette mesure ne remplace pas les protections précédentes, mais réduit considérablement le volume de tentatives automatisées qui atteignent réellement votre serveur, puisque la majorité des robots n'ira jamais chercher plus loin qu'une adresse par défaut absente.
Désactiver XML-RPC si vous ne l'utilisez pas
Ce fichier, présent par défaut sur WordPress, permet des connexions à distance utilisées par certaines applications mobiles ou outils de publication externe. Il constitue aussi un vecteur d'attaque supplémentaire, notamment pour des tentatives de connexion groupées qui contournent parfois les limitations classiques. Si aucun outil de votre PME n'en dépend, le désactiver au niveau du serveur ou via une extension ferme cette porte sans aucune perte fonctionnelle.
S'appuyer sur son hébergeur
De nombreux hébergeurs gérés proposent déjà un pare feu applicatif et un filtrage des tentatives suspectes au niveau du réseau, avant même que la requête n'atteigne WordPress. Vérifier ce que propose concrètement votre hébergement actuel permet parfois de constater qu'une partie de la protection est déjà en place, et que l'effort à fournir côté site se limite aux mesures complémentaires décrites ici.
Points à vérifier avant publication : confirmer que les extensions citées (Limit Login Attempts Reloaded, WPS Hide Login) sont toujours maintenues et disponibles sur le répertoire officiel WordPress au moment de la publication, et vérifier que l'absence d'authentification à deux facteurs native dans le cœur de WordPress reste d'actualité à cette date.