Iga WordPressi saidi juurkaustas on „vaikiv" fail, mille enamik omanikke avastab alles pärast rünnet. Selle nimi on xmlrpc.php. Fail ise pole pahatahtlik: WordPress hoiatab ausalt, et see on kaugsuhtluse liides. Kuid just selle faili kaudu on aastaid brute-force'itud paroole, saadetud rämpspostist pingback'e ja suunatud DDoS-liiklust.

Wordfence'i 2024. aasta andmete kohaselt on XML-RPC kaudu toimuvad ründed WordPressi saitide vastu suunatud viie peamise ründevektori hulgas. Üksainus system.multicall päring võimaldab ründajal testida sadu paroole korraga, mitte ühte nagu sisselogimisvormi kaudu. Majutusteenuse pakkujad registreerivad keskmisel saidil igakuiselt miljoneid selliseid katseid.

Mõistame, miks seda faili üldse vaja on, kes peaks seda alles hoidma, ja mis kõige tähtsam, näitame viit viisi xmlrpc.php keelamiseks või turvaliseks blokeerimiseks, alates ühe klõpsuga pluginast kuni sihitud .htaccess muudatusteni.

💡 Kiirülevaade:

• Õpi, mis on xmlrpc.php ja millised WordPressi funktsioonid sellest sõltuvad (pingback, mobiilirakendus, Jetpack)
• Hinda tegelikke riske: brute-force'i võimendamine, pingback DDoS ja kataloogide skannimine robotite poolt
• Vali õige kaitsemeetod: pluginaga keelamine, blokeerimine .htaccess kaudu, juurdepääsu sulgemine veebiserveri tasemel või faili eemaldamine
• Sea üles monitooring: kuidas veenduda, et xmlrpc.php ei vasta enam päringutele

Mis on xmlrpc.php ja millised WordPressi funktsioonid sellest sõltuvad

XML-RPC on kaugprotseduurikutse protokoll, mis töötab üle HTTP ja edastab andmeid XML-vormingus. Tehnoloogia ilmus 1990ndate lõpus, ammu enne REST API-t, ja WordPress päris selle oma algusaegadel. Fail xmlrpc.php saidi juurkaustas võtab vastu XML-päringuid, töötleb neid ja tagastab vastuse, näiteks avaldab postituse, laadib üles meediafaili või kontrollib kasutaja õigusi.

Praktikas töötavad xmlrpc.php kaudu mitmed stsenaariumid:

• Pingback'id ja trackback'id. Kui keegi lingib sinu postitusele, saadab tema sait XML-RPC päringu koos teavitusega. Sinu WordPress kontrollib linki ja kui see on ehtne, lisab pingback'i kommentaaridesse.

• Kaugpublitseerimine. Rakendused nagu vana Windows Live Writer või töölauakliendid (TextMate, MarsEdit) kasutasid XML-RPC-d postituste kirjutamiseks ja saatmiseks ilma administraatoripaneeli sisenemata.

• WordPressi mobiilirakendus. Ametlik iOS-i ja Androidi rakendus tugines pikka aega XML-RPC-le, kuigi liigub nüüd üha enam REST API-le.

• Integratsioonid. Teenused nagu Jetpack (osa selle funktsionaalsusest), IFTTT ja mõned SEO tööriistad kasutavad endiselt XML-RPC-d saidiga ühenduse loomiseks.

WordPress REST API väljalaskmisega versioonis 4.7 (detsember 2016) liikus enamik kaasaegseid integratsioone uuele protokollile. REST API on kiirem, töötab XML-i asemel JSON-iga ja on paremini dokumenteeritud. Sellegipoolest sisaldab WordPress iga installatsiooni puhul tagasiühilduvuse tagamiseks endiselt faili xmlrpc.php.

