Viele POST-Anfragen an /xmlrpc.php von GoogleBot, die den Server herunterfahren?

9

Ich habe mehrere gehostete WordPress-Blogs und ich habe versucht, sie zu besuchen, und sie sind sehr langsam. Ich habe mir meine Serverprotokolle angesehen und diese gefunden

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"

Ich erhalte ~ 10 Treffer pro Sekunde für die Datei /xmlrpc.php vom GoogleBot auf mehrere Websites, und dies scheint den Server zu verlangsamen. ich renne

tail -f

in der Protokolldatei und kann nur sehen, wie diese Anforderungen fortgesetzt werden. Weiß jemand, warum dies passieren könnte oder was Sie tun könnten, um es zu stoppen?

server-load

— jkeesh
quelle

2

Ich müsste die IP-Adresse und die Adressen nachschlagen, aber ich wette, das ist nicht wirklich Googles Crawler , sondern nur ein (höchstwahrscheinlich) bösartiger Bot, der vorgibt, es zu sein.

— s_ha_dum

1

missbrauchipdb.com/whois/188.138.33.149

— s_ha_dum

Ja, ich dachte nicht, dass es ein Googlebot ist - ich denke, das war in meiner Frage nicht klar. Was tun Sie auf jeden Fall dagegen? sollte ich ips blockieren?

— Jkeesh

7

Ich würde die IP mit blockieren, iptableswenn ich es wäre und wenn Sie diese Art von Zugriff auf Serverebene haben.

Sie können auch xmlrpc deaktivieren. Leider wurde seit 3.5 die Admin-Bildschirmoption zum Deaktivieren dieser Funktion entfernt. Eine einzelne Codezeile sollte es jedoch deaktivieren: add_filter( 'xmlrpc_enabled', '__return_false' );Dies könnte einen gewissen Overhead bei den Anforderungen sparen, obwohl nicht alles beseitigt wird.

— s_ha_dum
quelle

Vielen Dank. Am Ende habe ich es mit iptables blockiert, und das schien zu helfen.

— Jkeesh

5

"Googlebot" hat keinen Grund, auf xmlrpc.php zuzugreifen. Sie können dies oben in Ihre xmlrpc.php einfügen

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

Ich vermute, es ist eine Kern-WordPress-Datei. Es könnte also ärgerlich sein, dies auf dem neuesten Stand zu halten. Wäre schön, wenn Automattic Akismet verwenden würde, um diese IPs aus allen WP-Skripten überall auf die schwarze Liste zu setzen.

Update: Ich habe die Berechtigung mit chmod 0 xmlrpc.php(siehe meine Kommentare) entfernt, nachdem ein DDoS begonnen hat, meinen Server zu besteuern. Mit anderen Worten, dieser bedingte PHP-Code hindert einen aggressiven Angreifer möglicherweise nicht daran, Ihr Blog vorübergehend zu deaktivieren. In jedem Fall geben sie normalerweise ziemlich schnell auf.

— PJ Brunet
quelle

Wenn Sie ein Blogger sind, der keine separate Blog-Clientanwendung für Mobilgeräte oder Desktops verwendet, benötigen Sie xmlrpc.php nicht und können diese sicher löschen. Mit anderen Worten, wenn Sie Ihre Blog-Beiträge im WordPress-Dashboard im Web schreiben, benötigen Sie xmlrpc.php nicht. In letzter Zeit wird xmlrpc.php wirklich von Hackern angegriffen, und ich persönlich empfehle Ihnen, diese Datei einfach zu löschen.

— PJ Brunet

Um meinen obigen Kommentar zu überarbeiten: Anstatt xmlrpc.php zu löschen, könnten Sie die Datei "chmod 0" und sie nach Bedarf wieder zum Leben erwecken, da Sie für bestimmte Dinge möglicherweise xmlrpc.php benötigen, wie ich mich vage erinnere, dass Sie xmlrpc.php benötigen um Jetpack zu aktivieren.

— PJ Brunet

Danke für den Tipp. Ich habe gerade ein exit()oben in die Datei eingefügt, da wir immer wp-admin verwenden, um Seiten zu bearbeiten. Ich fand dies eine relative Schwäche in Wordpress, die mich beunruhigt, WP für eine große Organisation zu implementieren. Wenn der xmlrpc deaktiviert ist, müsste ich mir keine Sorgen machen, oder?

— Mattijs

1

Blockieren Sie die IP mit 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

— 3m1l
quelle

Es wäre schön, eine Erklärung für diesen Shell-Befehl zu sehen.

— David

@ David Es ist ein bisschen anmaßend und ungeschickt IMO. Im Wesentlichen wird dabei die Datei access.log gescannt und nach Anforderungen an xmlrpc.php gesucht. Anschließend werden doppelte IP-Adressen gezählt, vom höchsten zum niedrigsten sortiert und die Top-8-IPs (IPs mit den meisten doppelten Anforderungen) zurückgegeben. Für jede dieser IP-Adressen wird die Firewall angewiesen, den gesamten Datenverkehr von ihnen zu löschen. Auf meinem Server gibt es viel mehr als 8 IPs, die dieses Zeug ausführen, und dies könnte auch legitime Anfragen blockieren, da nicht geprüft wird, wer es macht.

— tdk2fe

0

Wäre dies kürzlich passiert und es hätte den Server getötet und wir verwenden jetzt fail2ban , um das Problem zu beheben .

Diese Konfiguration wurde zu jail.local hinzugefügt :

[apache-xmlrpc]

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

Und erstellen Sie den Filter in filter.d / apache-xmlrpc.conf :

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

In meinem Fall kamen die Angriffe nicht immer von Googlebot, daher wurde der reguläre Ausdruck etwas breiter, aber für meine Zwecke gibt es kaum einen guten Grund dafür, dass eine IP in 5 Minuten mehr als 30 Mal auf xmlrpc trifft.

— Billynoah
quelle