Sinu sait on aeglane, majutusteenuse pakkuja saadab hoiatusi ületatud limiitide kohta ja logid näitavad lõputut POST-päringute voogu failile xmlrpc.php. Kui haldate WordPressi, on see õudusunenägu tõenäoliselt tuttav.

Fail xmlrpc.php on iga WordPressi installatsiooni vaikne, kuid äärmiselt ohtlik element. See on asunud teie saidi juurkaustas alates CMS-i paigaldamisest ja on aastakümneid püsinud robotite ja ründajate lemmik sisenemispunktina. Wordfence'i 2024. aasta raporti kohaselt kuuluvad XML-RPC ründed WordPressi saitide viie peamise ohuteguri hulka ja 2026. aastal pole midagi muutunud.

Ometi pole enamikul saidiomanikest aimugi, miks see fail üldse olemas on või kuidas seda neutraliseerida. See juhend hõlmab nelja toimivat meetodit xmlrpc.php blokeerimiseks, alates kiirest .htaccess reeglist kuni CDN-taseme tulemüürini. Ei mingit udu, ainult testitud kood ja selgitused, millal iga meetodit kasutada.

💡 Kiirülevaade:

• Kontrollige, kas teie xmlrpc.php vastab POST-päringutele (tõenäoliselt vastab)
• Valige blokeerimismeetod: htaccess, kood failis functions.php, plugin või WAF
• Lisage blokeerimisreegel ja veenduge, et lõpp-punkt tagastab 403 Forbidden
• Kui kasutate Jetpacki, konfigureerige täieliku keelamise asemel sihitud tulemüürikaitse

Mis on xmlrpc.php ja miks see on endiselt WordPressis

XML-RPC (Remote Procedure Call) on protokoll, mis võimaldab välistel rakendustel WordPressiga suhelda. See lisati tuuma juba versioonis 1.5 ja toimis aastakümneid ainsa API-na kaugpublitseerimiseks: WordPressi mobiilirakendused, töölauakliendid nagu Windows Live Writer ja kolmandate osapoolte teenused sõltusid kõik sellest.

WordPress REST API väljalaskmisega versioonis 4.7 (2016) kadus vajadus XML-RPC järele suuresti. Kaasaegne REST API katab kõike, mida XML-RPC varem tegi, ning teeb seda turvalisemalt, kiiremini ja korraliku autentimisega nonce või OAuth kaudu.

Kuid fail xmlrpc.php asub endiselt iga WordPressi installatsiooni juurkaustas. Kaugpublitseerimine selle kaudu on vaikimisi keelatud, kuid lõpp-punkt võtab päringuid vastu. Avage lihtsalt brauseris yoursite.com/xmlrpc.php, et näha: "XML-RPC server accepts POST requests only". See tähendab, et lõpp-punkt on elus ja rünnakuks valmis.

Miks xmlrpc.php on ohtlik: peamised ründevektorid

Ründajad kasutavad xmlrpc.php peamiselt kahte tüüpi rünneteks ja mõlemad võivad teie saidi rivist välja viia.

Toore jõu rünne system.multicall kaudu. Meetod system.multicall võimaldab pakkida sadu autentimiskatseid ÜHTE HTTP-päringusse. Selle asemel, et paroole ükshaaval testida (nagu wp-login.php kaudu), saadab robot korraga massiivi kasutajanimedest ja paroolidest. Tavalised sisselogimise piiramise pluginad selliseid päringuid ei tuvasta, nende jaoks näeb see välja nagu "üks katse". Tulemus: ründajad käivad sekunditega läbi tuhandeid kombinatsioone, ilma et see blokeeringuid käivitaks.

Pingback DDoS. Pingback funktsioon võimaldab teisel saidil teavitada teie WordPressi sellele viitavast lingist. Ründaja saadab võltsitud pingback-päringu, asendades allika IP-aadressiks ohvri IP. Teie server kontrollib kohusetundlikult linki ja ründab pahaaimamatut sihtmärgiks olevat hosti. Korrutage see tuhandete ohustatud WordPressi installatsioonidega ja saate hajutatud DDoS-ründe, kus teie sait on kahurilihaks.

Majutusteenuse pakkujad jälgivad sellist väljaminevat liiklust ja võivad teie konto "DDoS-is osalemise" eest külmutada. Samal ajal raiskab teie server protsessori, mälu ja ribalaiust rämpspäringute teenindamisele.

Kontroll: kas teie xmlrpc.php vastab

Enne blokeerimist veenduge, et lõpp-punkt on tegelikult avatud. Avage brauseris:

1
https://yoursite.com/xmlrpc.php

Kui näete stringi "XML-RPC server accepts POST requests only", on lõpp-punkt elus ja ründajad saavad sellele päringuid saata. Kui saate 403 Forbidden või 404, siis kaitse juba töötab.

Teine meetod: saatke test-POST-päring terminali kaudu:

1
curl -X POST https://yoursite.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Vastus staatusega 200 OK ja XML-struktuur kinnitab: XML-RPC võtab päringuid vastu ja on ärakasutamiseks valmis.