Oluline nüanss: alates WordPress 2.6-st (aastal 2008) on XML-RPC kaudu kaugpublitseerimise funktsionaalsus vaikimisi keelatud. Selle lubamiseks tuleb selgesõnaliselt märkida ruut jaotises „Seaded → Kirjutamine". Samal ajal jätkavad pingback'id ja trackback'id tööd.

Kuidas on xmlrpc.php ohtlik: kolm peamist ründevektorit

WordPressi arendajad on xmlrpc.php-d parandanud rohkem kui korra. Versioonis 2.1.2 võis autenditud kasutaja, kellel on „kaasautori" õigused, piirangutest mööda minnes postituse avaldada. Versioonis 2.3.1 avastati XML-RPC kaudu infoleke. Mõlemad augud suleti kiiresti, kuid protokoll ise jäi arhitektuurselt haavatavaks kolmele ründeklassile, mis on endiselt aktuaalsed aastal 2026.

Brute-force'i võimendamine system.multicall kaudu

Peamine probleem on system.multicall meetod. See võimaldab pakkida mitu wp.getUsersBlogs väljakutset ühte HTTP-päringusse. Iga väljakutse kontrollib paari „kasutajanimi + parool". Seega teeb ründaja ühe päringu kohta ühe katse asemel sadu. Cloudflare on registreerinud kümnete tuhandete selliste päringute tippe tunnis ühe saidi kohta.

Tavaline sisselogimisvorm wp-login.php on piiratud ühe sisselogimiskatsega korraga ja on kergesti kaitstav pluginaga nagu Wordfence või Limit Login Attempts. xmlrpc.php läheb kõigist neist piirajatest mööda, sest see töötab läbi teise lõpp-punkti.

Pingback DDoS

Pingback'i funktsioon on loodud kahjutu teavitusena. Kuid ründaja võib saata võltsitud pingback'i päringuid sadade saitide nimel ja sinu server hakkab iga „linki" kontrollima, koormates protsessorit, võrku ja andmebaasi. Piisava mastaabi korral sait langeb. Sucuri nimetab oma 2023. aasta raportis pingback-ründeid üheks levinumaks WordPressi vastaseks DDoS-vektoriks.

Kataloogide skannimine robotite poolt

Robotid otsivad xmlrpc.php-d mitte ainult juurkaustast, vaid ka väljamõeldud alamkataloogidest nagu /2026/01/xmlrpc.php ja /blog/xmlrpc.php. Iga selline päring tagastab 404 ja raiskab serveri ressursse. Isegi kui rünne ebaõnnestus, aeglustavad kümned tuhanded rämpspäringud saiti ja ummistavad logid. Praktikas näevad omanikud, kuidas cPanel'i graafikud lähevad punasesse tsooni ja põhjuseks on just robotite poolne xmlrpc.php skannimine.

5 Viisi xmlrpc.php keelamiseks või turvamiseks

Allpool on viis meetodit, alates kõige lihtsamast kuni kõige radikaalsemani. Vali vastavalt oma olukorrale: kas kasutad mobiilirakendust, kas vajad pingback'e, milline on sinu majutus.

1. Keela pluginaga

Kõige turvalisem tee neile, kes ei taha koodi puutuda. Paigalda plugin ja see blokeerib juurdepääsu xmlrpc.php-le WordPressi tasemel, enne kui päringu töötlemine algab.

Plussid: pole vaja muuta .htaccess-i ega functions.php-d, lihtne tagasi lülitada. Miinused: lisab administraatoripaneelile veel ühe plugina, kaitse eemaldatakse deaktiveerimisel.

Paar tõestatud varianti:

• Disable XML-RPC, minimalistlik, üks toiming: aktiveeritud ja juurdepääs on suletud. Seadeid pole.
• Wordfence Security, kõikehõlmav tulemüür, milles XML-RPC keelamine on vaid üks funktsioonidest. Sobib, kui juba kasutad Wordfence'i või plaanid seda paigaldada.

2. Blokeeri.htaccess kaudu

