WordPress XML-RPC letilődésének letiltása: Így védd meg oldalad a brute force támadásoktól

A WordPress XML-RPC letiltása azt jelenti, hogy megakadályozzuk az xmlrpc.php fájl távoli elérését, ezzel gyorsan csökkentve a brute force támadásokat, pingback visszaéléseket és a fölösleges botforgalmat. Ha nem használod a Jetpack-et, a WordPress mobilalkalmazást, régebbi távoli közzétételi eszközöket vagy bármilyen, XML-RPC protokollt igénylő egyedi integrációt, akkor az XML-RPC letiltása a legtöbb WordPress oldal számára biztonságos és hatékony lépés a webhely megerősítésére. A leghatékonyabb megoldás, ha a kéréseket még a WordPress működése előtt, szerveroldalon blokkolod: vagyis Apache, LiteSpeed, Nginx vagy WAF szabályokkal tiltod le az xmlrpc.php elérését, ami általában jobb teljesítményt nyújt, mint egy bővítményes módszer.

Ebben az útmutatóban lépésről lépésre bemutatjuk, miért érdemes letiltani a WordPress XML-RPC-t, mikor nem ajánlott, és hogyan alkalmazhatod biztonságosan különböző szerverkörnyezetekben. Nem számít, hogy Hostragons infrastruktúrán vagy más tárhelyszolgáltatónál fut a weboldalad, a cél, hogy a webhelyed ne sérüljön, miközben csökkented a támadási felületet, mérsékeled a fölösleges erőforrás-felhasználást, és egy jól kezelhető biztonsági szintet alakítasz ki. Ha gyors és biztonságos alapokra vágysz WordPress oldaladhoz, a WordPress hosting választása is fontos szempont lesz.

Mi az az XML-RPC, és mire használja a WordPress?

Az XML-RPC egy régebbi távoli kommunikációs protokoll, amely lehetővé teszi, hogy különböző rendszerek HTTP-n át XML formátumban adatokat küldjenek egymásnak. A WordPress esetében ez elsősorban az xmlrpc.php fájlon keresztül valósul meg, amelyet régebben mobilalkalmazásból történő posztolásra, távoli hozzászólás-kezelésre, pingbackek kezelésére és egyes harmadik féltől származó szolgáltatások webhelyhez való kapcsolódására használtak.

A mai WordPress ökoszisztémában a REST API vált meghatározóvá, így az XML-RPC szerepe jelentősen csökkent. Ugyanakkor az xmlrpc.php fájl a legtöbb telepítésnél még elérhető, ami könnyen kiszúrható és automatizált támadások célpontjává teheti a webhelyet. Különösen a véletlenszerű IP-tartományokat pásztázó botok perceken belül megpróbálhatják elérni ezt a végpontot, még akkor is, ha a domain új. Ezért fontos, hogy Domain ellenőrzés után azonnal gondoskodj a biztonság alapjairól.

Mikor lehet mégis szükség az XML-RPC-re?

Nem minden oldal számára felesleges az XML-RPC. Bizonyos régi Jetpack funkciók, a WordPress mobilalkalmazás egyes műveletei, automatizált szolgáltatások vagy régi asztali blogkliens programok még igényelhetik ezt a protokollt. Ezen kívül egyedi fejlesztések, távoli tartalomfeltöltések vagy adatlekérések is használhatják az xmlrpc.php-t. Ezért mielőtt letiltanád, érdemes áttekinteni, hogy a weboldalad munkafolyamatai megkövetelik-e az XML-RPC-t.

Gyakorlati ellenőrzésként: ha az oldalad tartalmát kizárólag a wp-admin felületen keresztül szerkeszted, nem használsz Jetpack-et, nem posztolsz mobilalkalmazásból, és fejlesztőd nem telepített XML-RPC alapú egyedi integrációt, akkor valószínűleg nincs szükséged erre a funkcióra. A vállalati oldalak, blogok, katalógusok, kisvállalkozások és WooCommerce boltok nagy része zavartalanul működik XML-RPC nélkül. Ha azonban WooCommerce fizetési vagy szállítási integrációid vannak, érdemes a letiltást forgalommentes időszakban tesztelni.

