Védelem, amely már a WordPress előtt elindul

A szignatúraalapú keresők a lemezen már jelen lévő, ismert kártékony kódot keresik. A Must-Have Security eleve megakadályozza, hogy az ilyen kód fájlba kerüljön. A WordPress előtt indul, minden fájlírásnál ellenőrzi a tartalmat, és blokkolja az olyan futtatható kódot, amelynek létrehozására a webhely egyetlen összetevője sem kapott engedélyt. Így egy vadonatúj webshellt is blokkol, amelyhez még sehol nincs szignatúra. A már meglévő fájlok vizsgálatára is van keresője, de az más elven működik: a WordPress alapfájljait a hivatalos checksumok alapján ellenőrzi, minden mást pedig kódként elemez. Az elemző végigköveti a kérésből származó adatok útját a kódban: vagy bizonyítja, hogy a fájl ártalmatlan, vagy szabály alapján kártékonynak minősíti. A ritka, eldönthetetlen eseteket AI-ra bízza. Nem egy folyton lemaradó szignatúralistára hagyatkozik.

Nem. Amikor bővítményt, sablont vagy a WordPress alapfájljait frissíted, az éppen megnyitott felületen egyetlen érintéssel, passkey-vel adhatsz írási engedélyt. Ez kizárólag az adott útvonalra érvényes, néhány percig. Ha előbb megnéznéd, hogyan működik, kapcsold a fájlírások ellenőrzését megfigyelési módba. Így a saját webhelyeden láthatod, mit tenne a védelem, mielőtt újra bekapcsolod a tiltást.

Kifejezetten úgy terveztük, hogy ne zárhasson ki. A hozzáférésről döntő réteg hiba esetén engedi a belépést, és soha nem tilt le olyan IP-címet, amelyet egy megbízható admin már használt. Egyetlen tűzfalszabály sem blokkolhatja az adminfelületet vagy a bejelentkezési oldalt. A betöltőt sem egyszerűen törli, hanem két biztonságos lépésben kapcsolja ki. Ha a motor fatal errorba fut, kikapcsolja magát, hagyja elindulni a webhelyet, és e-mailben értesíti az összes megbízható admint. Ők a vezérlőpulton újra bekapcsolhatják a védelmet. (Az automatikus kikapcsolást letilthatod, ha motorhiba esetén inkább 500-as hibát szeretnél, mint védelem nélkül működő webhelyet. A beállítást passkey védi, mert az automatikus kikapcsolás engedélyezése gyengíti a védelmet.)

Minden fájlműveletnél lefut egy PHP-ban írt kódrészlet. Tesztszervereinken ez műveletenként körülbelül 2–45 mikroszekundum többletidőt jelentett, egy teljes adminfelületi kérésnél tehát néhány milliszekundumot. A teljesítmény tárhelyenként eltér, ezért nem ígérjük, hogy nálad is ugyanezeket az értékeket kapod.

WordPress és olyan PHP-környezet, ahol az auto_prepend_file beállítható .user.ini vagy .htaccess fájlból. Ezt szinte minden osztott és menedzselt tárhely biztosítja. Ahol egyik betöltő sem használható, ott a WordPress után indul el. Nem kell hozzá root jog, szervermodul vagy daemon.

A WordPress az adatbázisban tárolja az adminisztrátori szerepkört, ezt pedig egy SQL injection is átírhatja. Ezért a bővítmény a megbízható adminok nyilvántartását és minden hitelesítő adatot az adatbázison kívül, a motor saját, védett vezérlőfájljaiban tárolja. A WordPress-adminjog önmagában soha nem elég futtatható kód írásához, akkor sem, ha SQL injection támadással szerezték meg.

A WordPress a move_uploaded_file() függvénnyel mozgatja a feltöltött fájlokat, ami megkerüli a fájlírásokat ellenőrző stream wrappert. Ezért a bővítmény még az áthelyezés előtt ellenőrzi az ideiglenes fájl tartalmát és nevét is. A PHP-kódot rejtő JPEG-et éppúgy elutasítja, mint a shell.php.jpg fájlt, mert a fájlnév minden kiterjesztését ellenőrzi.

A fájlírásokat ellenőrző motor teljesen determinisztikus: nem használ hálózatot, adatbázist vagy AI-t. Ugyanazokból a bemeneti adatokból minden kérésnél ugyanarra az eredményre jut, és a döntését semmi nem írhatja felül. Egyedül a kártevőkereső kommunikál külső szolgáltatással. Alapértelmezés szerint ki van kapcsolva, a bekapcsolásakor pedig jóvá kell hagynod a külső szolgáltatás használatát. Még ekkor is a lehető legkevesebb adatot küldi el. A WordPress alapfájljait és a közös reputációs adatbázisban már ismert fájlokat hash alapján ellenőrzi. A többi fájl nagy részéről a saját szervereden futó elemző dönt. Csak azokat a fájlokat küldi el HTTPS-en keresztül AI-elemzésre, amelyekről nem tudja bizonyítani, hogy ártalmatlanok, és szabály alapján sem tudja őket kártékonynak minősíteni. Egy éles webhelyen ez a fájlok kevesebb mint 1%-a. A bizalmas adataidat (wp-config, .env, kulcsok, biztonsági mentések) viszont kizárólag a saját szervereden ellenőrzi, és semmilyen adatot nem küld róluk. A kereső óránkénti kerete előfizetésenként 3000 kérés és 300 AI-elemzés. Ha a vizsgálat eléri a kérési korlátot, szünetel, majd magától folytatódik. Ha az AI-elemzések kerete fogy el, az érintett fájlok kivárják a sorukat.

A támadó nem tudja tartósan megvetni a lábát a webhelyen, de amit a már futó kódjával tesz, azt a bővítmény nem akadályozza meg. Ha egy kérésben már fut a támadó kódja, meghívhatja az exec() függvényt, vagy kiiktathatja a stream wrappert. Ez a réteg azt akadályozza meg, hogy a kód fájlba kerüljön; a már futó kódot nem korlátozza. A dokumentáció egyértelműen leírja ezeket a korlátokat, nem állítja, hogy ezekre is van védelem.

Igen. A motor továbbra is érvényesíti a szabályokat, a biztonságod nem függ az előfizetéstől. A frissítésekhez és a támogatáshoz aktív előfizetés szükséges. Kikapcsoláskor a bővítmény maradéktalanul eltávolítja a betöltőt, törléskor pedig megtartja a beállításaidat, hacsak be nem jelölöd az „összes adat törlése” lehetőséget.