In vrijwel elk beveiligingsrapport van een WordPress-site duikt hetzelfde bestand op: xmlrpc.php. Het staat in de hoofdmap van elke installatie, u heeft het nooit bewust gebruikt, en toch is het een van de meest bezochte bestanden op uw server. Niet door bezoekers, maar door geautomatiseerde programma’s die er iets mee willen.
De vraag die klanten ons dan stellen, is of ze XML-RPC kunnen uitschakelen zonder dat er iets kapotgaat. Voor de meeste websites is het antwoord ja, en is het bovendien verstandig. In dit artikel leggen wij uit wat het bestand doet, wie het nog wél nodig heeft, en hoe u het op drie manieren uitzet, van eenvoudig tot grondig.
Wat XML-RPC is en waarom het er nog is
XML-RPC is een koppeling uit de begintijd van WordPress. Het maakte het mogelijk om van buitenaf met uw website te praten: een bericht plaatsen vanuit een schrijfprogramma op uw computer, een pingback versturen naar een andere blog, of de mobiele WordPress-app gebruiken. Dat was handig in een tijd waarin de website zelf nog geen goede alternatieven had.
Sinds enkele jaren heeft WordPress een moderne opvolger, de REST API, en gebruiken de meeste apps en diensten die. XML-RPC is blijven bestaan voor oudere koppelingen die er nog op leunen. Het staat standaard aan, ook op een gloednieuwe installatie, en dat is precies het probleem: het is een openstaande deur waar bijna niemand meer doorheen hoeft.
Waarom XML-RPC uitschakelen de moeite waard is
Er zijn twee redenen waarom aanvallers dol zijn op dit bestand.
De eerste is inloggen op grote schaal. XML-RPC kent een functie waarmee meerdere opdrachten in één verzoek worden verpakt. Een aanvaller kan daarmee honderden wachtwoorden tegelijk proberen in één enkel serververzoek. Een gewone limiet op inlogpogingen ziet dat als één poging, terwijl er in werkelijkheid honderden plaatsvinden. Dat maakt het bestand het favoriete gereedschap bij een brute-force-aanval op uw loginpagina.
De tweede reden is misbruik van pingbacks. Via XML-RPC kan een aanvaller uw website opdracht geven een ander adres te bezoeken. Met duizenden WordPress-sites tegelijk wordt zo een aanval op een derde partij uitgevoerd, en uw server doet ongevraagd mee. U merkt daar weinig van, behalve dat de site trager wordt en uw hostingpartij misschien een klacht ontvangt.
Zelfs als er niets lukt, kost het verwerken van al die verzoeken serverkracht. In onze ervaring is het uitschakelen van XML-RPC op drukbezochte aanvalsdoelen soms al merkbaar in de laadtijd van het beheergedeelte.
Wie het nog wél nodig heeft
Schakel niets uit voordat u dit lijstje heeft nagelopen. XML-RPC is mogelijk nog in gebruik als u:
- de Jetpack-plugin gebruikt (Jetpack communiceert deels via XML-RPC met de servers van WordPress.com);
- een oudere versie van de WordPress-app op uw telefoon gebruikt om te publiceren;
- berichten plaatst vanuit een extern schrijfprogramma of via een automatiseringsdienst die specifiek XML-RPC vereist;
- een koppeling heeft met een oud CRM of uitgeefsysteem dat nooit is bijgewerkt.
Twijfelt u? Kijk in de toegangslogboeken van uw server wie xmlrpc.php benadert. Ziet u alleen onbekende IP-adressen uit alle windstreken, dan gebruikt u het zelf niet. Ziet u een vast adres dat bij een dienst hoort die u kent, dan moet u eerst uitzoeken wat daar achter zit.
Stappenplan: drie manieren om het uit te zetten
Maak eerst een back-up, ook voor zo’n kleine wijziging. Kies daarna de methode die bij u past.
1. Via een plugin (eenvoudigst)
- Installeer een kleine plugin die XML-RPC uitschakelt, of gebruik de optie in uw bestaande beveiligingsplugin. Vrijwel elke beveiligingsplugin heeft er een instelling voor.
- Zet de optie aan en sla op.
- Test: open in uw browser uwdomein.nl/xmlrpc.php. Ziet u een foutmelding of een lege pagina in plaats van de tekst “XML-RPC server accepts POST requests only”, dan werkt het.
2. Via een filter in uw thema of een eigen plugin
Voor wie liever geen extra plugin wil, volstaat één regel code. Voeg in het bestand functions.php van uw child-thema, of beter nog in een kleine eigen plugin, het volgende toe: add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );. WordPress weigert dan alle XML-RPC-verzoeken. Let op: het bestand blijft bereikbaar en de server verwerkt het verzoek nog steeds gedeeltelijk, dus dit is minder grondig dan de derde methode.
3. Op serverniveau (grondigst)
De beste oplossing is de toegang tot het bestand blokkeren voordat WordPress überhaupt wordt geladen. Op een Apache-server voegt u aan het .htaccess-bestand een regel toe die verzoeken naar xmlrpc.php weigert; op Nginx doet u hetzelfde in de serverconfiguratie. Het verzoek stopt dan bij de webserver en kost vrijwel geen kracht meer. Bent u niet vertrouwd met deze bestanden, vraag dit dan aan uw hostingpartij; bij de meeste is het een kwestie van minuten. Als u Jetpack gebruikt, kunt u hier een uitzondering maken voor de IP-adressen van WordPress.com.
Na het uitschakelen: wat u controleert
Loop de dagen erna kort na of alles nog werkt. Publiceer een testbericht vanuit de app als u die gebruikt, controleer of Jetpack-functies nog reageren en kijk of geautomatiseerde koppelingen nog data aanleveren. Werkt iets niet meer, dan weet u meteen waar het aan ligt en kunt u de wijziging terugdraaien of een uitzondering maken.
Het uitschakelen van XML-RPC is één van de maatregelen die wij standaard meenemen in de inrichting van websitebeveiliging voor klanten; het hoort in hetzelfde rijtje als een firewall, een limiet op inlogpogingen en tweestapsverificatie. Geen van die maatregelen is op zichzelf voldoende, maar samen sluiten ze de deuren die aanvallers het vaakst proberen. Wat een firewall voor uw website daarbij wel en niet doet, leest u in een apart artikel.
Conclusie
Gebruikt u geen Jetpack, geen oude app en geen koppeling die er specifiek om vraagt, dan is XML-RPC uitschakelen een kleine moeite met een duidelijk voordeel: minder aanvalsverkeer, minder serverbelasting en één ingang minder om zich zorgen over te maken. Doe het via de serverconfiguratie als dat kan, via een plugin als dat makkelijker is, en controleer daarna een week lang of alles blijft werken.