Miért jelent veszélyt a WordPress XML-RPC a brute force támadások szempontjából?

A brute force támadás lényege, hogy a támadó automatikus eszközökkel ismételten próbálja kitalálni a felhasználónév-jelszó párosokat. WordPressben ez jellemzően a wp-login.php-n keresztül történik, de az XML-RPC még kedvezőbb lehetőségeket kínál a támadóknak. Bizonyos XML-RPC metódusok ugyanis egyetlen HTTP kérésben több bejelentkezési próbálkozást is engedélyeznek. Különösen a system.multicall funkció segítségével gyengén konfigurált rendszereken akár több száz próbálkozás is álcázva, kevesebb látható kéréssel hajtható végre.

Például míg a wp-login.php-n keresztül 500 egyedi próbálkozást 500 külön kérésként észlel a rendszer, az XML-RPC-n keresztüli 500 próbálkozás kevesebb, összevont kérésben érkezhet. Ez megnehezítheti a biztonsági bővítmények és egyszerű naplófigyelők számára a támadás időben történő felismerését. Ennek következtében nő a CPU terhelés, a PHP munkafolyamatok leterhelődnek, az adatbázis fölösleges lekérdezésekkel terhelődik, és a valódi látogatók lassú válaszidőkkel találkozhatnak. Megosztott tárhelyeken ez nemcsak biztonsági, hanem teljesítménybeli és erőforrás-használati problémát is okoz.

Az XML-RPC másik kockázata a pingback visszaélés. Ez a mechanizmus arra szolgál, hogy más honlapok jelezzék, ha hivatkoznak a tartalmadra, de rosszindulatú használat esetén DDoS jellegű forgalmat generálhat, vagy harmadik fél oldalait teheti meg támadás célpontjává. Emiatt az XML-RPC letiltása nem csupán a bejelentkezési próbálkozásokat csökkenti, hanem a pingback alapú visszaélések esélyét is mérsékli.

XML-RPC letiltási módszerek összehasonlító táblázata

Ahogy a táblázat is mutatja, a leggyorsabb és legerősebb módszer, ha nincs szükséged az XML-RPC-re, akkor szerver- vagy WAF szinten zárod le az elérést. A bővítményes megoldás egyszerűbb, de a támadói kérések így is elérhetik a PHP futtatókörnyezetet, ami nem szünteti meg teljesen az erőforrás-terhelést. Emiatt nagy forgalmú, e-kereskedelmi vagy támadás alatt álló oldalakon elsődleges a webszerver szabályok használata.

Előkészületek a letiltás előtt – ellenőrző lista

Biztonsági beállítások előtt az egyik legfontosabb elv az előzetes mérés és a visszaállítási terv kidolgozása. Az XML-RPC letiltása általában biztonságos, de élő oldalon soha ne végezz változtatást vakon. Az alábbi lista segít csökkenteni a hibák kockázatát:

• Legyen friss, működő fájl- és adatbázismentésed az elmúlt 24 órából. WordPress frissítés, biztonsági módosítás és bővítményváltás előtt ez kötelező.
• Ellenőrizd, hogy használsz-e Jetpack-et, WordPress mobilalkalmazást, távoli közzétételi eszközt vagy egyedi integrációt, mely az XML-RPC-t igényli.
• Vizsgáld meg az elérési naplókat, különösen az xmlrpc.php kérések számát. Ha percenként több tucat vagy száz kérés érkezik, támadás alatt állhatsz.
• Válassz alacsony forgalmú időszakot a változtatásra. WooCommerce esetén különösen fontos a kosár, fizetés és regisztráció funkciók későbbi tesztelése.
• Készíts visszavonási tervet. Legyen kéznél FTP, SSH vagy fájlkezelő hozzáférésed, hogy a szabályokat könnyen kikapcsolhasd vagy eltávolíthasd.

