XML-RPC in WordPress deaktivieren

XML-RPC ist ein Remote-Procedure-Call-Protokoll, das WordPress seit seinen fruehen Tagen unterstuetzt. Die Datei xmlrpc.php liegt im WordPress-Stammverzeichnis und stellt eine API bereit, ueber die externe Anwendungen mit deiner Seite kommunizieren koennen. Waehrend das im Jahr 2008 genuinerweise nuetzlich war, als es keine besseren Alternativen gab, hat die REST API (eingefuehrt in WordPress 4.7, Dezember 2016) es fuer legitime Anwendungsfaelle vollstaendig ersetzt. Heute wird XML-RPC hauptsaechlich von Angreifern fuer Brute-Force-Loginversuche und DDoS-Amplification-Angriffe ausgenutzt. Wenn du weder Jetpack noch ein Legacy-Mobilveroeffentlichungstool verwendest, solltest du es deaktivieren.

Die Geschichte von XML-RPC in WordPress

XML-RPC-Unterstuetzung ist seit Version 1.5 (2005) Teil von WordPress, war aber standardmaessig deaktiviert. Seitenbetreiber mussten es in den Einstellungen manuell aktivieren, wenn sie Desktop-Blogging-Clients wie Windows Live Writer oder MarsEdit nutzen wollten. In WordPress 3.5 (Dezember 2012) wurde XML-RPC standardmaessig aktiviert und die Moeglichkeit, es ueber die Admin-Oberflaeche zu deaktivieren, wurde entfernt. Die Begruendung war, dass mobile Apps und externe Dienste zunehmend darauf angewiesen waren. Diese Entscheidung bedeutete aber auch, dass jede WordPress-Installation nun einen offenen API-Endpunkt hatte, den Angreifer ins Visier nehmen konnten.

Mit WordPress 4.7 (Dezember 2016) wurde die REST API Teil des WordPress-Kerns. Die REST API bietet eine moderne, JSON-basierte Schnittstelle, die flexibler, besser dokumentiert und einfacher abzusichern ist als XML-RPC. Die WordPress-Mobile-App wechselte 2019 von XML-RPC zur REST API. Zu diesem Zeitpunkt war der einzige grosse Dienst, der XML-RPC noch benoetigte, Jetpack, und selbst Jetpack hat seine XML-RPC-Abhaengigkeit ueber die Zeit reduziert.

Wie der system.multicall Brute-Force-Angriff funktioniert

Der gefaehrlichste Aspekt von XML-RPC ist die system.multicall-Methode. Normale Brute-Force-Angriffe gegen die WordPress-Loginseite versuchen eine Benutzername/Passwort-Kombination pro HTTP-Anfrage. Rate-Limiting und Plugins wie Limit Login Attempts koennen diese Angriffe effektiv blockieren, weil jeder Versuch eine separate Anfrage erzeugt.

XML-RPCs system.multicall aendert die Gleichung komplett. Ein Angreifer kann Hunderte oder sogar Tausende von wp.getUsersBlogs-Authentifizierungsversuchen in eine einzige HTTP-Anfrage buendeln. Aus Sicht des Servers sieht das wie eine Anfrage aus. Aus Sicht des Angreifers hat er gerade 500 Passwoerter getestet. Login-Rate-Limiting-Plugins, die auf Anwendungsebene arbeiten, fangen diese Versuche oft nicht ab, weil sie nur eine eingehende Anfrage sehen.

So sieht ein Multicall-Brute-Force-Payload aus:

<?xml version="1.0"?>
<methodCall>
  <methodName>system.multicall</methodName>
  <params>
    <param>
      <value><array><data>
        <value><struct>
          <member>
            <name>methodName</name>
            <value><string>wp.getUsersBlogs</string></value>
          </member>
          <member>
            <name>params</name>
            <value><array><data>
              <value><string>admin</string></value>
              <value><string>password123</string></value>
            </data></array></value>
          </member>
        </struct></value>
        <!-- Hunderte weitere Versuche folgen -->
      </data></array></value>
    </param>
  </params>
</methodCall>

