Hoe u XML-RPC uitschakelt in WordPress

XML-RPC is een remote procedure call-protocol dat WordPress sinds zijn beginjaren ondersteunt. Het bestand xmlrpc.php bevindt zich in de rootmap van uw WordPress en biedt een API waarmee externe applicaties met uw site kunnen communiceren. Hoewel dit in 2008 oprecht nuttig was toen er nog geen betere alternatieven waren, heeft de REST API (geïntroduceerd in WordPress 4.7, december 2016) deze volledig vervangen voor legitieme gebruiksscenario's. Tegenwoordig wordt XML-RPC voornamelijk uitgebuit door aanvallers voor brute force-inlogpogingen en DDoS-versterkingsaanvallen. Als u Jetpack of een verouderde mobiele publicatietool niet gebruikt, moet u het uitschakelen.

De geschiedenis van XML-RPC in WordPress

XML-RPC-ondersteuning maakt sinds versie 1.5 (2005) deel uit van WordPress, maar het was standaard uitgeschakeld. Site-eigenaren moesten het handmatig inschakelen in Instellingen als ze desktop-blogclients zoals Windows Live Writer of MarsEdit wilden gebruiken. In WordPress 3.5 (december 2012) werd de XML-RPC-interface standaard ingeschakeld en de optie om deze via de admin-UI uit te schakelen werd verwijderd. De redenering was dat mobiele apps en externe diensten er steeds meer op vertrouwden. Deze beslissing betekende echter ook dat elke WordPress-installatie nu een open API-eindpunt had dat aanvallers konden targeten.

Met WordPress 4.7 (december 2016) werd de REST API onderdeel van WordPress core. De REST API biedt een moderne, op JSON gebaseerde interface die flexibeler, beter gedocumenteerd en gemakkelijker te beveiligen is dan XML-RPC. De WordPress-mobiele app schakelde in 2019 over van XML-RPC naar de REST API. Op dat moment was de enige grote dienst die nog XML-RPC vereiste Jetpack, en zelfs Jetpack heeft zijn afhankelijkheid van XML-RPC in de loop der tijd verminderd.

Hoe de system.multicall brute force-aanval werkt

Het gevaarlijkste aspect van XML-RPC is de methode system.multicall. Normale brute force-aanvallen op de WordPress-loginpagina proberen één gebruikersnaam/wachtwoordcombinatie per HTTP-verzoek. Rate limiting en plug-ins zoals Limit Login Attempts kunnen deze aanvallen effectief blokkeren omdat elke poging een apart verzoek genereert.

De system.multicall van XML-RPC verandert de vergelijking volledig. Een aanvaller kan honderden of zelfs duizenden wp.getUsersBlogs-authenticatiepogingen bundelen in één HTTP-verzoek. Vanuit het perspectief van de server lijkt dit één verzoek. Vanuit het perspectief van de aanvaller hebben ze net 500 wachtwoorden getest. Inlog-rate limiting plug-ins die op applicatieniveau werken, vangen deze pogingen vaak niet op omdat ze slechts één inkomend verzoek zien.

Zo ziet een multicall brute force-payload eruit:

<?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>
        <!-- nog honderden pogingen volgen -->
      </data></array></value>
    </param>
  </params>
</methodCall>

DDoS-versterking via pingbacks

De tweede grote aanvalsvector is de XML-RPC pingback-functie. Pingbacks zijn meldingen die tussen WordPress-sites worden verzonden wanneer de ene site naar een andere linkt. Aanvallers misbruiken dit door vervalste pingback-verzoeken naar duizenden WordPress-sites te sturen, allemaal gericht op één enkele doel-URL. Elke WordPress-site stuurt vervolgens een verificatieverzoek naar het doel, waardoor duizenden WordPress-installaties effectief worden omgevormd tot een gedistribueerd denial-of-service (DDoS)-botnet. De doelserver wordt overspoeld met inkomende verzoeken van legitieme WordPress-sites, waardoor het moeilijk te blokkeren is.

Hoe te testen of XML-RPC momenteel is ingeschakeld

Controleer voordat u wijzigingen aanbrengt of XML-RPC actief is op uw site. U kunt curl gebruiken vanaf de commandoregel:

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

Als XML-RPC is ingeschakeld, ontvangt u een XML-respons met alle beschikbare methoden (meestal 80+ methoden). Als het is uitgeschakeld of geblokkeerd, krijgt u een 403 Forbidden-fout, een connection refused-fout, of een melding "XML-RPC server accepts POST requests only" (afhankelijk van hoe het is uitgeschakeld).