Kui töötad Apache'i serveriga, võimaldab .htaccess fail saidi juurkaustas blokeerida juurdepääsu enne, kui päring WordPressini jõuab. See vähendab koormust: Apache tagastab kohe 403 Forbidden, ilma PHP-d käivitamata.

Lisa järgmine plokk .htaccess-i faili algusesse, enne # BEGIN WordPress:

1
<IfModule mod_alias.c>
2
    RedirectMatch 403 /(.*)/xmlrpc.php$
3
</IfModule>

RedirectMatch 403 direktiiv püüab kinni kõik URL-id, mis lõpevad /xmlrpc.php-ga, sealhulgas alamkataloogid nagu /2025/06/xmlrpc.php, ja tagastab koheselt 403.

Plussid: ei puuduta WordPressi koodi, töötab enne PHP laadimist, säästab ressursse. Miinused: vaja .htaccess-i käsitsi muuta, majutuse või teema vahetamisel võib fail üle kirjutatud saada.

Oluline: enne .htaccess-i muutmist tee varukoopia. Viga .htaccess-i süntaksis võib saidi maha võtta (500 Internal Server Error).

3. Eemalda lingid functions.php kaudu

See meetod ei blokeeri faili ennast, vaid eemaldab HTML-lingid xmlrpc.php-le ja wlwmanifest.xml-ile saidi <head> sektsioonist. Kasu on vähenenud nähtavuses: HTML-i parsivad robotid ei näe otsest viidet XML-RPC lõpp-punktile.

Lisa aktiivse teema functions.php-sse (või Code Snippets plugina kaudu):

1
remove_action('wp_head', 'rsd_link');
2
remove_action('wp_head', 'wlwmanifest_link');

rsd_link konks väljastab <link rel="EditURI">, lingi xmlrpc.php-le Really Simple Discovery klientide jaoks. wlwmanifest_link konks on Windows Live Writeri jaoks (ammu toetamata, kuid WordPress väljastab seda endiselt).

Plussid: puhas <head> ilma rämpslinkideta. Miinused: xmlrpc.php jääb füüsiliselt otse URL-i kaudu kättesaadavaks, see pole blokeerimine, vaid maskeerimine.

4. Sule juurdepääs WAF-i või Cloudflare'i kaudu

Veebirakenduste tulemüür blokeerib päringud xmlrpc.php-le enne, kui need sinu serverini jõuavad. See on kõige tõhusam lähenemine saitidele mis tahes majutusel.

Seadistamise võimalused:

• Cloudflare (tasuta pakett): WAF Rule → Block → URI Path väli sisaldab /xmlrpc.php. Päring lükatakse tagasi Cloudflare'i võrgu tasemel, sinu server ei näe seda üldse.
• Wordfence WAF: Sisseehitatud „Disable XML-RPC" funktsioon tulemüüri sektsioonis.
• Majutuse WAF: Kinsta, WP Engine ja teised hallatavad majutusteenused võimaldavad XML-RPC paar klõpsuga juhtpaneeli kaudu keelata.

Plussid: null serveri koormus, saab peenhäälestada (näiteks lubada Jetpack, blokeerides kõik muu). Miinused: nõuab WAF-i poolset seadistamist, mitte kõik majutusteenuse pakkujad ei paku seda võimalust.

5. Eemalda või nimeta fail ise ümber

Kõige radikaalsem meetod. Kustutad (või nimetad ümber) xmlrpc.php faili serverist. Kui faili füüsiliselt ei eksisteeri, pole midagi päringuid töödelda, server tagastab 404.

Oluline nüanss: järgmisel WordPressi uuendusel fail taastatakse. Automaatsed tuumauuendused kirjutavad üle kõik WordPressi failid, sealhulgas xmlrpc.php. Seega on kustutamine ajutine meede, kui just ei sea sisse regulaarset puhastamist.

