az xmlrpc.php File and Site Security

a legtöbb WordPress téma header.php sablonjában szerepel egy fontos horog, az úgynevezett wp_head. Ez az alapvető horog lehetővé teszi a WordPress funkciók számára, hogy tartalmat küldjenek a böngészőnek a weboldalak <head> területén1.

például a WordPress újabb verzióiban a wp_head() lehetővé teszi a WordPress számára, hogy a következő három sort adja ki a téma <head>:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://digwp.com/xmlrpc.php?rsd" /><link rel="wlwmanifest" type="application/wlwmanifest+xml" href="https://digwp.com/wp-includes/wlwmanifest.xml" /> <link rel='index' title='Digging into WordPress' href='https://digwp.com/' /><meta name="generator" content="WordPress 2.8" />

mint látható, sok dolgot adunk hozzá, beleértve a feed linkeket, az XML-RPC és a WLW linkeket, és néhány más elemet. Bár rengeteg megbeszélni ezeket a zárványokat, itt elsősorban a xmlrpc.php fájlra mutató hivatkozással foglalkozunk. A WordPress tartalmazza ezt a linket az XML-RPC felületéhez, amely lehetővé teszi a távoli alkalmazások számára a WordPress kommunikációját és interakcióját.

mit jelent xmlrpc.php do? Szükségem van rá?

míg a WordPress XML-RPC dokumentációja meglehetősen vékony, részleges megértést kaphatunk a xmlrpc.php működéséről, ha átlépjük a fájl kódját. Ne aggódj, nem fogunk unatkozni, hogy itt, de elég annyit mondani, hogy a xmlrpc.php szükséges a dolgok, mint:

  • kiküldetés közvetlenül a blog segítségével TextMate, Flock, és más ügyfelek
  • kiküldetés közvetlenül a blog segítségével Eudora, Thunderbird, és más alkalmazások
  • fogadása pingbacks és trackbacks a webhely más blogok

nem mindenki használja a távoli kiküldetés funkció elérhető számukra a WordPress, de azt hiszem, hogy sok blogok határozottan használja a az XML-RPC protokoll a pingback és trackback funkciókhoz.

nem az xmlrpc.a php fájl biztonsági kockázatot jelent?

néhányan emlékeznek a xmlrpc.php szkripthez kapcsolódó biztonsági kockázatokra a WordPress 2.1.2 jó napjaiban, amikor:

a WordPress lehetővé teheti egy távoli hitelesített támadó számára, hogy megkerülje a biztonsági korlátozásokat, amelyeket az xmlrpc parancsfájl nem megfelelő érvényesítése okoz. A közreműködői engedélyekkel rendelkező távoli támadó kihasználhatja ezt a biztonsági rést, hogy bejegyzéseket tegyen közzé a webhelyen.

ezt a biztonsági rést azonnal megszüntették a 2.1.3-as verzióban, de röviddel ezután (a 2.3-as verzióban).1) egy másik biztonsági problémát fedeztek fel, amikor kiderült, hogy az XML-RPC megvalósítás információkat szivárogtat.

bár ezt a 2.3.2-es verzióban rögzítették, az XML-RPC protokollhoz kapcsolódó biztonsági aggályok végül arra késztették a WordPress fejlesztőit, hogy alapértelmezés szerint tiltsák le a távoli hozzáférést a 2.6-os verzióban. A xmlrpc.php fájl továbbra is szerepel a <head> dokumentumban (feltehetően a pingbackek és a trackbackek kedvéért), de a távelérési funkció nem működik, amíg kifejezetten nem engedélyezik2.

nézze meg ezeket a kapcsolódó hozzászólásokat a romlandó sajtó további információkért az xmlrpc-ről.php fájl-és webhelybiztonság:

  • védelem a WordPress Pingback sebezhetőségéhez
  • védelem a WordPress Brute Force Amplification támadás ellen

Biztonsági tippek a webhely xmlrpc-jéhez.php fájl

az írás idején nincsenek ismert sebezhetőségek a WordPress XML-RPC protokolljával kapcsolatban. Ennek ellenére biztonsági problémák merültek fel a xmlrpc.php szkripttel a múltban, és minden bizonnyal új problémák merülhetnek fel mind most, mind a jövőben. Csak a biztonság kedvéért itt van néhány különböző stratégia és tipp, amelyek segítenek a blog maximális biztonságának biztosításában.

ha nincs rá szüksége, törölje

a lehetséges biztonsági rések kiküszöbölésének talán a legbiztonságosabb módja az, ha egyszerűen eltávolítja a kérdéses szkriptet. Ha nincs szükség távoli közzétételre, pingbackekre vagy trackbackekre, akkor a legegyszerűbb egyszerűen eltávolítani a xmlrpc.php fájlt a szerverről. Ahelyett, hogy valóban törölné, lehet, hogy csak át akarja nevezni valami kitalálhatatlant. Akárhogy is, ha a szkript nem érhető el a támadó számára, megnehezíti a kihasználást.

