web-dev-qa-db-fra.com

Les connexions horaires à mon site WordPress via XMLRPC bloquent mon adresse IP sur BlueHost car ils voient de nombreuses connexions par e-mail.

Je possède actuellement un site WordPress dans un hébergement (BlueHost). D'autre part, j'ai une application dans nos bureaux à . Net . Cette application met à jour WordPress via XMLRPC toutes les heures.

Le problème est que mon adresse IP est temporairement bloquée tous les jours.

J'essaie de comprendre quel type de solution existe ces problèmes. À partir du service d'hébergement, ils me disent qu'il y a de nombreuses tentatives de connexion via par courrier électronique . Ils le voient comme un email, mais je sais que c'est via XMLRPC.

  1. Y a-t-il un moyen d'éviter d'être considéré comme du spam, puisque ce n'est vraiment pas le cas?
  2. Est-ce la seule solution pour faire moins de connexions? Ils me disent 3 ou 4 par jour. J'ai besoin de 24.
  3. Existe-t-il une solution au niveau de la configuration d'hébergement pour pouvoir mettre l'IP source dans une liste blanche?

Je suppose que ce doit être un problème assez commun, c'est pourquoi je le pose ici. De déjà merci beaucoup.

Si vous avez besoin d'informations supplémentaires sur la façon dont je me connecte, je peux ajouter le code source.

UPDATE

Réponse de bluehost:

Merci d'avoir contacté le support. Nous avons reçu votre dossier car votre adresse IP était bloquée en permanence. Ceci est très inhabituel et peu commun pour une adresse IP d'être listée aussi souvent. Il semble que vous utilisiez xmlrpc.php pour vous connecter. C’est une pratique courante à laquelle nous assistons par des tentatives de malveillance. En effet, des tentatives malveillantes tenteront d'exploiter ce fichier pour obtenir un accès alors qu'elles ne le devraient pas. Je recommande fortement de revenir à une procédure de connexion standard.

UPDATE 2:

Deuxième réponse de l'hébergement:

Nous suivons votre cas concernant votre journalisation XMLRPC. Malheureusement, le blocage est dû à une règle de sécurité mod sur votre serveur partagé. Il s'agit d'une règle de sécurité dans nos configurations Mod Security qui ne peut pas être supprimée dans un environnement de serveur partagé. Nous avons essentiellement ces règles de sécurité Mod configurées pour empêcher le client d'être vulnérable aux exploits que XMLRPC peut autoriser, tels que: https://null-byte.wonderhowto.com/how-to/gain-control-wordpress- en exploitant-xml-rpc-0174864 /

wordpressphpsecurityshared-hostingweb-services
3
jpussacq

Un peu d'histoire ...

SOURCE

XML-RPC est activé par défaut depuis WP version 3.5, avec le support XML-RPC activé, vous pouvez publier sur votre blog WordPress à l'aide de nombreux clients Weblog tiers connus. Malheureusement, c’est un autre point d’entrée pour les pirates informatiques qui souhaitent accéder à votre site Web.

La plupart des WordPress administrateurs n'utilisent même pas XMLRPC

En fait, la plupart des webmasters n'ont aucune idée de ce que fait ce fichier. C'est pourquoi la plupart des hôtes partagés le bloquent ou le restreignent complètement. Les hôtes qui ne bloquent pas et les administrateurs de sites Web qui ne l'utilisent pas, il est recommandé par la communauté de la sécurité de le bloquer simplement en procédant comme suit:

Renommer xmlrpc.php

mv xmlrpc.php randomstring.php

Suppression de xmlrpc.php

rm xmlrpc.php

. htaccess Deny 

<FilesMatch "xmlrpc.php">
  Order Deny,Allow
    deny from all
</FilesMatch>

Mais il arrive parfois que xmlrpc.php soit réellement utile, mais comment en tirez-vous profit sans être attaqué en même temps et contourner les blocages système?

La méthode la plus simple consiste à le renommer. Vous pouvez le faire en utilisant la méthode du système de fichiers, par exemple via SFTP, FTP, SSH, etc. ou en utilisant l'un des nombreux plug-ins disponibles dans la bibliothèque de plug-ins WordPress.

La plupart des hôtes bloquent par nom de fichier, si bien le renommer, vous fournira une solution de contournement et rendra votre site plus sécurisé. Vous devez vous attendre à beaucoup d'erreurs 404 dans vos journaux, car ces robots reniflant vont causer cela, 404 n'indique pas que votre site est cassé, mais en fait, cela confirme que cela fonctionne.

Si vous préférez, vous pouvez utiliser la méthode Rename puis utiliser le bloc DENY mentionné ci-dessus. Vous pouvez, bien sûr, faire preuve d’inventivité et les rediriger vers un site Web avec une taille de page ÉNORME qui pourrait/causerait le crash d’un grand nombre de robots mal conçus, par exemple:

redirect 301 /xmlrpc.php http://www.example.com/bigpagesize.html
3
Simon Hayter