1. Meetod: kiire blokeerimine.htaccess kaudu

Lihtsaim ja tõhusaim meetod on blokeerida juurdepääs failile veebiserveri tasemel. Päring lükatakse tagasi enne WordPressi jõudmist, mis säästab serveri ressursse ja töötab isegi siis, kui sait on koormuse all.

Lisage see oma juurkausta .htaccess faili (see, mis asub wp-config.php kõrval):

1
Block xmlrpc.php — protection from brute force and DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

Direktiiv Require all denied on Apache 2.4+ süntaks, mis kehtib kõigi kaasaegsete majutusteenuse pakkujate puhul. Pärast salvestamist avage xmlrpc.php brauseris; peaksite saama 403 Forbidden.

Kui teie server kasutab nginxi, lisage reegel virtuaalhosti konfiguratsiooni:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

Pärast nginxi konfiguratsiooni muutmist taaskäivitage server: sudo nginx -s reload.

See meetod töötab, kui te KINDLASTI ei vaja XML-RPC-d, ei Jetpacki, WordPressi mobiilirakenduste ega WooCommerce'i integratsioonide jaoks.

2. Meetod: keelamine functions.php kaudu (programmeeritav meetod)

Kui eelistate probleemi lahendada koodi, mitte serveri konfiguratsioonide tasemel, on siin kaks testitud koodijuppi teie aktiivse teema functions.php faili või Code Snippets jaoks.

XML-RPC täielik keelamine (WP 3.5+):

1
// Disable XML-RPC completely
2
add_filter('xmlrpc_enabled', '__return_false');

Üks rida ja WordPress lõpetab XML-RPC päringute töötlemise. Kui proovitakse xmlrpc.php poole pöörduda, saab klient veateate; fail ise jääb serverisse, kuid on funktsionaalselt surnud.

wp_head päiste puhastamine RSD ja WLW linkidest:

Isegi pärast XML-RPC WordPressi keelamist jätkab see kahe rea sisestamist <head> sektsiooni, mis paljastavad teavet teie saidi kohta:

1
// Remove RSD and WLW Manifest links from headers
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Konksud rsd_link ja wlwmanifest_link lisavad <head> sektsiooni sildid <link rel="EditURI"> ja <link rel="wlwmanifest">; need eksisteerivad ainult XML-RPC klientide jaoks ja neil pole 2026. aastal mingit praktilist eesmärki. Eemaldage need.

⚠️ Oluline: teema functions.php muudatused lähevad uuendamisel kaotsi. Kasutage püsivaks kohandatud koodi hoidmiseks alamteemat või Code Snippets pluginat.

3. Meetod: turvapluginad

Kui te ei soovi koodi puutuda, paigaldage plugin. Kolm testitud võimalust:

• Wordfence Security. Kõige populaarsem WordPressi tulemüür. Lisaks XML-RPC blokeerimisele pakub see pahavara skannerit, sisselogimise kaitset ja liikluse monitooringut. Wordfence'i seadetes → Login Security → märkige "Disable XML-RPC authentication".

• Disable XML-RPC-API. Kergekaaluline plugin, mis teeb täpselt ühte asja: haagib xmlrpc_enabled filtri ja keelab lõpp-punkti. Lisaseadeid pole; aktiveerige ja unustage.

• iThemes Security (Solid Security). Põhjalik plugin koos WordPress Tweaks mooduliga, kus XML-RPC keelatakse ühe linnukesega. See sulgeb ka teisi vektoreid: tabeli prefiksi muutmine, failiredaktori keelamine administraatorist, toore jõu rünnete kaitse.

Pärast ükskõik millise neist pluginatest aktiveerimist kontrollige alati, et xmlrpc.php tagastaks vea, mitte tervituse.

4. Meetod: tulemüüri taseme blokeering (Cloudflare / Sucuri)

Kõige võimsam kaitsetase on veebitulemüür, mis viskab pahatahtlikud päringud ära enne, kui need teie majutusse jõuavad.

Cloudflare** WAF.** Looge kohandatud reegel: URI Path väli sisaldab xmlrpc.php → tegevus Block. Päringud filtreeritakse Cloudflare'i võrgu tasemel (üle 330 kohalolekupunkti üle maailma); teie server ei näe neid kunagi. Tasuta pakett sisaldab 5 kohandatud reeglit, millest piisab. Boonus: Cloudflare näitab blokeeritud päringute statistikat ja te näete ründe ulatust oma silmaga.

Sucuri Website Firewall. Sarnane lähenemine: WAF reegel URI-l /xmlrpc.php. Sucuri pakub ka failide terviklikkuse monitooringut ja automaatset pahavara puhastamist.

Tulemüüri reegel töötab hästi koos .htaccess või programmeeritava keelamisega: tulemüür lõikab ära massilise rämpsu, samas kui kohalik blokeering on varuvariandiks juhuks, kui liiklus WAF-ist kuidagi mööda läheb.

Mida teha, kui kasutate Jetpacki