frissítés: ha eltávolítja (vagy átnevezi) a xmlrpc.php fájlt a WordPress telepítéséből, akkor a következő szakaszban leírt funkciót is végre kell hajtania, hogy elkerülje a 404 hiba lavináját (további magyarázatért lásd ezt a megjegyzést).

távolítsa el az xmlrpc-re mutató hivatkozásokat.php és wlwmanifest.xml

Alternatív megoldásként, ha nincs szüksége távoli hozzáférésre vagy pingback funkcióra, akkor inkább egyszerűen távolítsa el a társított fejléchivatkozásokat, ahelyett, hogy törölne bármilyen alapvető fájlt a szerverről. Ez könnyen megvalósítható az aktív téma functions.php fájljában elhelyezett következő funkcióval:

function removeHeadLinks() {remove_action('wp_head', 'rsd_link');remove_action('wp_head', 'wlwmanifest_link');}add_action('init', 'removeHeadLinks');

ez megakadályozza, hogy ez a két fájl összekapcsolódjon a fejlécben, de maguk a fájlok továbbra is elérhetők maradnak a szerveren. Feltétlenül győződjön meg arról, hogy a távoli közzététel alapértelmezett letiltása érvényben van, ha ezt a módszert alkalmazza.

tiltsa le a távoli közzétételi funkciót

ha nem teszi közzé a távoli közzétételt, de továbbra is szeretne pingbackeket és trackbackeket kapni, vegye figyelembe a WordPress tanácsát, és hagyja alapértelmezés szerint letiltva a távoli hozzáférési funkciót. Ez a lépés önmagában óriási módszernek tűnik a blog biztonságának szigorításában. A fájl továbbra is elérhető lesz a szerveren, de a támadók sokkal kevesebbet tehetnek vele.

a rosszindulatú xmlrpc megakadályozása.php directory scanning

azoknak, akik bölcsen szemmel tartják a szerver hozzáférési és hibanaplóit, valószínűleg a közelmúltban megnőtt a rosszindulatú xmlrpc.php könyvtár szkennelés. Akármilyen okból is, a rosszfiúkat hirtelen nagyon érdeklik a xmlrpc.php fájlok, és minden könyvtárat átvizsgálnak, amin a botjaik megtalálhatják őket. Az utóbbi időben rengeteg ilyen tevékenységet láttam:

http://domain.tld/2009/xmlrpc.phphttp://domain.tld/2009/06/xmlrpc.phphttp://domain.tld/2009/06/01/xmlrpc.phphttp://domain.tld/2009/06/01/permalink/xmlrpc.phphttp://domain.tld/2009/06/02/permalink/xmlrpc.phphttp://domain.tld/2009/06/03/permalink/xmlrpc.php...

függetlenül attól, hogy a támadók megtalálják-e a célpontjukat vagy sem, ez a fajta viselkedés kimeríti a rendszer erőforrásait, csökkenti a sávszélességet, és megakadályozza, hogy a webhely maximális kapacitással működjön. Így annak megakadályozása érdekében, hogy ez a rosszindulatú viselkedés károsítsa webhelyét, kidolgoztam a következő HTAccess megoldást:

<IfModule mod_alias.c>RedirectMatch 301 /(.*)/xmlrpc\.php$ http://domain.tld/xmlrpc.php</IfModule>

ha a webhelyéhez tartozó, interneten elérhető Root HTAccess fájlba helyezi, ez az egyszerű irányelv átirányítja a blog xmlrpc.php fájljára vonatkozó összes kérést a tényleges fájlra. Már több hete használom ezt a módszert a romlandó sajtónál, és emiatt több ezer rosszul irányított kérést szüntettem meg.

hagyja el az xmlrpc-t.php fájl, de megakadályozza a hozzáférést

végül, de nem utolsósorban egy egyszerű módszer, amely lehetővé teszi, hogy a fájlt a helyén hagyja a szerveren, de megakadályozza a hozzáférést. Tökéletes, ha nincs szüksége a szkriptre, és olyan lusta akar lenni, amennyire csak lehetséges, hogy biztonságban tartsa (úgy gondolja, hogy nincs karbantartás). Egyszerűen illessze be a következő kódot a root HTAccess fájlba, és végezze el vele:

<IfModule mod_alias.c>RedirectMatch 403 /(.*)/xmlrpc\.php$</IfModule>

Megjegyzések

  • 1 vagy bárhol a wp_head() horog található.
  • 2 ennek a funkciónak az engedélyezéséhez lépjen a következő oldalra: Beállítások (Settings) 6403>

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.