DDoS-Amplification ueber Pingbacks

Der zweite grosse Angriffsvektor ist die XML-RPC-Pingback-Funktion. Pingbacks sind Benachrichtigungen, die zwischen WordPress-Seiten gesendet werden, wenn eine Seite auf eine andere verlinkt. Angreifer missbrauchen dies, indem sie gefaelschte Pingback-Anfragen an Tausende von WordPress-Seiten senden, die alle auf eine einzelne Ziel-URL zeigen. Jede WordPress-Seite sendet dann eine Verifizierungsanfrage an das Ziel und verwandelt so Tausende von WordPress-Installationen effektiv in ein verteiltes Denial-of-Service-Botnetz (DDoS). Der Zielserver wird mit eingehenden Anfragen von legitimen WordPress-Seiten ueberflutet, was die Blockierung erschwert.

Testen, ob XML-RPC derzeit aktiviert ist

Bevor du Aenderungen vornimmst, pruefe, ob XML-RPC auf deiner Seite aktiv ist. Du kannst curl auf der Kommandozeile verwenden:

curl -X POST https://deineseite.de/xmlrpc.php   -H "Content-Type: text/xml"   -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Wenn XML-RPC aktiviert ist, erhaeltst du eine XML-Antwort mit allen verfuegbaren Methoden (typischerweise 80+ Methoden). Wenn es deaktiviert oder blockiert ist, erhaeltst du einen 403-Forbidden-Fehler, einen Connection-Refused-Fehler oder eine "XML-RPC server accepts POST requests only"-Meldung (je nachdem, wie es deaktiviert wurde).

Server-Logs auf XML-RPC-Angriffe pruefen

Vor dem Deaktivieren von XML-RPC lohnt es sich, deine Zugriffslogs zu pruefen, ob du bereits angegriffen wirst. Suche nach POST-Anfragen auf xmlrpc.php:

# Apache Access Log
grep "xmlrpc.php" /var/log/apache2/access.log | tail -50

# Nginx Access Log
grep "xmlrpc.php" /var/log/nginx/access.log | tail -50

# Anfragen pro IP zaehlen
grep "xmlrpc.php" /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Wenn du Hunderte oder Tausende von POST-Anfragen auf xmlrpc.php von verschiedenen IP-Adressen siehst, wird deine Seite aktiv angegriffen. Das ist extrem haeufig und ein weiterer Grund, den Endpunkt komplett zu deaktivieren.

Methode 1: Auf Webserver-Ebene blockieren (empfohlen)

XML-RPC auf Webserver-Ebene zu blockieren ist der effektivste Ansatz, weil die Anfrage abgelehnt wird, bevor PHP ueberhaupt geladen wird. Das spart Serverressourcen und ist der Ansatz, den du gegenueber PHP-Level-Filterung bevorzugen solltest.

Apache (.htaccess)

Fuege dies zu deiner .htaccess-Datei im WordPress-Stammverzeichnis hinzu:

# Gesamten Zugriff auf xmlrpc.php blockieren
<Files xmlrpc.php>
    Order deny,allow
    Deny from all
</Files>

Wenn du bestimmte IP-Adressen erlauben musst (zum Beispiel wenn du Jetpack nutzt), kannst du Ausnahmen hinzufuegen:

<Files xmlrpc.php>
    Order deny,allow
    Deny from all
    Allow from 122.248.245.244
    Allow from 54.217.201.243
</Files>

Nginx

Fuege dies innerhalb deines Server-Blocks in der Nginx-Konfiguration hinzu:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

Die Direktiven access_log off und log_not_found off verhindern, dass sich deine Log-Dateien mit blockierten XML-RPC-Versuchen fuellen, die bei stark angegriffenen Seiten auf Gigabytes anwachsen koennen.

Methode 2: Per WordPress-Filter deaktivieren (PHP-Ebene)

Wenn du keine Server-Konfigurationsdateien aendern kannst (haeufig bei Shared Hosting), kannst du XML-RPC auf PHP-Ebene deaktivieren. Fuege dies zur functions.php deines Themes oder besser noch zu einem benutzerdefinierten Must-Use-Plugin hinzu:

// XML-RPC vollstaendig deaktivieren
add_filter('xmlrpc_enabled', '__return_false');

// XML-RPC-Discovery-Link aus dem HTML-Head entfernen
remove_action('wp_head', 'rsd_link');

// X-Pingback HTTP-Header entfernen
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

Wichtig: Der xmlrpc_enabled-Filter deaktiviert nur authentifizierungsbasierte XML-RPC-Methoden. Die Datei xmlrpc.php wird trotzdem geladen, PHP wird trotzdem ausgefuehrt, und nicht-authentifizierte Methoden (wie Pingbacks) koennen weiterhin funktionieren. Deshalb ist das Blockieren auf Server-Ebene bevorzugt. Der Filter-Ansatz verbraucht trotzdem Serverressourcen fuer die Verarbeitung der Anfrage, bevor sie letztendlich abgelehnt wird.

Must-Use-Plugin erstellen (empfohlen statt functions.php)

Anstatt Code zur functions.php hinzuzufuegen (die bei Theme-Updates ueberschrieben wird), erstelle ein Must-Use-Plugin. Erstelle die Datei wp-content/mu-plugins/disable-xmlrpc.php:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Deaktiviert XML-RPC-Funktionalitaet vollstaendig
 */
add_filter('xmlrpc_enabled', '__return_false');
remove_action('wp_head', 'rsd_link');
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

Must-Use-Plugins werden vor regulaeren Plugins geladen und koennen nicht versehentlich ueber die Admin-Oberflaeche deaktiviert werden.

Methode 3: Sicherheits-Plugin-Konfiguration

Wenn du ein Sicherheits-Plugin wie Wordfence, Sucuri oder iThemes Security nutzt, bieten diese integrierte Optionen zum Deaktivieren von XML-RPC:

Wordfence: Gehe zu Wordfence > Alle Optionen > Brute-Force-Schutz. Die Firewall begrenzt automatisch die Rate von XML-RPC-Authentifizierungsversuchen. Fuer eine vollstaendige Blockierung nutze die oben genannte Server-Level-Methode.
iThemes Security: Gehe zu Sicherheit > Einstellungen > WordPress-Anpassungen. Schalte "XML-RPC deaktivieren" ein, um es komplett zu blockieren, oder waehle "Pingbacks deaktivieren", um nur den Pingback-Missbrauch zu blockieren, waehrend andere XML-RPC-Methoden funktional bleiben.
Sucuri: Die Sucuri Web Application Firewall (cloud-basiert) kann XML-RPC auf CDN-Ebene blockieren, bevor Anfragen deinen Server ueberhaupt erreichen.

Cloudflare-WAF-Regeln fuer XML-RPC-Schutz

Wenn du Cloudflare nutzt, kannst du eine WAF-Regel erstellen, die XML-RPC-Anfragen am Edge blockiert, bevor sie deinen Server ueberhaupt erreichen. Gehe zu Sicherheit > WAF > Benutzerdefinierte Regeln und erstelle eine Regel:

Regelname: XML-RPC blockieren
Ausdruck: (http.request.uri.path contains "/xmlrpc.php")
Aktion: Blockieren

Das ist die effizienteste Blockierungsmethode, weil Cloudflare die Anfrage an ihren Edge-Servern verarbeitet. Dein Origin-Server sieht den Traffic nie. Wenn du Jetpack erlauben musst, fuege eine Ausnahme fuer Automattics IP-Bereiche hinzu.

fail2ban-Konfiguration fuer XML-RPC-Brute-Force

Wenn du deinen eigenen Server verwaltest (VPS oder Dedicated), kannst du fail2ban verwenden, um IP-Adressen automatisch zu sperren, die wiederholt xmlrpc.php aufrufen. Erstelle eine Filter-Datei unter /etc/fail2ban/filter.d/wordpress-xmlrpc.conf:

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

Fuege dann ein Jail in /etc/fail2ban/jail.local hinzu:

[wordpress-xmlrpc]
enabled = true
port = http,https
filter = wordpress-xmlrpc
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 60
bantime = 3600