Automatticu Jetpack kasutab XML-RPC-d, et ühendada teie sait WordPress.com serveritega. Kui keelate xmlrpc.php täielikult, lakkab Jetpack töötamast: statistika, tellimused, piltide CDN, Related Posts moodul ja Jetpacki toore jõu rünnete kaitse lähevad korraga katki.

Lahendus: ärge tapke XML-RPC-d täielikult, vaid lubage valikuliselt päringuid Jetpacki serveritest:

• Jätke xmlrpc.php ligipääsetavaks (ÄRGE blokeerige .htaccess kaudu ja ÄRGE haakige xmlrpc_enabled filtrit).

• Konfigureerige Cloudflare WAF nii: lubage päringuid xmlrpc.php failile AINULT Automatticu IP-vahemikest (nimekirja uuendatakse Jetpacki dokumentatsioonis), blokeerige ülejäänud.

• Eemaldage vähemalt RSD ja WLW päised, kasutades 2. meetodi koodijuppi, et mitte paljastada lõpp-punkti <head> sektsioonis asjatult.

• Paigaldage Wordfence ja lubage toore jõu rünnete kaitse spetsiaalselt xmlrpc.php jaoks; see ei blokeeri legitiimseid Jetpacki päringuid, kuid lõikab ära paroolide äraarvamise katsed.

⁉️🤔 Korduma kippuvad küsimused

Kas ma võin lihtsalt xmlrpc.php faili serverist kustutada?

Võite, kuid see on halb tava. Järgmisel WordPressi uuendusel fail taastatakse ja olete jälle haavatav. Parem on blokeerida juurdepääs .htaccess kaudu või keelata funktsionaalsus koodis filtriga: efekt on sama, kuid tuumauuendused ei lõhu teie kaitset. Kui te faili siiski kustutasite, eemaldage kindlasti rsd_link funktsioonist wp_head, vastasel juhul saavad külastajad EditURI linki järgides 404 vea.

Kas XML-RPC keelamine lõhub WooCommerce'i?

Ei. WooCommerce on täielikult üle läinud WordPress REST API-le ega sõltu XML-RPC-st. Teie pood jätkab tööd muutusteta. Ainus erand on, kui kasutate iidset kohandatud lahendust, mis on seotud XML-RPC-ga, kuid selliseid pole praktiliselt enam alles.

Mis siis, kui minu majutusteenuse pakkuja juba blokeerib xmlrpc.php?

Kui teenusepakkuja on XML-RPC serveri tasemel juba keelanud, ei pea te midagi tegema; lõpp-punkt on ligipääsmatu. Kontrollige: avage xmlrpc.php; kui näete 403, siis kaitse töötab. Ainus, mida tasub lisada, on RSD ja WLW päiste eemaldamine functions.php kaudu, sest teenusepakkuja neid ei puuduta.

Kas ma pean XML-RPC keelama, kui kasutan hallatud WordPressi majutust?

Enamik hallatud majutusteenuseid (Kinsta, WP Engine, SiteGround) blokeerivad või piiravad rangelt xmlrpc.php platvormi tasemel. Kontrollige brauseri kaudu, kas lõpp-punkt on avatud. Kui blokeeritud, pole lisameetmeid vaja. Kui avatud, lisage .htaccess reegel: hallatud majutusteenused ei kirjuta seda üle.

Kuidas ma tean, kas minu saiti rünnatakse praegu xmlrpc.php kaudu?

Kolm märki: serveri koormuse järsk hüpe muutumatu liikluse juures, sajad identsed POST-päringud xmlrpc.php failile juurdepääsulogides ning mälu/protsessori limiidi vead teie majutusteenuse pakkujalt. Lülitage sisse monitooring (Wordfence → Live Traffic või Cloudflare → Security Events); näete ründe allikat ja ulatust reaalajas.

Kas xmlrpc.php tasub 2026. aastal keelata

Lühike vastus: jah, kui te ei kasuta Jetpacki ega avalda postitusi WordPressi mobiilirakenduse kaudu.

XML-RPC on pärand WordPress 1.5 ajastust. REST API on ammu selle koha üle võtnud ja xmlrpc.php ise on muutunud avatud ukseks toore jõu ja DDoS rünnetele. Selle sulgemine võtab viis minutit. Valige oma olukorrale sobiv meetod:

• Ei taha koodi puutuda: paigaldage Disable XML-RPC-API, kaks klõpsu.
• Omate juurdepääsu serverifailidele: lisage reegel .htaccess faili, serveri tase on usaldusväärsem.
• Eelistate puhast koodi: rakendage xmlrpc_enabled filter ja eemaldage päised kahe koodijupiga failis functions.php.
• Soovite maksimaalset kaitset: seadistage WAF reegel Cloudflare'is ja kombineerige see kohaliku blokeeringuga.

Pärast blokeerimist kontrollige alati, et xmlrpc.php tagastab 403 Forbidden, ja jälgige logisid vähemalt nädal aega; olete üllatunud, kui palju rämpsliiklust kaob. Samuti tellige WordPressi uuendused: ajalugu näitab, et vanad protokollid surevad aeglaselt ja uued XML-RPC haavatavused võivad ilmneda isegi pärast 2026. aastat.