Attaque par force brute : s'en protéger

Comment elle se déroule

La documentation de WordPress la décrit comme la manière la plus simple d'entrer : on essaie des couples identifiant et mot de passe jusqu'à trouver le bon. Les robots partent de listes de mots de passe courants et de mots de passe issus de fuites d'autres sites. Ils essaient d'abord les identifiants évidents : admin, le nom du site, le prénom affiché sous les articles.

Deux portes sont visées en priorité sur WordPress :

• la page de connexion, wp-login.php ;
• le fichier xmlrpc.php, qui permet de tester des centaines de mots de passe en une seule requête par la méthode system.multicall.

Même ratée, l'attaque coûte : chaque essai fait travailler PHP et la base de données. Un site peut ralentir, voire tomber, sous une vague d'essais qui n'a aucune chance d'aboutir.

Les signes qu'elle vous vise

1. Le site ralentit par vagues sans hausse de vos visites réelles.
2. Les journaux d'accès montrent des centaines de requêtes vers wp-login.php ou xmlrpc.php, depuis des adresses différentes.
3. Une extension de sécurité vous envoie des alertes de connexions échouées ou de comptes bloqués.
4. Un compte inconnu apparaît parmi les administrateurs. Là, ce n'est plus une tentative : le site est compromis, voir Nettoyer un site WordPress piraté.

Les protections, par ordre d'efficacité

Un mot de passe long et unique

Un mot de passe de plusieurs mots, généré et gardé par un gestionnaire de mots de passe, résiste à des années d'essais. Ce qui tombe, ce sont les mots de passe courts, prévisibles ou déjà utilisés ailleurs. N'utilisez pas « admin » comme identifiant.

La double authentification

Avec elle, même le bon mot de passe ne suffit pas : il faut aussi le code de votre téléphone. C'est la mesure qui ferme la porte pour de bon. Voir Double authentification.

Le blocage des essais répétés

Après quelques échecs, l'adresse qui essaie est bloquée un temps. Mieux vaut que ce blocage se fasse en amont, au niveau du serveur ou d'un pare-feu placé devant le site, plutôt que dans une extension WordPress : la documentation de WordPress rappelle qu'une extension s'exécute dans PHP et consomme donc des ressources pendant l'attaque.

La fermeture de ce qui ne sert pas

Si vous n'utilisez pas xmlrpc.php (il sert surtout à certaines applications mobiles et à Jetpack), désactivez-le ou bloquez-le au niveau du serveur. Changer l'adresse de la page de connexion réduit le bruit dans les journaux, mais ne remplace aucune des mesures précédentes.

Ce qui ne marche pas

Bloquer les adresses une par une, à la main : les robots en changent à chaque essai. Compter sur la discrétion d'un petit site : les robots ne choisissent pas leurs cibles, ils balaient tout ce qui répond. Ajouter un captcha sans rien d'autre : il freine les robots les plus simples, pas les autres.

Sur un site hébergé chez nous

Les essais en série sur l'administration sont bannis automatiquement au niveau du serveur, et un filtrage en amont écarte des robots avant même qu'ils atteignent votre site. Le pare-feu applicatif complète le tout. Ces protections sont comprises dans toutes nos offres, sans réglage de votre part. Il vous reste deux gestes que personne ne peut faire à votre place : un mot de passe unique pour chaque compte, et la double authentification activée, déjà préinstallée sur votre WordPress.

Questions fréquentes