WordPress XML-RPC – stäng av det du förmodligen inte använder

· 3 min lästid · WordPress Säkerhet
WordPress XML-RPC – stäng av det du förmodligen inte använder

XML-RPC är ett gammalt protokoll som låter externa program kommunicera med din WordPress-installation. Det är påslaget som standard. De flesta som driver en vanlig företagswebbplats använder det inte – men angripare gör det.

Problemet är att xmlrpc.php tillåter upprepade inloggningsförsök i ett enda anrop. En angripare kan testa tusentals lösenord via en enda HTTP-request, vilket gör att traditionellt inloggningsskydd inte hjälper. Jag ser det här regelbundet när jag går igenom loggar för kunder.

Vad används XML-RPC egentligen till?

Historiskt var XML-RPC det enda sättet att publicera inlägg från externa appar – tänk gamla mobila bloggklienter och tjänster som IFTTT. Jetpack har länge använt det för sina funktioner, men nyare versioner av Jetpack använder WordPress REST API istället.

Du behöver förmodligen XML-RPC om du:

  • Använder Jetpack med äldre konfiguration
  • Publicerar via en extern app som förlitar sig på det (exempelvis vissa e-postbaserade publiceringsflöden)
  • Använder WordPress.com-appen för att hantera en självhostad installation

Annars: stäng av det.

Kolla om du faktiskt tar emot trafik

Innan du stänger av något är det värt att titta på loggarna. Be din hosting-leverantör om access-loggar och sök på xmlrpc.php. Ser du hundratals POST-anrop, ofta från samma IP-range eller med User-Agent-strängar som python-requests eller masscan – då är du redan ett aktivt mål.

Om du ser noll trafik, eller bara legitima anrop från Jetpack, vet du vad du har att göra med.

Tre sätt att stänga av det

1. Via .htaccess (snabbaste sättet för Apache)

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Detta blockerar all trafik till filen helt. Fördelen är att det inte påverkar WordPress-koden alls och sker på servernivå.

2. Via functions.php

add_filter('xmlrpc_enabled', '__return_false');

Detta inaktiverar XML-RPC i WordPress, men filen är fortfarande nåbar – angripare kan fortfarande skicka trafik dit och få ett felmeddelande tillbaka. Lite sämre än .htaccess-varianten.

3. Via ett plugin

Det finns enkla plugins som Disable XML-RPC som löser det med ett klick. Fungerar fint om du inte vill röra kod. Se bara till att det är aktivt underhållet – ett gammalt plugin löser inte ett säkerhetsproblem.

Om du använder Jetpack

Jetpack behöver faktiskt inte XML-RPC längre i moderna versioner. Men stäng inte av det blint om du kör Jetpack – testa istället i en staging-miljö innan du gör ändringen i produktion. Om Jetpack-funktioner slutar fungera vet du att det fortfarande finns ett beroende.

Ett bra alternativ är att blockera XML-RPC för alla utom Jetpacks servrar via IP-vitlistning i .htaccess. Det är lite mer jobb men bevarar funktionaliteten.

Det räcker inte att bara stänga av det

XML-RPC är ett av flera inloggningsrelaterade angreppsvektorer. Även med xmlrpc.php avstängt kan wp-login.php utsättas för brute force. Det hör ihop med bredare åtgärder – tvåfaktorsautentisering, inloggningsbegränsningar och bra lösenordspolicy.

Har du aldrig gått igenom din WordPress-installations exponerade endpoints systematiskt är ett gratis webbtest ett enkelt sätt att se var du står just nu.

Hur mår din webb?

Kör ett gratis test och se hur din webb presterar inom SEO, säkerhet, prestanda och tillgänglighet, på under en minut.

Testa gratis

Inget konto krävs

Få fler tips som dessa

Prenumerera på vårt nyhetsbrev, vi delar tips om webbunderhåll, säkerhet och prestanda.