XML-RPC-Schnittstelle schützen

Seit der Version 3.5 ist die XML-RPC-Schnittstelle standardmäßig in Wordpress aktiviert. So ist es Angreifern möglich, automatische Anmeldeversuche durchzuführen. Dies stellt ein Sicherheitsrisiko dar und kann darüber hinaus bei einer höheren Anzahl von automatischen Zugriffen den Server und somit die Performance beeinträchtigen! Daher sollten die Zugriffsmöglichkeiten auf die XML-RPC-Schnittstelle deaktiviert oder – falls XML-RPC benötigt wird – zumindest eingeschränkt werden.

Zugriffe auf die XML-RPC komplett unterbinden

Um die WordPressinstallation vor Angriffen dieser Art zu schützen, kann der Zugriff auf die Datei xmlrpc.php via .htaccess komplett unterbunden werden:

Deaktivierung via .htaccess:

<Files xmlrpc.php>
Require all denied
</Files>

Wird XML-RPC nicht genutzt, empfehlen wir die komplette Deaktivierung.

Zugriffe auf XML-RPC einschränken

Wenn man XML-RPC nutzt und auf den Zugriff daher nicht komplett unterbinden kann, können alle Zugriffe verboten, jedoch einzelne Clients erlaubt werden.

Freigabe für einzelne Clients via .htaccess:

<IfModule mod_setenvif.c>
<Files xmlrpc.php>
BrowserMatch "WordPress" allowed
BrowserMatch "Windows Live Writer" allowed
BrowserMatch "wp-iphone" allowed
BrowserMatch "wp-android" allowed
BrowserMatch "wp-windowsphone" allowed
Order Deny,Allow
Deny from All
Allow from env=allowed
</Files>
</IfModule>

Nicht benötigte Freigaben sollten zeilenweise entfernt werden!

Achtung: Es handelt sich dabei nicht um einen absoluten Schutz der XML-RPC-Schnittstelle. Es werden lediglich die Zugriffsmöglichkeiten verringert.

Um die Schnittstelle vollständig zu schützen, muss der Zugriff auf XML-RPC wie oben beschrieben komplett deaktiviert werden.

Vielen Dank an die Informationen dazu an wpcoder.de!

End of article

Anna Philipp

Über den Autor

Anna Philipp

7 Kommentare

Bitte füllen Sie das Captcha aus : *

Reload Image

Die von Ihnen hier erhobenen Daten werden von der domainfactory GmbH zur Veröffentlichung Ihres Beitrags in diesem Blog verarbeitet. Weitere Informationen entnehmen Sie bitte folgendem Link: www.df.eu/datenschutz


  • ad1601com
    ad1601com - 26. August 2014 um 16:51 Uhr

    Ich mische mich mal ein, ohne konkrete Angriffe über diesen Weg zu kennen:

    BrowserMatch fragt nur ab, ob sich der Client als legitimes Endgerät auszugeben versucht. Eine Filterung hierauf ist deshalb IMHO nur nice-to-have, da sie sehr einfach umgangen werden kann – eben in dem man im angreifenden Client einen entsprechenden User-Agent hinterlegt. Um einen möglichen Angriff zu verschleiern sollte ein intelligenter Angreifer dies sowieso tun.

    Zweckmäßiger erscheint mit eine Filterung auf Basis der IP-Adresse. Kommunizieren Systeme hinter festen IPs miteinander, ist eine exklusive Beschränkung der Zugriffe auf diese IPs selbstverständlich der einfachste Weg.

    Wird die Schnittstelle über ein Smartphone angesprochen, dürfte eine Filterung auf das IP-Netz des Mobilfunkproviders sowie des heimischen DSL-Providers jeglichen Missbrauch bereits deutlich erschweren.

    Wird die Schnittstelle nur aus dem Heimnetzwerk genutzt, kann der Zugriff auch via DynDNS-IP abgesichert werden: In dem die IP der DynDNS-Domain ausgelesen wird und der Zugriff auf diese beschränkt wird, ist ein Missbrauch dieses Weges beinahe ausgeschlossen.

    Da mir kein Weg bekannt ist in einer htaccess die ausgelesene IP einer Domain auf Allow zu stellen, ist die Lösung hierfür 3 Zeilen Code in den Header der xmlrpc.php zu hinterlegen (nicht updatesicher) oder aber die .htaccess dynamisch via Cronjob schreiben zu lassen.

    Diese Wege sind aber natürlich alle etwas komplizierter und hätten – im Detail beschrieben – ziemlich sicher das Posting von Anna gesprengt 😉

    Grüße
    Andreas

  • moinsen
    moinsen - 27. August 2014 um 15:11 Uhr

    ob sich das lohnt muss jeder natürlich selber entscheiden.
    solange der normale login nicht geschützt ist (übrigens bitte nicht mit diesem WPsecurity plugin – da kann man das cookie einfach löschen und hat wieder 3 versuche 😀 )
    Ich seh dev vector als nicht sehr kritisch an, solange man sich über plugins massen an 3rd party code ins WP holt muss man sich darüber eigentlich keine gedanken machen 😉

    nen gutes passwort ist wohl der beste schutz

  • Tobsen
    Tobsen - 27. August 2014 um 16:17 Uhr

    Für welche Art von Dingen wird dieses xmlrpc denn genau benutzt?
    Denn diese Datei scheint es doch schon lange zu geben.

    Wird die nicht auch für Pingbacks verwendet? Dann wäre es ja etwas schade… 🙂

  • ad1601com
    ad1601com - 31. August 2014 um 12:46 Uhr

    @Tobsen:
    Öhm… offensichtlich! dF liefert hierfür netterweise selbst den Beweis:

    Auf welchem Protokoll Pingback basiert hatte ich zugegeben nicht auf dem Schirm. WP dokumentiert das hier: http://codex.wordpress.org/XML-RPC_Pingback_API

    In diesem Fall sollte man entsprechend überlegen, ob diese Filterung so Sinn gibt.

    BrowserMatch „WordPress“ allowed

    … wird zwar mutmaßlich WP das PingBack erlauben – andere Blogsoftware die dieses Protokoll ebenfalls beherrscht aber aussperren. Anscheinend hat dF die genannte Sperre bei sich selbst nicht umgesetzt, sonst wäre der o. g. Link nicht aufrufbar.

    Grüße
    Andreas

  • Karsten
    Karsten - 6. November 2014 um 07:56 Uhr

    Hallo. Ich hatte nun bei einem Blog Anmeldeversuche festgestellt und durch Zufall von dieser xml-rpc Sache gelesen.
    Beim Anschauen der Serverlogs ist mir aufgefallen das die Versuche wohl über diese Schnittstelle erfolgten. Also den Codeschnippsel in die htaccess geschrieben. Blos, wie melde ich mich jetzt selber auf meinem Blog an? Über den Webbrowser geht es ja nun nicht mehr. Wäre ja blöd jedesmal das Teil zu löschen und anschließend wieder einzufügen.
    Gruß Karsten

  • Anna
    Anna - 10. November 2014 um 13:38 Uhr

    Hallo Karsten, Sie sollten damit nur Clients ausschließen, die Sie selbst nicht nutzen. Ihren eigenen müssten Sie erlauben.