Diese Konfiguration sperrt jede IP-Adresse, die innerhalb von 60 Sekunden mehr als 5 Anfragen an xmlrpc.php stellt, fuer eine Stunde. Passe die Werte an deine Traffic-Muster an.

XML-RPC vs. REST API: Sicherheitsvergleich

Das Verstaendnis, warum die REST API sicherer ist, hilft zu erklaeren, warum XML-RPC ausgemustert werden sollte:

Authentifizierung: Die REST API unterstuetzt mehrere Authentifizierungsmethoden (Cookie-Auth, Application Passwords, OAuth) und hat integrierte Nonce-Verifizierung. XML-RPC sendet Anmeldedaten bei jeder Anfrage als Klartext im XML-Body.
Rate Limiting: REST-API-Anfragen koennen pro Endpunkt ratenbegrenzt werden. Die Multicall-Methode von XML-RPC macht Pro-Anfrage-Rate-Limiting unwirksam.
Berechtigungen: Die REST API respektiert WordPress-Capability-Checks und bietet granulare Permission-Callbacks fuer jeden Endpunkt. XML-RPC hat grobere Zugriffssteuerung.
Eingabevalidierung: REST-API-Endpunkte verwenden schemabasierte Eingabevalidierung. XML-RPC verlaesst sich auf die einzelnen Methodenimplementierungen fuer die Validierung.
Kein Multicall-Aequivalent: Die REST API hat keinen Batch-Endpunkt, der das Buendeln von Hunderten von Authentifizierungsversuchen in einer einzigen Anfrage ermoeglicht.

Pruefe vor dem Deaktivieren, ob du XML-RPC noch brauchst

Bevor du XML-RPC deaktivierst, stelle sicher, dass keiner deiner aktiven Dienste es benoetigt:

Jetpack: Einige Jetpack-Funktionen kommunizieren noch ueber XML-RPC. Wenn du Jetpack nutzt, teste deine Seite nach dem Deaktivieren von XML-RPC. Wenn Funktionen nicht mehr gehen, musst du moeglicherweise Automattics IP-Adressen erlauben oder die oben gezeigte Server-Level-Allowlist-Methode verwenden.
WordPress-Mobile-App: Aktuelle Versionen der WordPress-Mobile-App nutzen die REST API. Nur sehr alte Versionen (vor 2019) nutzten XML-RPC. Wenn deine App einwandfrei funktioniert, brauchst du XML-RPC nicht.
IFTTT- oder Zapier-Integrationen: Einige Legacy-Integrationen mit Automatisierungsdiensten nutzten XML-RPC. Pruefe, ob deine Automatisierungen nach dem Deaktivieren noch funktionieren.
Windows Live Writer oder andere Desktop-Editoren: Diese Legacy-Tools nutzten XML-RPC zum Veroeffentlichen. Wenn du noch einen nutzt, erwaege den Wechsel zum WordPress-Block-Editor oder einer REST-API-basierten Alternative.

Ueberpruefen, dass XML-RPC deaktiviert ist

Nach Anwendung deiner gewaehlten Methode stelle sicher, dass XML-RPC tatsaechlich blockiert ist:

# Sollte 403 Forbidden oder Connection Refused zurueckgeben
curl -s -o /dev/null -w "%{http_code}" -X POST   https://deineseite.de/xmlrpc.php   -H "Content-Type: text/xml"   -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Wenn du einen 403-Statuscode erhaeltst, ist XML-RPC blockiert. Wenn du immer noch eine 200 bekommst, funktioniert deine Blockierungsmethode nicht korrekt. Pruefe deine Konfiguration und stelle sicher, dass der Server neu gestartet wurde (bei Nginx) oder dass .htaccess-Aenderungen gelesen werden (bei Apache, stelle sicher, dass AllowOverride aktiviert ist).

Du kannst auch einen InspectWP-Scan durchfuehren. Der Sicherheitsbereich erkennt, ob XML-RPC erreichbar ist, und markiert es als potenzielles Risiko, wenn es auf Anfragen antwortet.