Eben kam von meinem Provider eine Mail, nach der automatisierte massive Aufrufe der Datei xmlrpc.php in meinem Blog dazu geführt haben, dass der komplette Server an seine Leistungsgrenze gekommen ist. Da das Blog auf einem Shared-Hosting von All-Inkl läuft, war hier natürlich schnelles Handeln gefragt. Die Jungs vom Support haben das Script aus dem Grund erstmal nicht mehr aufrufbar geschaltet, indem sie die Rechte der Datei von 744 auf 300 geändert haben. Damit laufen die Aufrufe von dem Spaßvogel, der sich da reinhacken möchte, erstmal ins Leere.
Mittlerweile habe ich diese Art Attacken auch auf anderen Wordpress Seiten und bei anderen Hostern. Ein Auszug aus den Logdaten zeigt die immer wiederkehrenden Versuche, Wordpress über einen POST Aufruf der xmlrpc.php zu knacken. Das Ganze sieht so aus:
[ 112] ‚0-3 “- “0/0/2867 “.“171.83“2228 “121334 “0.0 “0.00 “45.59 “5.199.XXX.XXX “POST “ www.kindskopp.com“/xmlrpc.php‘
[ 461] ‚0-3 “- “0/0/3058 “.“171.77“2228 “128420 “0.0 “0.00 “97.27 “5.199.XXX.XXX “POST “ www.kindskopp.com“/xmlrpc.php‘
[ 216] ‚0-3 “- “0/0/2878 “.“171.40“2228 “2765 “0.0 “0.00 “43.40 “5.199.XXX.XXX “POST “ www.kindskopp.com“/xmlrpc.php‘
[ 361] ‚0-3 “- “0/0/2844 “.“171.66“2228 “23121 “0.0 “0.00 “38.72 “5.199.XXX.XXX “POST “ www.kindskopp.com“/xmlrpc.php‘
[ 508] ‚0-3 “- “0/0/3038 “.“171.80“2228 “78254 “0.0 “0.00 “44.41 “5.199.XXX.XXX “POST “ www.kindskopp.com“/xmlrpc.php‘
[ 68] ‚0-3 “- “0/0/3018 “.“171.65“2228 “118321 “0.0 “0.00 “41.81 “5.199.XXX.XXX “POST “ www.kindskopp.com“/xmlrpc.php‘
Auch bei diesem anderen Hoster wurde mir mitgeteilt, dass diese Attacken den ganzen Server in Bedrängnis bringen können, auch wenn mein Wordpress nur auf einem Shared-Hosting läuft.
Ich habe dann mal geschaut, was man noch machen kann, um diese Datei zu schützen und habe folgende Möglichkeiten gefunden:
Kapitel in diesem Beitrag:
1. Komplettes Verbot der Zugriffe auf die XML-RPC Schnittstelle
Dabei wird die xmlrpc.php Datei durch einen Eintrag in die .htaccess-Datei komplett geschützt. Das heißt, keiner kann mehr von aussen auf diese Datei zugreifen. Der Schutz ist 100% und sicher, aber er hat den Nachteil, dass man selbst nicht mehr mit Programmen wie Wordpress for iOS oder dem Windows Live Writer zugreifen kann. Auch Pingbacks oder Trackbacks können so nicht mehr von externen Blogs zum eigenen Blog „durchdringen“. Wer damit kein Problem hat, weil er sowieso immer im Admin von Wordpress arbeitet und auch keine Trackbacks von anderen Blogs wünscht, der ist mit dieser Lösung gut bedient.
Hier der entsprechende Code, den man in die .htaccess Datei im Root-Ordner der Wordpress Installation einrichten muss:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Einschub – weitere interessante Beiträge im Blog:
- So löscht man den Google Verlauf
- Apple-ID Passwort vergessen – was tun?
- Samsung Galaxy Ladekabel
- Die LAN Kabel Bestseller
- Die besten Staubsaugroboter nach Stiftung Warentest
2. Zugriffe auf die xmlrpc.php nur teilweise einschränken
Wer mit dem Windows Live Writer, Poster oder auch der iOS App Wordpress for iOS arbeitet, der wird sicher nicht komplett darauf verzichten wollen. Aus dem Grund bietet sich für diese Blogger folgende Variante der oben genannten Zusatzes für die .htaccess Datei an, die für gängige Drittsoftware die XMP-RPC-Schnittstelle frei hält. Weiterhin geblockt werden aber die Trackbacks von anderen Blogs.
So sieht der angepasste Code aus:
<IfModule mod_setenvif.c>
<Files xmlrpc.php>
BrowserMatch "Poster" allowed
BrowserMatch "WordPress" allowed
BrowserMatch "Windows Live Writer" allowed
BrowserMatch "wp-iphone" allowed
BrowserMatch "wp-android" allowed
Order Deny,Allow
Deny from All
Allow from env=allowed
</Files>
</IfModule>
Die Zeilen mit „BrowserMatch“ lassen sich natürlich beliebig anpassen, falls man ein bestimmtes Programm verwendet, das im oben genannten Script nicht bedacht wurde. Wichtig ist, dass man das Apache-Modul „mod_setenvif“ installiert haben muss, damit der Schutz funktioniert. Dieses Modul ist aber in vielen Webservern bereits installiert. Ebenfalls wichtig ist es, dass man weiß, dass der User-Agent sehr leicht zu fälschen ist. Es ist also kein wasserdichter Schutz, den man hier vornimmt!
Ich habe mich im aktuellen Fall für die rigorose Variante entschieden und sperre einfach alles aus, was auf die Datei zugreifen will. Ich bekomme kaum Trackbacks und nutze auch keine Drittsoftware sondern nur den Wordpress-Admin, um Blogposts zu verfassen. So sieht nun meine htaccess-Datei von Wordpress aus:
Update: Seit dem Wordpress Update auf Version 3.9.2 ist es nicht mehr möglich DDoS-Attacken auf die xmp-rpc.php zu fahren. Das Wordpress-Team hat reagiert und entsprechend den Code geändert. Damit könnt ihr euch ab dieser Version die Modifikation, wie oben beschrieben, sparen.
Meine Tipps & Tricks rund um Technik & Apple
Ähnliche Beiträge
Seit 2012 betreibe ich meinen Blog als Sir Apfelot und helfe meinen Lesern bei technischen Problemen. In meiner Freizeit flitze ich auf elektrischen Einrädern, fotografiere mit meinem iPhone, klettere in den hessischen Bergen oder wandere mit meiner Familie. Meine Artikel behandeln Apple-Produkte, Drohnen-News und Lösungen für aktuelle Bugs.
Pingback: Wordpress Sicherheit: wp-login.php umbenennen und vor Hackern schützen » Sir Apfelot
Ich hatte den gleichen Angriff mit 280.000 Zugriffen an einem Tag.
Dank der beschriebenen Lösung (mit teilweiser Freigabe) konnte ich die Seite wieder aktivieren.
Jetzt habe ich nur noch das Problem, dass Jetpack (wordpres.com) nicht mehr zugreifen kann. Es kommt folgende Meldung:
Deine Webseite muss öffentlich erreichbar sein, um Jetpack verwenden zu können: site_inaccessible
Fehlerdetails: The Jetpack server was unable to communicate with your site [HTTP 403]. Ask your web host if they allow connections from WordPress.com. If you need further assistance, contact Jetpack Support: http://jetpack.me/support/
Frage: Welcher BrowserMatch muss dafür eingetragen werden.
Hi! Also den Browsermatch konnte ich nicht ermitteln. Ich habe keine Installation mit Jetpack, wo ich hätte testen können. Aber in deinem Fall könnte es vielleicht klappen, wenn man die Zugriffe auf die xmlrpc.php für alle IP Adressen bis auf die von Wordpress.com sperrt. Ich habe mal geschaut, welche IP das ist, aber ich veröffentliche sie hier mal nicht. Man sollte ja vorsichtig damit sein. :)
Aber einen Tipp dazu: Öffne einfach ein Terminal-Fenster am Mac oder PC und tippe dann „ping wordpress.com“. Dann erhälst du eine IP-Adresse, die du in folgenden Eintrag packst, der dann in die htaccess-Datei gesetzt wird:
<Files xmlrpc.php>
Order Deny,Allow
Deny from All
Allow from HIER.DIE.IP.EINGEBEN
</Files>
Mit etwas Glück nutzt Wordpress-Jetpack die gleiche IP wie die Domain. Wenn das nicht geht, dann versuche mal bei der IP das letzte Oktet (also den letzten Punkt und die Zahl danach) wegzulassen. Dann wird die Datei für den gesamten IP-Block geöffnet – mit einer guten Chance, dass Jetpack auch dabei ist.
Hi,
ich habe auch diese Fehleranzeige bei „jetpack“ gehabt und habe mich dann für das Plugin „WPtouch Mobile Plugin“ entschieden. Es ist auch lange nicht so groß , wie jetpack und „rubelt“ auch die Homepage für Mobile Geräte um. (Ich habe aber nur aus diesem Grunde „jetpack“ installiert).
Was soll ein 403 bringen? Damit der Server erst recht eine hohe Last bekommt und ständig tausenden Anfragen von unterschiedlichen IPs mit 403 no permisson antwortet? Damit die Angreifer noch agressiver einen DoS starten und den Server lahm legen? Nein. –
Wozu wurden Firewalls entwickelt? Also…
fail2ban installieren und mit einer knallharten Regel die (meist) Botnetzangriffe aussperren auf Netzwerkebene. Nicht auf Server-Ebene. Da ist es schon zu spät. Also filter erstellen mit zB:
—> failregex = -.*-.* „(GET|POST) .*\/xmlrpc\.php.*
und in der jail maxretry = 1. Dann freut sich der der Apache / nginx und kann sich auf das Wesentliche konzentrieren…
Auch andere Dienste können mit fail2ban wunderbar aberiegelt werden. Die wp-login-php ist auch eine begehrtes Ziel.
PS. Dein Scroll-Script ist viel zu schnell am Mac Trackpad und der Subit-Button ist im Firefox verschwunden auf 1×1 Pixel…
Hallo Marcus!
Danke für deinen Hinweis. Ich kenne fail2ban nicht, aber wenn ich es richtig gelesen habe, kann man es sehr flexibel einsetzen. Ich nutze bei den meisten Blogs nun das Wordfence Plugin. Das hält einem die DoS Attacken auch vom Leib.
Wegen dem PS: Ich hab am MacBook mal die Seite am Trackpad aufgerufen und das scrollt eigentlich normal. Und der Submit Button für Kommentare funktioniert auch ganz korrekt. Ich wüsste jetzt nicht, wie ich nach dem Fehler suchen sollte… :-(