Professzionális tárhelyszolgáltatónál az automatikus mentések, naprakész PHP verzió, elszigetelt fiókok és tűzfal támogatás sokat számítanak. Ezekhez kapcsolódóan hasznos lehet a Biztonságos Web Hosting, illetve az oldal általános védelmét bemutató SSL tanúsítvány tartalmak átnézése is.

1. módszer: XML-RPC letiltása .htaccess szabállyal Apache vagy LiteSpeed szerveren

Apache és LiteSpeed webszerveren a leggyakoribb és legegyszerűbb megoldás, ha a webhely gyökérkönyvtárában található .htaccess fájlba illesztünk be egy olyan szabályt, amely blokkolja az xmlrpc.php fájl elérését. Mivel a LiteSpeed kompatibilis az Apache .htaccess szabályaival, ez a módszer széles körben alkalmazható. A legnagyobb előnye, hogy a kérés el sem jut a WordPress magjáig.

Lépésről lépésre

• Nyisd meg a tárhelyed vezérlőpultját, és indítsd el a fájlkezelőt, vagy FTP-klienssel csatlakozz a public_html könyvtárhoz.
• Keresd meg a .htaccess fájlt, és ments róla biztonsági másolatot. Ha nem látsz rejtett fájlokat, kapcsold be a rejtett fájlok megjelenítését.
• A WordPress által létrehozott szabályok megtartása mellett a fájl tetejére illeszd be az XML-RPC tiltó szabályt.
• A szabálynak úgy kell kinéznie, hogy az xmlrpc.php fájlhoz érkező kéréseket minden esetben elutasítja.
• Mentés után próbáld meg megnyitni a böngészőben a sajatdomained.hu/xmlrpc.php címet.

Apache 2.4 és LiteSpeed környezetben az alábbi szabály használatos: a xmlrpc.php fájlhoz a Require all denied parancsot kell alkalmazni. Régebbi, Apache 2.2 verzióknál a Deny from all megoldás jellemző, azonban 2026-ban már ajánlott friss, korszerű szerver szoftvert használni. Ha régi Apache verzió fut, az nemcsak az XML-RPC miatt, hanem általános biztonsági szempontból is fejlesztendő.

Ha sikeres a tiltás, akkor az xmlrpc.php oldal 403 Forbidden, 404 Not Found vagy hasonló elutasító választ ad, és nem jelenik meg az “XML-RPC server accepts POST requests” szöveg. Ha ez utóbbi üzenet látható, az xmlrpc.php továbbra is elérhető.

2. módszer: XML-RPC blokkolása Nginx szerveren

Nginx esetén a .htaccess fájl nem működik, mert az Nginx nem olvassa a könyvtárszerinti helyi szabályokat. Ezért a tiltást a szerver konfigurációs fájljában, a megfelelő server blockban kell elhelyezni. Ha menedzselt tárhelyet használsz, előfordulhat, hogy nincs közvetlen hozzáférésed ehhez, ilyenkor kérd meg a szolgáltató támogatását az xmlrpc.php letiltására.

Az alapelv, hogy az location = /xmlrpc.php blokkban vagy 403-as tiltást állítasz be, vagy 404-es „nem található” választ küldesz. A 403-as tiltás egyértelmű, a 404-es pedig kevésbé árulkodó a támadók számára. A szabály hozzáadása után teszteld a konfigurációt, majd indítsd újra az Nginx szolgáltatást. Egy apró elírás akár az egész webhely elérhetetlenségét okozhatja, ezért ezt a lépést körültekintően végezd el.

VPS vagy dedikált Nginx szervereken a módosítás után érdemes figyelni az elérés naplókat, hogy az xmlrpc.php kérések 403 vagy 404 státuszkódot kapnak-e. Ha ugyanattól az IP-től még mindig jönnek sok próbálkozás, érdemes fail2ban, rate limit vagy WAF szabályokkal további védelmi réteget építeni. Részletesebb szerverbiztonsági útmutatóért nézd meg a VPS szerver biztonság cikket.

3. módszer: XML-RPC letiltása biztonsági bővítmény segítségével

