Schon seit dem Start im Jahre 2003 bietet die WordPress XML RPC Schnittstelle verschiedene Funktionen, um aus der Ferne Daten übertragen und mit der Webseite interagieren zu können. Auch wenn die Schnittstelle gewisse Vorteile und Möglichkeiten bietet, ist sie ebenso ein großes Risiko.
Was genau diese Schnittstelle ist, was für Möglichkeiten angeboten werden und wie wir am besten mit dieser Schnittstelle umgehen erkläre ich euch heute.
Was genau ist die berüchtigte xmlrpc.php?
Unter /xmlrpc.php bietet WordPress von Hause aus eine Schnittstelle für die Verarbeitung von XML Dateien. Das RPC steht hier für Remote Procedure Call, was sich mit Aufruf einer entfernten Funktion übersetzen lässt. Andere Systeme, wie mobilen Applikationen oder externen Programmen, kommunizieren hierüber.
Als bestes Beispiel dient hier die von WordPress angebotene mobile WordPress App. Diese App ermöglicht es beispielsweise Medien hochzuladen und Beiträge zu publizieren.
Die App und eure WordPress Seite kommunizierten bis zur Version 3.5 komplett über die XML RPC Schnittstelle. Heutzutage passiert das durch die REST Schnittstelle. Die veraltete xmlrpc.php wurde hier also ersetzt.
Warum ist xmlrpc.php gefährlich?
Die WordPress XML RPC Schnittstelle bietet einen öffentlichen Zugang zu internen Funktionen. Das bietet direkt einen verlockenden Angriffsvektor in deinen WordPress Server hinein.
Die gängigsten und von mir beobachteten Angriffe sind hier DDoS Attacken und Brute Force Angriffe.
Bei einer DDoS Attacke benutzt der Angreifer die vorhandene XML RPC Schnittstelle, die eigentlich für die Registrierung von Pingbacks gedacht ist. Ein Pingback ist ein Benachrichtigungssystem, welches bei Verlinkungen in Blogs anderer Autoren den originalen Verfasser über die Verlinkung benachrichtigt.
Ein Angreifer kann hier eine große Anzahl von Pingbacks gleichzeitig senden, um deinen Server zu überlasten und deine Webseite unerreichbar zu machen.
Bei einem Brute Force Angriff wird beispielsweise die wp.getUsersBlogs Funktion der XML RPC Schnittstelle ausgenutzt, um sehr viele verschieden Nutzername und Passwort Kombinationen auszuprobieren. Ist diese Attacke erfolgreich, hat der Angreifer eine gültige Kombination aus Nutzernamen und Passwort und kann sich in der geknackten Webseite einloggen.
Soll ich xmlrpc.php deaktivieren?
Wenn keine Abhängigkeiten zu dieser Schnittstelle existieren, kann die Schnittstelle ohne Probleme deaktiviert werden. Die Schnittstelle existiert bislang noch, um eine Abwärtskompatibilität zu älteren Systemen zu garantieren. Deswegen kann das WordPress Team auch in künftigen Releases diese Schnittstelle nicht deaktivieren. Ansonsten könnten veraltete Systeme nicht mehr mit WordPress kommunizieren.
Wegen dieser Abhängigkeiten kann also nicht jeder die Schnittstelle deaktivieren. Hier helfen verschiedene Plugins wie Disable XML-RPC Pingback, die nur eine gewisse Funktionalitäten der Schnittstelle deaktivieren.
Wie entferne ich die Schnittstelle komplett?
Ein einfaches Löschen der Datei reicht hier nicht aus. Jedes kommende WordPress Update würde diese Datei neu erstellen. Die Schnittstelle kann am besten durch Konfiguration der Webserversoftware wie Apache oder NGINX entfernt werden. Wem das zu technisch ist, kann ohne Probleme ein Plugin wie Disable XML RPC API nutzen, um die Schnittstelle zu deaktivieren.
Alternativ existiert der folgende Filter, einen Beitrag zu Filtern habe ich ja bereits geschrieben. Dieser Filter deaktiviert die XML RPC Schnittstelle:
add_filter( 'xmlrpc_enabled', '__return_false' );Wer die Schnittstelle selbst deaktivieren möchte, folgt basierend auf dem genutzten Webserver folgende Schritte.
Entfernung unter Apache
In Apache erlaubt man den Zugriff auf Dateien über die .htaccess Datei. Um hier den Zugriff aud ie xmlrpc.php Datei zu verbieten, fügt man im Stammverzeichnis von WordPress folgenden Code in die .htaccess Datei ein:
<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>Entfernung unter NGINX
Unter NGINX steuert ein Serverblock den Zugriff. Hier muss innerhalb des server { [...] } Blocks folgender Code eingefügt werden:
location ~* ^/xmlrpc.php$ {
return 403;
}Alternativ könnt Ihr diesen Code auch in einer weiteren Konfigurationsdatei unter /etc/nginx/includes speichern und in jedem WordPress Serverblock diese Konfiguration mittels include /etc/nginx/includes/proxy.conf einbinden.
Das Ergebnis sollte wie folgt aussehen:
Fertig!
Nun solltet Ihr sicherer ohne XML RPC Schnittstelle unterwegs sein. Probiert zum Sichergehen einfach mal eure URL mit einem angehangenen `/xmlrpc.php` aus. Ihr solltet wie bei meiner Webseite eine 403 Fehlermeldung erhalten. Falls das nicht klappt: ich helfe gerne! Einfach einen Kommentar schreiben.