web-dev-qa-db-fra.com

Existe-t-il des moyens de se connecter en contournant wp-login.php?

J'ai une WP installation qui a été martelée ces derniers jours par des tentatives de connexion par force brute.

Le plug-in Limiter les tentatives de connexion est installé sur le site. Et quand j'ai commencé à recevoir des notifications fréquentes sur les verrouillages, j'ai décidé, étant donné que j'accède uniquement au fichier wp-login.php et au wp-admin d'un endroit, de bloquer toutes les adresses IP sauf le mien via .htaccess. J'ai testé le bloc .htaccess en retirant mon IP de la liste des exceptions, et il bloque en effet l'accès au fichier wp-login.php. Cela semble donc fonctionner de cet aspect.

Cependant, même lorsque les adresses IP sont bloquées, le nombre limité de tentatives de connexion permet de signaler les verrouillages (fréquents) des adresses IP. Je pensais que c'était curieux, car avec le bloc .htaccess en place, il semble qu'il soit impossible de commencer par le script wp-login.php, sans parler de la tentative de connexion traitée par le plug-in.

J'ai donc essayé une autre expérience: alors que j'étais déjà connecté à WP, j'ai changé le nom de wp-login.php en wp-login.xyz, empêchant ainsi le script de s'exécuter entièrement. Même avec le script de connexion complètement désactivé, j'ai toujours des notifications indiquant que des tentatives de connexion sont en cours et que les adresses IP sont verrouillées.

Ensuite, j'ai pensé que quelqu'un avait peut-être un cookie d'authentification. J'ai donc changé les sels. Les tentatives viennent quand même.

J'ai consulté le codex pour obtenir de l'aide sur l'API d'authentification, mais la plupart des sources y sont incomplètes et, de toute façon, je ne vois pas comment il serait possible de tenter une connexion autrement que via wp-login.php.

Ma question est donc la suivante: quels autres moyens, le cas échéant, de tenter une connexion sont-ils possibles sans le script wp-login.php? Et comment de tels itinéraires de connexion alternatifs peuvent-ils être désactivés?

EDIT: code .htaccess (premières lignes du fichier): il se trouve dans le répertoire racine WP (même emplacement que wp-login.php.

<FilesMatch wp-login.php>
order deny,allow
Deny from all

# Allow from this IP address
allow from xx.xxx.xxx.xx  #My IP
</FilesMatch>

ErrorDocument 401 "Sorry. No logins here!"
ErrorDocument 403 "Sorry. No logins here!"
loginauthentication
1
Caspar

La réponse est très probablement XML-RPC, qui est utilisé pour communiquer avec les applications wordpress mobiles et est toujours activé dans les versions les plus récentes. Si vous n'utilisez pas d'applications mobiles pour administrer votre WP, vous pouvez utiliser mon plug-in - http://wordpress.org/plugins/control-xml-rpc-publishing/ pour le désactiver.

2
Mark Kaplun

Comme @MarkKaplun l'a suggéré, le problème était bien XML-RPC. J'ai contacté la société d'hébergement et demandé une lecture des journaux. xmlrpc.php a été touché plus de 3500 fois en moins de 24 heures (et il s’agit d’un petit site où personne n’aurait aucune raison de frapper rien autant de fois!).

Edit

Voici ce que je soupçonne qu'il se passait. De Le blog de Antti Vilpponen sur la limitation des attaques par xmlrpc:

D'après les tests que j'ai effectués, j'ai constaté que WordPress prend également en charge les URL avec informations d'identification. Un attaquant peut donc utiliser une URL telle que http://admin:[email protected]/changeDNS.asp?newDNS=aaaa pour reconfigurer le routeur interne.

Donc, c'est frapper xmlrpc.php avec la demande authentifiée qui a le même effet que d'utiliser wp-login.php et déclenche WP pour entrer dans sa routine d'authentification - ce qui à son tour déclenchait le plugin Limit Login Attempts et générait le verrouillage.

/ Modifier

Plutôt que d'utiliser un plug-in (c'était avant la réponse de @MarkKaplan), j'ai choisi de couper simplement tout accès à xmlrpc.php sur le serveur, en utilisant à nouveau .htaccess dans la racine WP comme suit:

<Files xmlrpc.php>
    Order allow,deny
    Deny from all
</Files>

Travaillé comme un charme. Mon identifiant est resté silencieux.

Edit

Le nom de fichier dans la directive Apache a été mal orthographié en tant que xlmrpc.php. J'ai essayé de le corriger, mais la limite d'édition de caractères stackexchange ne m'a pas laissé jusqu'à ce que j'écrive ce paragraphe inutile. C'est maintenant correct.

1
Caspar