Ha nem akarsz szerverfájlokat szerkeszteni, a biztonsági bővítmények praktikus megoldást kínálnak. Például a Wordfence, Solid Security vagy All-In-One Security pluginok külön beállításokat tartalmazhatnak az XML-RPC tiltására, pingback kikapcsolására vagy bejelentkezési kísérletek korlátozására. Ez a módszer jól jön kisebb blogok vagy alapvető vállalati oldalak esetén.

Ugyanakkor fontos tudni, hogy ha a bővítmény csak a WordPress futása után blokkolja a kérést, akkor a támadó kérés így is eléri a PHP-t, ami nem szünteti meg teljesen az erőforrás-fogyasztást. Ezért bővítményes megoldásnál is javasolt a szerver vagy WAF szintű védelem kiegészítése, különösen nagy forgalmú vagy támadás alatt álló oldalak esetén.

Figyelmeztetések bővítmény használata esetén

• Töltsd le a biztonsági bővítményt kizárólag a hivatalos WordPress plugin könyvtárból vagy a gyártó hivatalos oldaláról.
• Kerüld az évek óta nem frissített bővítményeket, mert 2026-ban a folyamatos karbantartás és kompatibilitás nagyon fontos biztonsági jelzés.
• Ne használj több biztonsági bővítményt ugyanarra a célra, mert összeütközések léphetnek fel a bejelentkezésnél, cache kezelésnél vagy fájlhozzáféréseknél.
• Az XML-RPC letiltása után teszteld az oldal egészségi állapotát, űrlapokat, regisztrációt és fizetési folyamatokat.
• Rendszeresen ellenőrizd a bővítmény naplóit, és ha folyamatos támadásokat tapasztalsz, adj hozzá IP alapú tiltást vagy WAF szabályt.

4. módszer: WAF, CDN és tárhelyi tűzfal használata az XML-RPC blokkolására

A Web Application Firewall (WAF) az egyik leghatékonyabb réteg arra, hogy a káros kéréseket még a webalkalmazás elérése előtt kiszűrje. A Cloudflare-hez hasonló CDN szolgáltatások képesek blokkolni az xmlrpc.php kéréseket a szerver előtt. A tárhelyszolgáltatók által biztosított ModSecurity vagy egyedi WAF szabályok ugyancsak ezt a célt szolgálják. Ez a réteg különösen akkor hasznos, ha sok bot-támadás éri az oldalt, és nem szeretnéd, hogy a kérések elérjék a WordPress-t.

A WAF szabálynak pontosnak kell lennie: ha az URI útvonala tartalmazza az xmlrpc.php-t, akkor blokkolni vagy kihívást (challenge) kell alkalmazni. Ha nincs szükséged az XML-RPC-re, a teljes tiltás a legegyszerűbb. Ha részleges használatot igényel az oldal, akkor csak meghatározott IP-k engedélyezése javasolt. Például ha egy automatizált szolgáltatás fix IP-ről érkezik, azt felveheted a fehérlistára, míg minden más xmlrpc.php kérés elutasításra kerül. Ez a megközelítés kiegyensúlyozza a biztonságot és a szolgáltatás folytonosságát.

A WAF réteg hatékonysága nagyobb, ha az oldal HTTPS-t használ. HTTPS nélküli oldalak esetén a bejelentkezési adatok és munkamenet biztonsága különösen veszélyeztetett. Ezért az XML-RPC letiltás mellett érdemes az egész oldalt HTTPS-re állítani, HSTS fejléceket alkalmazni és figyelni a tanúsítvány lejáratát. Ehhez kapcsolódóan a SSL tanúsítvány és Ingyenes SSL Telepítés témák nyújtanak további segítséget.

Hogyan teszteld az XML-RPC letiltás utáni működést?

A változtatás után nem elég csak azt ellenőrizni, hogy az oldal elérhető-e. Fontos megnézni, hogy az XML-RPC valóban le van-e tiltva, a beléptető rendszer megfelelően működik-e, és a felhasználói funkciók nem sérültek-e. Az alábbi lépések egy egyszerű, de hatékony ellenőrzést biztosítanak:

