XML-RPC Schnittstelle in WordPress per .htaccess schützen

Rechte der XML-RPC Datei
Rechte der XML-RPC Datei

So sieht die Rechtevergabe nach dem Eingriff des Supports aus, um das Script zu blocken.

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->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:

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:

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:

htaccess Schutz XML RPC

Dies ist meine komplette htaccess-Datei im WordPress Hauptverzeichnis inklusive dem Sperrcode, um die XML-RPC Schnittstelle zu schützen.

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.

Sir Apfelot auf SteadyHQ unterstützen

6 Kommentare

  1. […] In den letzten Tagen konnte ich bei einigen Kundenblogs wieder Attacken auf den Adminbereich “wp-admin” von WordPress erkennen. Ich verwende bei den meisten Blogs das Plugin Login-Lockdown, das nicht nur die erfolglosen Loginversuche mitschneidet, sondern auch das Login für eine IP sperrt, wenn eine bestimmte Anzahl an falschen Logins erfolgt ist. Die Anzahl der Logins und die Dauer der Sperrung kann man selbst festlegen, indem man die Einstellungen der Plugins im Adminbereich verändert. Auf diese Weise sieht man eben auch, ob ein Hacker sich mit einer Brute-Force-Attacke Zugriff auf den WordPress-Admin verschaffen möchte. Diese Technik wird übrigens auch verwendet, um die XML-RPC-Schnittstelle von WordPress zu attakieren – aber dazu mehr in einem anderen Beitrag. […]

  2. elotse sagt:

    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.

    • Sir Apfelot sagt:

      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.

    • Marianne sagt:

      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).

    • Marcus sagt:

      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…

      • Sir Apfelot sagt:

        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… 🙁

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.