Une attaque par force brute est exactement ce que son nom indique : un script automatisé essaie des combinaisons d'identifiants et de mots de passe sur votre page de connexion, encore et encore, jusqu'à ce que l'une fonctionne. C'est sans éclat, extrêmement courant et presque entièrement automatisé. La plupart des sites WordPress subissent des tentatives dans les jours qui suivent leur mise en ligne, aussi discrets soient-ils.
Pourquoi cela marche
Elle ne réussit que lorsque trois conditions sont réunies : des mots de passe faibles ou réutilisés, des identifiants prévisibles (admin étant le classique) et aucune limite au nombre de tentatives d'un script. Retirez l'une d'elles et une attaque par force brute cesse d'être une vraie menace, quel que soit le nombre d'essais qu'un robot lance.
Une variante appelée credential stuffing ne devine rien du tout. Elle essaie de vraies paires e-mail et mot de passe issues de fuites d'autres services, en pariant que vous en avez réutilisé une. C'est pourquoi un mot de passe robuste mais réutilisé reste un risque.
Ce qui l'arrête vraiment
- Un mot de passe unique et robuste sur chaque compte. Cela suffit à déjouer la grande majorité des tentatives. Un gestionnaire de mots de passe rend la chose indolore.
- Pas d'identifiant « admin ». C'est le premier essai de toute exécution automatisée. Créez un administrateur sous un autre nom, transférez-lui les contenus et supprimez l'ancien compte.
- Un nombre limité de tentatives de connexion. Bloquer une adresse après quelques échecs transforme un jeu de devinettes illimité en impasse.
- L'authentification à deux facteurs. Même un mot de passe deviné ou divulgué est inutile sans le second facteur.
- La limitation de débit au niveau du serveur ou du pare-feu. Elle bloque le flot de requêtes avant qu'il n'atteigne WordPress, ce qui protège aussi les ressources du serveur. Un outil comme fail2ban peut bannir une adresse qui échoue sans cesse ; le guide du pare-feu explique où cela s'intègre.
N'oubliez pas XML-RPC
Le formulaire de connexion n'est pas la seule porte. WordPress accepte aussi les connexions via xmlrpc.php, et cette interface peut essayer de nombreux mots de passe en une seule requête, ce qui contourne les limites simples par requête. Si vous n'utilisez pas l'application mobile, les fonctions de Jetpack ou d'autres outils qui s'appuient sur XML-RPC, bloquez-le ou désactivez-le. Beaucoup de sites n'en ont jamais besoin.
Les identifiants sont plus faciles à trouver qu'on ne le croit
WordPress peut révéler des noms d'utilisateur à quiconque les demande. Une requête comme /?author=1 redirige vers une page d'auteur qui contient l'identifiant de connexion, et l'API REST liste les utilisateurs sur /wp-json/wp/v2/users. Les attaquants utilisent les deux pour dresser une liste avant de commencer à deviner. Donnez à chaque compte un nom affiché différent de son identifiant, et envisagez de restreindre la liste des utilisateurs si aucun thème ni plugin n'a besoin qu'elle soit publique.
Ce qui n'aide pas vraiment
Renommer wp-login.php ou cacher la page de connexion n'arrête que les robots les plus rudimentaires, qui ne vérifient que l'adresse par défaut. C'est un léger ralentisseur plutôt qu'une protection, et d'autres portes comme XML-RPC restent. C'est acceptable comme couche supplémentaire, pas comme plan.
Comment savoir si vous êtes visé
Regardez dans le journal d'accès de votre serveur : de nombreuses requêtes POST vers wp-login.php venant d'adresses IP variées. En ligne de commande, ceci liste les sources les plus actives :
grep "POST /wp-login.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
Un pic bref est du bruit de fond normal sur internet. Un schéma soutenu et à fort volume mérite une réaction. Regardez aussi l'autre bout : une connexion réussie depuis une adresse inconnue, ou un administrateur que vous n'avez pas créé, signifie qu'un essai a réussi. Dans ce cas, suivez la vérification de piratage en cinq minutes.
L'analyse hebdomadaire de SiftWP recherche les configurations qui facilitent la réussite des attaques par force brute, notamment les comptes administrateurs sans identifiants robustes et uniques, dans son passage régulier sur le site. Elle s'exécute via SSH sans plugin, donc elle fonctionne même si vous avez verrouillé la page de connexion. Les limites de connexion et l'authentification à deux facteurs relèvent toujours de votre configuration WordPress ou de votre hébergeur.