• Nyisd meg a böngészőben a sajatdomained.hu/xmlrpc.php címet. Ha tiltás él, akkor 403-as, 404-es vagy üres választ kell kapnod. Az „XML-RPC server accepts POST requests” üzenet nem jelenhet meg.
• Jelentkezz be a WordPress adminisztrációs felületére normál felhasználói adatokkal, és győződj meg róla, hogy a bejelentkezés zavartalan.
• Próbáld ki az oldal űrlapjait, hozzászólásokat, regisztrációt, illetve WooCommerce fizetési lépéseket.
• Nézd meg a szerver hozzáférési naplóiban, hogy az xmlrpc.php kérések milyen státusszal térnek vissza (403 vagy 404 a kívánt).
• Ha van telepítve biztonsági bővítmény, ellenőrizd a támadási naplókat, hogy látszik-e a próbálkozások csökkenése vagy blokkolása.

Haladóbb tesztként küldhetsz POST kérést terminálból, de a legtöbb weboldal-tulajdonos számára a böngészős és naplóellenőrzés elegendő. Ha a letiltás után a Jetpack kapcsolat megszakad, a mobilalkalmazás nem tud posztolni vagy az integráció hibát jelez, akkor az XML-RPC valóban szükséges. Ilyenkor érdemes inkább IP-alapú engedélyezést vagy rate limit megoldást alkalmazni a teljes tiltás helyett.

Az XML-RPC letiltása elég védelmet nyújt? Egyéb biztonsági lépések

Az XML-RPC letiltás gyors és hatékony lépés a brute force támadások mérséklésére, de önmagában nem garantál teljes védelmet. A támadók a wp-login.php-n, REST API-n, gyenge bővítményeken, elavult témákon vagy kiszivárgott jelszavakon keresztül is próbálkozhatnak. Ezért az XML-RPC letiltása után is fontos egy több rétegű biztonsági stratégia kialakítása.

Ajánlott alapvető biztonsági intézkedések

• Használj erős jelszavakat és egyedi felhasználóneveket. Az „admin” felhasználónév kerülése még mindig alapvető, de hatékony lépés.
• Kapcsold be a kétfaktoros hitelesítést (2FA). Különösen az adminisztrátor fiókoknál ez jelentősen csökkenti a jelszólopás kockázatát.
• Állíts be bejelentkezési kísérlet-korlátozást (rate limiting) a wp-login.php számára, akár biztonsági bővítménnyel.
• Mindig tartsd naprakészen a WordPress magot, bővítményeket és témákat. Az elavult komponensek a legtöbb valós támadás okozói.
• Töröld azokat a bővítményeket és témákat, amelyeket nem használsz. A régi, inaktív kódok is biztonsági kockázatot jelentenek.
• Ellenőrizd a fájl jogosultságokat. A túl engedékeny írási jogok növelik a rosszindulatú feltöltések esélyét.
• Rendszeresen készíts biztonsági mentést, és teszteld a visszaállítási folyamatot. Egy mentés csak akkor ér valamit, ha működik.
• Válassz megbízható tárhelyet, amely biztosít izolált fiókokat, naprakész PHP verziót, WAF-et és biztonsági mentési lehetőséget.

Például, ha csak az XML-RPC letiltásával próbálod megvédeni az oldalt, de a jelszó egyszerű és könnyen kitalálható, akkor a biztonsági lánc leggyengébb pontja továbbra is sérülékeny marad. Ezzel szemben, ha erős jelszót, 2FA-t, naprakész rendszert, WAF-et és biztonságos tárhelyet használsz együtt, a legtöbb automatizált bot támadás hatástalanná válik. Ez a megközelítés 2026-ban SEO szempontból is lényeges, mert a gyengén védett webhelyek káros átirányítások, spam oldalak és indexelési problémák miatt veszíthetnek organikus forgalmat.

Az XML-RPC letiltásának hatása a teljesítményre és SEO-ra

