Brute force sur wp-login : quand c'est la cause, quand ça ne l'est pas
Des milliers de 404 ou de 200 sur `wp-login.php` sont du bruit quotidien. Une connexion réussie à 4 h du matin avec un compte inconnu, elle, est une cause. Distinguer les deux évite de « durcir » pendant que le shell est déjà là.
Des milliers de 404 sur wp-login sont du bruit quotidien. Une connexion réussie à 4 h du matin avec un compte inconnu, elle, est une cause.
Le bruit n'est pas l'incident
Tout WordPress visible reçoit des tentatives. iThemes et Wordfence les affichent en rouge. Ce n'est pas une raison de restaurer une sauvegarde. C'est une raison d'avoir un mot de passe long et, plus tard, 2FA.
L'incident, c'est : un user créé, un rôle changé, un fichier daté, un login success dans les logs. Par où commencer.
iThemes et Wordfence colorient en rouge le bruit quotidien. Ce n'est pas une raison de restaurer une sauvegarde. L'incident, c'est un login success (302 vers wp-admin, cookie), un user daté, un e-mail « nouvel utilisateur ». Sans ça, durcissez plus tard. Avec ça, changez les secrets dans l'ordre (panel d'abord) et chassez comme pour n'importe quelle entrée : une fois dans l'admin, on dépose un mu-plugin. xmlrpc multicall à côté : vos stats wp-login peuvent être calmes.
Un rapport Wordfence « 12 000 attaques aujourd'hui » sans succès n'est pas un incident. C'est Internet. Traitez-le après, avec 2FA. Le transformer en urgence vous fait installer trois plugins de lockout pendant qu'un mu-plugin tourne déjà — si l'entrée a été un RCE, pas un mot de passe.
Ce qui prouve une réussite
access.log : POST `wp-login.php` suivi d'un 302 vers `wp-admin` et d'un cookie. Table users : compte daté. E-mail WordPress « nouvel utilisateur ». Session inconnue.
Sans ça, vous avez du bruit. Avec ça, vous avez une porte « mot de passe » — et probablement d'autres fichiers, parce qu'une fois dedans, on dépose.
Si les logs Apache/Nginx sont déjà rotatés, la table `wp_users` et les e-mails « nouvel utilisateur » restent. Un compte `admin2` du mardi 4 h 12 suffit à classer « réussite ». Changez le panel avant le mot de passe WP : l'inverse laisse réécrire `wp-config`.
Sans 302 vers wp-admin, sans user daté, sans e-mail « nouvel utilisateur », vous avez du bruit. Avec, vous avez une porte mot de passe — et probablement des fichiers, parce qu'une fois dedans on dépose.
Mots de passe, users, application passwords
`admin` / `123456` : encore. Un e-mail de l'agence réutilisé partout. Un stagiaire. Révoquez les application passwords. Régénérez les clés AUTH. Panel d'hébergement d'abord — un attaquant avec le FTP n'a pas besoin de wp-login.
Moins d'administrateurs. Rôles éditeur pour le quotidien.
xmlrpc à côté
La brute force passe par xmlrpc multicall. Vos stats « wp-login » sont calmes, le user existe quand même. XML-RPC.
Dans Wordfence, filtrez les événements « successful » xmlrpc, pas le compteur d'échecs. Un seul succès vaut plus que dix mille 404. Désactivez xmlrpc après le clean si l'app officielle ne s'en sert pas.
Limiter sans s'enfermer
Après le clean : 5–10 essais, ban temporaire, 2FA. Pendant : un lockout de votre IP de bureau bloque le constat. Whitelist ou plugin off. iThemes.
Masquer wp-login n'arrête pas xmlrpc ni `wp-json`. Priorité basse.
Après une réussite : tout le reste
Comme n'importe quelle entrée : mu-plugins, uploads PHP, thème, File Manager posé par l'admin. Un login success n'est pas « juste changer le mot de passe ». Backdoor.
Cherchez ce qu'un admin pose en vingt minutes : plugin File Manager, mu-plugin, user supplémentaire, option `siteurl`. La brute force n'est que l'entrée. Le reste est un incident normal. Backdoor PHP.
Après une réussite, le changement de mot de passe WP sans le panel est du théâtre. L'attaquant réécrit wp-config ou recrée l'admin. Ordre des secrets, toujours. wp-config.
Captcha et 2FA, le bon moment
Après. Un captcha le soir J+0 sur un site encore shellé : théâtre. 2FA ensuite empêche la prochaine brute force, pas le PHP déjà là.
Ce que les logs hébergeur ajoutent
FTP réussi à la même heure : l'entrée n'était pas wp-login. cPanel / Plesk users. Ne vous fixez pas sur le login WP.
2FA et captcha après le clean, pas le soir J+0 sur un site encore shellé. Logs FTP à la même heure : l'entrée n'était pas wp-login. Guide WordPress, créer un espace.
Compte client Woo, Fail2ban, et l'IP « chez moi »
Un reset massif des mots de passe clients Woo n'est pas un réflexe de bruit admin. Seulement si le constat dit que `wp_users` clients a été lu. Fail2ban sur un VPS coupe le bruit réseau, pas un RCE plugin. Utile en plus, après.
Des tentatives depuis « votre » IP : PC infecté, VPN d'agence, ou attaquant déjà sur le réseau. Ne whitelist pas tout le bureau. Le login `/my-account` Woo se rate-limite aussi ; le skimmer reste un autre dossier. WooCommerce.
Renommez `admin` après le clean (compte nominatif, puis retirez). Pendant, changez le mot de passe et chassez. Créer un espace.
Les deux heures après un login success
Panel, FTP, WP, MySQL, SMTP — dans cet ordre. Users, application passwords, clés AUTH. Puis ce qu'un admin pose : File Manager, mu-plugin, siteurl. Logs FTP à la même heure. 2FA demain, pas comme substitut ce soir. xmlrpc : succès « successful » dans Wordfence.
Le bruit de demain matin reviendra : normal. Vous n'avez plus à le colorier en rouge. Par où commencer. Créer un espace.