Kui lähed seda teed, täienda kustutamist meetodi 2 .htaccess reegliga. Ilma selleta jätkavad robotid xmlrpc.php URL-ile koputamist ja server tagastab igale päringule ausalt 404, tuhandeid vigu logides.

Kas xmlrpc.php üldse tasub keelata?

Vastus sõltub sellest, mida kasutad. Mine läbi kontrollnimekiri:

Kui sa ei kasuta mobiilirakenduse vana versiooni, pole lubanud Jetpacki haldust WordPress.com-iga ja pingback'id pole sinu jaoks kriitilised, keela see kõhklemata. Aastal 2026 katab REST API peaaegu kõik tegelikud stsenaariumid.

Video: kuidas keelata XML-RPC WordPressis 5 minutiga

Vaata visuaalset juhendit xmlrpc.php keelamiseks koos ekraanidemonstratsiooni ja iga meetodi selgitusega:

⁉️🤔 Korduma kippuvad küsimused

Kas xmlrpc.php lihtsalt ignoreerimine on ohutu?

Enamikul juhtudel ei ole. Isegi kui sa XML-RPC-d ei kasuta, skannivad robotid seda lõpp-punkti pidevalt. Iga selline päring koormab serverit. Parem on selgesõnaliselt sulgeda juurdepääs .htaccess-i või plugina kaudu, see kõrvaldab nii brute-force'i riski kui ka rämpspäringud logides.

Kas sait läheb katki, kui xmlrpc.php on keelatud?

WordPress ise jätkab tööd ilma muudatusteta. Lihtsalt kontrolli, kas kasutad Jetpacki haldust WordPress.com-iga või mobiilirakenduse vana versiooni. Kui ei, siis keela muretult. Pingback'id lakkavad tulemast, kuid enamik saite ei kasuta neid niikuinii tegelikuks suhtluseks.

Kuidas kontrollida, et xmlrpc.php on tegelikult blokeeritud?

Ava brauseris https://your-site.com/xmlrpc.php. Kui näed valget ekraani teatega „XML-RPC server accepts POST requests only", on fail elus ja vastab. Kui saad 403 Forbidden või 404 Not Found, siis blokeering töötab. Automaatseks monitooringuks võid kasutada veebipõhiseid kontrollijaid nagu xmlrpc.eror.xyz või curl päringut konsoolist.

Kumb on parem: plugin või.htaccess?

.htaccess blokeerib päringu enne WordPressi käivitumist, see säästab serveri ressursse. Pluginat on lihtsam paigaldada ja see ei nõua failide muutmist. Mittekriitiliste saitide puhul pole peaaegu mingit vahet. Suure koormusega projektide puhul on eelistatud .htaccess või WAF-i reegel.

Kas pärast xmlrpc.php keelamist on vaja WordPressi uuendada?

Ei. xmlrpc.php keelamine ei sõltu WordPressi versioonist ega mõjuta tuumauuendusi. Ainus nüanss: kui kustutasid faili füüsiliselt, taastab uuendus selle, nõudes uuesti kustutamist.

Mida siis xmlrpc.php-ga oma saidil teha?

Universaalset vastust pole, kontekst määrab kõik. Kuid tuhandete WordPressi saitide praktika annab selge pildi: kui sa ei tea, kas vajad XML-RPC-d, siis sa ei vaja seda.

Soovid usaldusväärsust ilma koodi süvenemata, paigalda Disable XML-RPC. Oled valmis kulutama viis minutit .htaccess-ile, saad serveritaseme kaitse ilma lisapluginateta. Kasutad Cloudflare'i, sea üles WAF-i reegel ja unusta probleem.

Peamine on mitte jätta xmlrpc.php „vaikimisi" avatuks. Aastal 2026 on iga sulgemata WordPressi lõpp-punkt sihtmärk automatiseeritud robotitele, keda ei huvita, kas sul on blogi või veebipood. Sule juurdepääs ühe ülaltoodud meetodi abil, kontrolli tulemust curl päringuga ja maga rahulikult.