Az XML-RPC támadások önmagukban nem közvetlen Google rangsorolási tényezők, de közvetett hatásuk jelentős lehet. A túlzott botforgalom gyorsan kimerítheti a szerver erőforrásait, ami lassabb oldalbetöltést, romló Core Web Vitals mutatókat és rosszabb felhasználói élményt eredményez. Emellett a gyakori erőforrás-korlátok miatt 500-as hibák, időtúllépések és elérhetetlenségek is előfordulhatnak, amiket a Googlebot is érzékel, és negatívan értékel.

Vegyünk egy példát: normál esetben a főoldalad 300 ms alatt válaszol, de ha az xmlrpc.php-t percenként 1000 kérés éri, a PHP munkafolyamatok leterhelődnek, és a válaszidő akár 2 másodpercre is megugorhat. Ez a felhasználói élmény romlását, konverziócsökkenést és a Google Search Console keresési statisztikáinak ingadozását okozhatja. Az XML-RPC szerveroldali letiltásával ezt a fölösleges terhelést már a WordPress réteg előtt megszakíthatod, így stabilabb teljesítményt érhetsz el.

SEO szempontból tehát a biztonságos és gyors oldal nemcsak a tartalom minőségén, hanem a technikai háttéren is múlik. HTTPS, naprakész PHP, gyors tároló, megfelelő cache beállítások és támadási felület csökkentése együttesen alakítják a webhely sikerét. Emiatt a WordPress biztonsági beállításai nemcsak rendszergazdai, hanem SEO és tartalomfejlesztői feladat is. A Hostragons blogján további hasznos anyagokat találsz erről a témáról, például a WordPress sebesség optimalizálás és technikai SEO ellenőrző lista cikkekben.

Ha nem tudod teljesen letiltani az XML-RPC-t, milyen alternatívák vannak?

Néhány esetben az XML-RPC teljes tiltása nem megoldható. Például ha bizonyos mobilközzétételi folyamat, vállalati automatizmus vagy régi integráció még erre a protokollra épül. Ilyenkor nem az a cél, hogy minden kérést engedj, hanem hogy kontrolláltá tedd az elérést.

Az első megoldás az IP alapú fehérlista, amely csak a megbízható szolgáltatók IP-címeit engedi át, minden más kérést blokkol. A második a rate limit, vagyis a kérések számának korlátozása egy adott idő alatt, így az egy IP-ről érkező túlzott xmlrpc.php kérések elutasításra kerülnek. Ez nem olyan végleges, mint a teljes tiltás, de csökkenti a támadás volumenét. Harmadik lehetőség a pingback metódusok letiltása, miközben csak a valóban szükséges metódusokat engedélyezed – ez fejlettebb beállítást igényel, fejlesztői kontroll mellett.

Negyedikként az XML-RPC elérését külön biztonsági réteghez is kötheted, például HTTP alap-hitelesítéshez, VPN-hez, vállalati IP-korlátozáshoz vagy WAF kihíváshoz. Ezek csökkentik a nyilvános végpontok kockázatát. Mindenképp érdemes hosszú távon az ilyen régi integrációkat modernebb, REST API alapú, jobban kontrollálható megoldásokra átállítani.

Gyakorlati útmutató Hostragons felhasználóknak

Ha Hostragons szerverén fut a WordPress oldalad, először is végezd el az igényfelmérést, majd válaszd ki a legkevésbé bonyolult, de hatékony módszert. Megosztott vagy WordPress tárhely csomagok esetén a .htaccess szerkesztése elegendő lehet. VPS vagy dedikált szerver esetében pedig az Nginx, Apache, LiteSpeed és WAF rétegek kombinálását is megtervezheted.

Az optimális sorrend: készíts mentést, ellenőrizd az XML-RPC-t használó szolgáltatásokat, blokkolj szerveroldalon, végezd el a teszteket, majd 24 órán át figyeld a naplókat. Ha továbbra is érkeznek támadási kísérletek, adj hozzá WAF szabályt, IP tiltást és bejelentkezési korlátozást. Végül aktiváld az 2FA-t, tartsd naprakészen a rendszert, és gondoskodj a rendszeres mentésekről és SSL-ről.