Serverlogboeken controleren op XML-RPC-aanvallen

Voordat u XML-RPC uitschakelt, is het de moeite waard om uw access logs te controleren om te zien of u al wordt aangevallen. Zoek naar POST-verzoeken naar 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

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

Als u honderden of duizenden POST-verzoeken naar xmlrpc.php ziet vanuit verschillende IP-adressen, wordt uw site actief getarget. Dit komt extreem vaak voor en is nog een reden om het eindpunt volledig uit te schakelen.

Methode 1: Blokkeren op webserverniveau (aanbevolen)

XML-RPC blokkeren op webserverniveau is de meest effectieve aanpak omdat het verzoek wordt afgewezen voordat PHP überhaupt wordt geladen. Dit bespaart serverbronnen en is de aanpak die u boven filteren op PHP-niveau zou moeten verkiezen.

Apache (.htaccess)

Voeg dit toe aan uw .htaccess-bestand in de WordPress-rootmap:

# Blokkeer alle toegang tot xmlrpc.php
<Files xmlrpc.php>
    Order deny,allow
    Deny from all
</Files>

Als u specifieke IP-adressen moet toestaan (bijvoorbeeld als u Jetpack gebruikt), kunt u uitzonderingen toevoegen:

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

Nginx

Voeg dit toe binnen uw server block in de Nginx-configuratie:

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

De directives access_log off en log_not_found off voorkomen dat uw logbestanden vol raken met geblokkeerde XML-RPC-pogingen, die op zwaar getargete sites kunnen uitgroeien tot gigabytes.

Methode 2: Uitschakelen via WordPress-filter (PHP-niveau)

Als u serverconfiguratiebestanden niet kunt wijzigen (gebruikelijk bij shared hosting), kunt u XML-RPC uitschakelen op PHP-niveau. Voeg dit toe aan de functions.php van uw thema of, beter nog, aan een aangepaste must-use plug-in:

// XML-RPC volledig uitschakelen
add_filter('xmlrpc_enabled', '__return_false');

// Verwijder de XML-RPC discovery-link uit de HTML head
remove_action('wp_head', 'rsd_link');

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

Belangrijk: Het filter xmlrpc_enabled schakelt alleen op authenticatie gebaseerde XML-RPC-methoden uit. Het bestand xmlrpc.php wordt nog steeds geladen, PHP wordt nog steeds uitgevoerd, en niet-geauthenticeerde methoden (zoals pingbacks) kunnen nog steeds werken. Daarom heeft blokkeren op serverniveau de voorkeur. De filteraanpak verbruikt nog steeds serverbronnen voor het verwerken van het verzoek voordat het uiteindelijk wordt afgewezen.

Een must-use plug-in maken (aanbevolen boven functions.php)

In plaats van code toe te voegen aan functions.php (die wordt overschreven tijdens thema-updates), maakt u een must-use plug-in. Maak het bestand wp-content/mu-plugins/disable-xmlrpc.php aan:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Schakelt XML-RPC-functionaliteit volledig uit
 */
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 plug-ins worden vóór reguliere plug-ins geladen en kunnen niet per ongeluk via de admin-interface worden gedeactiveerd.

Methode 3: Configuratie van een beveiligingsplug-in

Als u een beveiligingsplug-in zoals Wordfence, Sucuri of iThemes Security gebruikt, bieden deze ingebouwde opties om XML-RPC uit te schakelen:

Wordfence: Ga naar Wordfence > All Options > Brute Force Protection. De firewall beperkt automatisch het tempo van XML-RPC-authenticatiepogingen. Gebruik voor volledige blokkering de bovenstaande methode op serverniveau.
iThemes Security: Ga naar Security > Settings > WordPress Tweaks. Schakel "Disable XML-RPC" in om het volledig te blokkeren, of selecteer "Disable Pingbacks" om alleen de pingback-misbruikvector te blokkeren terwijl andere XML-RPC-methoden functioneel blijven.
Sucuri: De Sucuri Web Application Firewall (cloud-gebaseerd) kan XML-RPC blokkeren op CDN-niveau, voordat verzoeken zelfs uw server bereiken.

Cloudflare WAF-regels voor XML-RPC-bescherming

Als u Cloudflare gebruikt, kunt u een WAF-regel maken die XML-RPC-verzoeken aan de edge blokkeert, voordat ze überhaupt uw server bereiken. Ga naar Security > WAF > Custom Rules en maak een regel:

Regelnaam: Block XML-RPC
Expressie: (http.request.uri.path contains "/xmlrpc.php")
Actie: Block

Dit is de meest efficiënte blokkeringsmethode omdat Cloudflare het verzoek afhandelt op hun edge-servers. Uw origin-server ziet het verkeer nooit. Als u Jetpack moet toestaan, voeg dan een uitzondering toe voor de IP-bereiken van Automattic.

fail2ban-configuratie voor XML-RPC brute force

Als u uw eigen server beheert (VPS of dedicated), kunt u fail2ban gebruiken om automatisch IP-adressen te bannen die herhaaldelijk xmlrpc.php benaderen. Maak een filterbestand aan op /etc/fail2ban/filter.d/wordpress-xmlrpc.conf:

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

Voeg vervolgens een jail toe in /etc/fail2ban/jail.local:

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

Deze configuratie bant elk IP-adres dat binnen 60 seconden meer dan 5 verzoeken naar xmlrpc.php doet en blokkeert deze gedurende een uur. Pas de waarden aan op basis van uw verkeerspatronen.

XML-RPC vs. REST API: beveiligingsvergelijking

Begrijpen waarom de REST API veiliger is, helpt verklaren waarom XML-RPC met pensioen moet:

Authenticatie: De REST API ondersteunt meerdere authenticatiemethoden (cookie auth, application passwords, OAuth) en heeft ingebouwde nonce-verificatie. XML-RPC verzendt referenties in platte tekst binnen het XML-lichaam bij elk verzoek.
Rate limiting: REST API-verzoeken kunnen per eindpunt worden gerate-limit. De multicall-methode van XML-RPC maakt rate limiting per verzoek ineffectief.
Permissies: De REST API respecteert WordPress capability-controles en biedt gedetailleerde permissie-callbacks voor elk eindpunt. XML-RPC heeft grovere toegangscontrole.
Invoervalidatie: REST API-eindpunten gebruiken op schema gebaseerde invoervalidatie. XML-RPC vertrouwt op de individuele methode-implementaties voor validatie.
Geen multicall-equivalent: De REST API heeft geen batch-eindpunt waarmee honderden authenticatiepogingen in één verzoek kunnen worden gebundeld.

Controleer of u XML-RPC nog nodig hebt voordat u het uitschakelt

Voordat u XML-RPC uitschakelt, controleert u of geen van uw actieve diensten dit vereist:

Jetpack: Sommige Jetpack-functies communiceren nog steeds via XML-RPC. Als u Jetpack gebruikt, test uw site na het uitschakelen van XML-RPC. Als functies kapot gaan, moet u mogelijk de IP-adressen van Automattic toestaan of de hierboven getoonde server-niveau allow-list-methode gebruiken.
WordPress mobiele app: Huidige versies van de WordPress mobiele app gebruiken de REST API. Alleen zeer oude versies (vóór 2019) gebruikten XML-RPC. Als uw app prima werkt, hebt u XML-RPC niet nodig.
IFTTT- of Zapier-integraties: Sommige verouderde integraties met automatiseringsdiensten gebruikten XML-RPC. Controleer of uw automatiseringen nog werken na het uitschakelen.
Windows Live Writer of andere desktopeditors: Deze verouderde tools gebruikten XML-RPC voor publicatie. Als u er nog een gebruikt, overweeg dan over te stappen op de WordPress-blokeditor of een op REST API gebaseerd alternatief.

Verifiëren dat XML-RPC is uitgeschakeld

Na het toepassen van uw gekozen methode, verifieer dat XML-RPC daadwerkelijk is geblokkeerd:

# Zou 403 Forbidden of connection refused moeten retourneren
curl -s -o /dev/null -w "%{http_code}" -X POST   https://yoursite.com/xmlrpc.php   -H "Content-Type: text/xml"   -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Als u een 403-statuscode krijgt, is XML-RPC geblokkeerd. Als u nog steeds een 200 krijgt, werkt uw blokkeringsmethode niet correct. Controleer uw configuratie en zorg ervoor dat de server opnieuw is gestart (voor Nginx) of dat .htaccess-wijzigingen worden gelezen (voor Apache, zorg ervoor dat AllowOverride is ingeschakeld).

U kunt ook een InspectWP-scan uitvoeren. De beveiligingssectie detecteert of XML-RPC toegankelijk is en markeert dit als een potentieel risico als het op verzoeken reageert.