Beaucoup de requêtes POST à ​​/xmlrpc.php de GoogleBot en train de supprimer le serveur?


9

J'ai plusieurs blogs wordpress hébergés, et j'ai essayé de les visiter et ils sont vraiment lents. J'ai regardé les journaux de mon serveur et j'ai trouvé ça

stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:28 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:28 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:28 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:28 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:29 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:29 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:29 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:29 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:31 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:31 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"
stanfordflipside.com:80 188.138.33.149 - - [17/Aug/2013:17:14:31 -0700] "POST /xmlrpc.php HTTP/1.1" 200 595 "-" "GoogleBot/1.0"

J'obtiens ~ 10 accès par seconde au fichier /xmlrpc.php du GoogleBot vers plusieurs sites, et cela semble ralentir le serveur. je cours

tail -f 

sur le fichier journal, et peut simplement voir ces demandes se poursuivre. Est-ce que quelqu'un sait pourquoi cela pourrait se produire ou ce que vous pourriez faire pour l'arrêter?


2
Je devrais rechercher l'adresse IP et les adresses, mais je parie que ce n'est pas réellement le robot de Google , juste un bot malveillant (très probablement) faisant semblant de l'être.
s_ha_dum


ouais je ne pensais pas que c'était un googlebot - je suppose que ce n'était pas clair dans ma question. en tout cas, que faites-vous à ce sujet? dois-je bloquer les IPS?
jkeesh

Réponses:


7

Je bloquerais l'adresse IP iptablessi c'était moi et si vous avez ce type d'accès au niveau du serveur.

Vous pouvez également désactiver xmlrpc. Malheureusement, depuis la version 3.5, l'option d'écran administrateur pour désactiver cette fonctionnalité a été supprimée. Une seule ligne de code devrait cependant le désactiver: add_filter( 'xmlrpc_enabled', '__return_false' );cela pourrait économiser une partie de la charge des demandes, mais cela ne l'éliminera pas entièrement.


Merci. J'ai fini par le bloquer avec iptables, et cela a semblé aider.
jkeesh

5

"Googlebot" n'a aucune raison d'accéder à xmlrpc.php Vous pouvez l'ajouter en haut de votre xmlrpc.php

// Block fake Googlebot
if ( strpos($_SERVER['HTTP_USER_AGENT'], "Googlebot") === true ) { exit(); }

Je suppose que c'est un fichier WordPress de base. Il peut donc être ennuyeux de garder cela à jour. Ce serait bien si Automattic utilisait Akismet pour blacklister ces IP de tous les scripts WP, partout.

Mise à jour: j'ai fini par supprimer l'autorisation avec chmod 0 xmlrpc.php(voir mes commentaires) après qu'un DDoS a commencé à taxer mon serveur. En d'autres termes, ce code PHP conditionnel pourrait ne pas empêcher un attaquant agressif de désactiver temporairement votre blog. En tout cas, ils abandonnent généralement assez vite.


De plus, si vous êtes un blogueur qui n'utilise pas une application cliente de blog mobile ou de bureau séparée, vous n'avez pas besoin de xmlrpc.php et vous pouvez le supprimer en toute sécurité. En d'autres termes, si vous écrivez vos articles de blog dans le tableau de bord WordPress, sur le Web, vous n'avez pas besoin de xmlrpc.php. Dernièrement, xmlrpc.php est vraiment attaqué par des pirates et personnellement, je vous recommande de supprimer ce fichier.
PJ Brunet

Pour réviser mon commentaire ci-dessus: plutôt que de supprimer xmlrpc.php, vous pouvez "chmod 0" le fichier et le faire revivre au besoin, car vous pourriez avoir besoin de xmlrpc.php pour certaines choses, comme je me souviens vaguement que vous avez besoin de xmlrpc.php pour activer Jetpack.
PJ Brunet

Merci pour le conseil. Je viens de mettre un exit()en haut du fichier car nous utilisons toujours wp-admin pour éditer les pages. J'ai trouvé cela une faiblesse relative sur Wordpress qui me fait craindre d'implémenter WP pour une grande organisation. Avec le xmlrpc désactivé, je n'aurais pas à m'inquiéter, non?
Mattijs

1

bloquer l'IP avec iptables:

for ip in $(grep xmlrpc /var/log/apache2/access.log | cut -d' ' -f1 | sort | uniq -c | sort -rn | head -n8 | awk '{print $2}'); do \
iptables -A INPUT -s $ip -j DROP; \
done

Ce serait bien de voir une explication de cette commande shell.
David

@David Son IMO un peu présomptueux et maladroit. Essentiellement, cela va analyser le fichier access.log et rechercher toutes les demandes à xmlrpc.php. Ensuite, il compte les adresses IP en double, les trie du plus élevé au plus bas et renvoie les 8 IP les plus importantes (IP avec le plus de demandes en double). Pour chacune de ces adresses IP, il indique au pare-feu de supprimer tout le trafic qui en découle. Sur mon serveur, il y a beaucoup plus de 8 adresses IP qui font ce genre de choses, et cela pourrait également bloquer les demandes légitimes, car il ne contrôle pas qui les fait.
tdk2fe

0

Si cela s'était produit récemment et que cela tuait le serveur, nous utilisons maintenant fail2ban pour atténuer le problème.

Ajout de cette configuration à jail.local :

[apache-xmlrpc]

enabled = true
port = http,https
filter = xmlrpc
logpath = /var/log/apache2/*access.log
maxretry = 30
findtime = 300
bantime = -1

Et créez le filtre dans filter.d / apache-xmlrpc.conf :

[Definition]
failregex = ^<HOST> -.*"(GET|POST) .*xmlrpc.php
ignoreregex =

Dans mon cas, les attaques ne provenaient pas toujours de googlebot, ce qui a rendu la regex un peu plus large, mais pour moi, il n'y a guère de bonne raison pour qu'une IP frappe xmlrpc 30+ fois en 5 minutes.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.