Ez nem egy eladásra irányuló, hanem egy alapvető higiéniai lépés. Ha a szervered régi PHP verziót futtat, kevés erőforrásod van vagy nincs tűzfalad, érdemes lehet újabb, biztonságosabb tárhelyszolgáltatás felé nyitni. A WordPressre optimalizált, biztonsági rétegekkel ellátott környezet nemcsak a támadás alatt álló webhelyek ellenállását növeli, hanem a mindennapi működést is gyorsabbá teszi. Ehhez használhatod a WordPress hosting, felhőszolgáltatás és SSL tanúsítvány oldalak tartalmait is.

Gyakran ismételt kérdések

Szétzavarja-e a weboldalt az XML-RPC letiltása?

A legtöbb szabványos WordPress oldalnál az XML-RPC letiltása nem okoz működési problémát. Az admin felület, téma, tartalom, űrlapok és a látogatói funkciók általában érintetlenek maradnak. Ha azonban használod a Jetpack-et, a WordPress mobilalkalmazást, vagy speciális XML-RPC alapú integrációkat, előfordulhatnak hibák. Ezért fontos a letiltás előtt a használat felmérése és utána az alapfunkciók tesztelése.

Honnan tudhatom, hogy az XML-RPC le van-e tiltva?

Nyisd meg a böngésződben a sajatdomained.hu/xmlrpc.php címet. Ha az „XML-RPC server accepts POST requests” üzenetet látod, az azt jelenti, hogy az elérés még engedélyezett. Ha viszont 403-as, 404-es vagy elutasító választ kapsz, akkor a tiltás valószínűleg működik. Pontosabb ellenőrzéshez nézd meg a szerver hozzáférési naplókat, hogy az xmlrpc.php kérések milyen státusszal térnek vissza.

Megszünteti-e teljesen a brute force támadásokat az XML-RPC letiltása?

Az XML-RPC-n keresztüli brute force próbálkozásokat jelentősen csökkenti, de nem szünteti meg a teljes kockázatot. A támadók továbbra is a wp-login.php vagy más rétegek felől próbálkozhatnak. Ezért az XML-RPC letiltás mellett erős jelszavak, kétfaktoros hitelesítés, bejelentkezési korlátozás, WAF és rendszeres frissítések is szükségesek.

Ha használom a Jetpack-et, akkor le kell-e tiltani az XML-RPC-t?

A Jetpack egyes funkciói igénylik az XML-RPC kapcsolatot. Ha Jetpack-et használsz, előbb nézd meg, mely modulokat alkalmazod, és mérlegeld, hogy teljesen vagy részlegesen szeretnéd-e letiltani az XML-RPC-t. Alternatív megoldásként csak a Jetpack szervereinek IP-címeit engedélyezheted, vagy WAF segítségével korlátozhatod az xmlrpc.php elérést.

Bővítménnyel vagy szerveroldalon érdemesebb letiltani?

A legjobb teljesítmény és biztonság érdekében a szerver vagy WAF szintű letiltás ajánlott, mert így a kérés a WordPress és PHP futtatás előtt elutasításra kerül. A bővítményes megoldás könnyebben használható kevésbé technikai felhasználóknak, de nagy támadások esetén nem szünteti meg teljesen az erőforrás-felhasználást. Ha nem tudsz szerveroldalon szabályt beállítani, akkor válassz megbízható bővítményt és WAF támogatást.

Összefoglalás és következő lépések

A WordPress XML-RPC letiltása az egyik leggyorsabb módja annak, hogy az XML-RPC-t nem használó oldalak esetében csökkentsd a brute force támadásokat, pingback visszaéléseket és a felesleges botforgalmat. A legerősebb védelem, ha az xmlrpc.php elérését szerver vagy WAF szinten zárod le, majd ezt több rétegű beléptetési védelemmel, 2FA-val, rendszeres frissítésekkel, SSL-lel és mentésekkel egészíted ki. Ha szeretnéd felülvizsgálni a webhelyed biztonsági állapotát, nézd meg a Hostragons WordPress-specifikus tárhely- és biztonsági megoldásait, és kezd el ma a kisebb lépéseket egy stabilabb védelemért.