Nem tudok belépni a WordPress admin felületre feltörés után – mit tegyek?

Ha feltörés után nem tudsz belépni a WordPress admin felületre, ne kezdj el vakon új adminokat létrehozni és pluginmappákat törölni. Előbb derítsd ki, hogy egyszerű jelszóprobléma, sérült plugin, támadó által átírt felhasználó vagy aktív malware okozza-e a kizárást. A hozzáférés visszaszerzése csak az első lépés; attól az oldal még fertőzött maradhat.

Milyen tünetet látsz pontosan?

Más ok állhat a következő jelenségek mögött:

• a jelszó hibás, és a visszaállító e-mail nem érkezik meg;
• a felhasználónév már nem létezik;
• belépés után visszadob a login oldalra;
• 403 vagy 500 hiba jelenik meg a wp-admin alatt;
• teljesen fehér oldal vagy kritikus hiba látszik;
• a böngésző más domainre irányít;
• a belépés sikeres, de nincs admin jogosultságod;
• a biztonsági plugin zárolta az IP-címedet.

Rögzítsd a hibát, az időpontot és a szervernapló kapcsolódó sorait. Ha már más feltörési jelet is látsz, kövesd az első 30 perces incidenskezelési listát.

Először zárd le a további hozzáférést

Ha a támadó még aktív, minden újonnan létrehozott adminodat törölheti. Cseréld le a tárhely és SFTP hozzáférését egy tiszta eszközről, kapcsold be a többtényezős hitelesítést, és nézd át, kik férnek hozzá a tárhelyfiókhoz. Ne felejtsd el az e-mail-fiókot: ha azt is megszerezték, a jelszó-visszaállítást a támadó olvashatja.

Készíts mentést a jelenlegi fájlokról, adatbázisról és naplókról. Ezután lehet hozzányúlni az adminhoz.

Hozzáférés visszaállítása WP-CLI-vel

Ha van SSH és működik a WP-CLI, először listázd a felhasználókat:

wp user list --fields=ID,user_login,user_email,roles,user_registered
wp user get sajatadmin --field=roles

Állíts be új, egyedi jelszót, és ellenőrizd az e-mail-címet:

wp user update sajatadmin --user_pass='EGY_HOSSZU_EGYEDI_JELSZO'
wp user update sajatadmin --user_email='biztonsagos@example.com'

Ha a felhasználó szerepköre megváltozott:

wp user set-role sajatadmin administrator

Új admint csak átmenetileg hozz létre, és később töröld. Minden ismeretlen adminról előbb gyűjts bizonyítékot. Az ismeretlen WordPress adminokról szóló cikk bemutatja, milyen kapcsolódó módosításokat kell keresni.

Visszaállítás adatbázisból

Ha nincs WP-CLI, phpMyAdminból vagy más adatbáziskezelőből vizsgáld meg a felhasználói táblát. A prefix nem mindig wp_, ezért a valódi táblanév eltérhet.

SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC;

A szerepkörök a wp_usermeta táblában találhatók. Ne másolj be internetről ellenőrizetlen SQL-t, és ne hagyj gyenge MD5 jelszót tartósan az adatbázisban. Biztonságosabb az e-mail-címet helyreállítani, majd a WordPress saját jelszó-visszaállítását használni, vagy WP-CLI-vel frissíteni.

Multisite esetén a jogosultságok kezelése eltér, és a super admin külön vizsgálatot igényel.

Mi van, ha a login loopol?

A belépési hurok gyakran cookie-, domain- vagy cache-probléma, de feltörés után malware is okozhatja. Ellenőrizd:

• a siteurl és home értékeket;
• a HTTPS és proxy beállításokat;
• a böngésző sütijeit;
• az objektum- és oldalcachet;
• a wp-config.php cookie- és URL-konstansait;
• a login hookokat módosító plugineket és mu-plugineket.

Pluginhiba kizárásához SFTP-n ideiglenesen átnevezhető a problémás plugin könyvtára. Az összes plugin könyvtárának átnevezése azonban incidens közben eltüntetheti a tünetet anélkül, hogy megmondaná, melyik komponens vagy malware volt felelős.

403, 500 és fehér oldal

A 403 jöhet WAF-szabályból, .htaccess módosításból, fájljogosultságból vagy IP-tiltásból. Az 500-as hiba mögött lehet sérült PHP, inkompatibilis frissítés vagy szándékosan hibásra írt plugin. Nézd meg a PHP error logot és a webszerver naplóját, ne a böngésző üzenetéből találgass.

Az admin ideiglenes helyreállításához előfordulhat, hogy FTP-n kell működőképes állapotba hozni az oldalt. Ezután már telepíthető a WebShield komponense, és elindítható az automatizált fájl- és állapotvizsgálat.

A malware elrejtheti az adminokat

A WordPress felület nem hiteles biztonsági leltár. Malware módosíthatja a pre_user_query, users_list_table_query_args vagy más hookok viselkedését, így egy felhasználó létezik az adatbázisban, de nem jelenik meg az adminlistában. Ugyanez történhet pluginokkal és sablonokkal is.

Ezért az adatbázist és a fájlrendszert a WordPress felületétől függetlenül is ellenőrizni kell. A WebShield ilyen változásokat akkor is észlelhet, ha az admin UI elrejti őket.

Beléptél. Most kezdődik a tisztítás

Ellenőrizd az aktív munkameneteket és alkalmazásjelszavakat

A jelszó cseréje nem feltétlenül érvénytelenít minden más hozzáférési módot. Nézd át az alkalmazásjelszavakat, API-kulcsokat, XML-RPC használatot és az aktív session tokeneket. Kényszeríts kijelentkezést minden eszközről, majd csak azokat az integrációkat állítsd vissza, amelyek tulajdonosa és célja ismert.

Egy támadó nem mindig böngészőből lép be. Használhat ellopott alkalmazásjelszót, WooCommerce API-kulcsot vagy kompromittált integrációt. Az access logban keresd az adminműveletek, REST API és XML-RPC kérések forrását.

E-mail és felhasználói adatok manipulálása

Ellenőrizd, nem változott-e meg az admin e-mail-címe, megjelenített neve vagy jelszó-visszaállítási folyamata. A támadó átírhatja az SMTP plugint, letilthatja a kimenő levelet, vagy saját címére továbbíthatja az értesítést. Nézd át a tárhely levelezési szabályait és a domain DNS rekordjait is.

A felhasználói tábla módosítási ideje önmagában nem látszik egyszerűen, ezért az adatbázisnapló, audit log és mentések összehasonlítása sokat számít. Ha nincs napló, fogalmazz óvatosan: a hozzáférés időpontja és módja nem bizonyítható teljes bizonyossággal.

Plugin okozta hiba vagy támadás?

Egy hibás frissítés is kizárhat az adminból. Különbséget a kronológia és a kapcsolódó jelek adnak. Ha közvetlenül egy ismert frissítés után PHP fatal error jelent meg, nincs ismeretlen fájl vagy felhasználó, valószínűbb a kompatibilitási hiba. Ha ugyanakkor furcsa POST kérések, új admin és módosult core fájl is látszik, incidensként kezeld.

A hibakereséshez átmenetileg bekapcsolható a naplózás úgy, hogy a hibák ne jelenjenek meg a látogatóknak:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

A debug.log érzékeny útvonalakat és adatokat tartalmazhat. A vizsgálat után kapcsold ki, és ne hagyd nyilvánosan letölthető helyen.

Helyreállítás után szigorítsd az adminvédelmet

Használj egyedi fiókokat, többtényezős hitelesítést és minimálisan szükséges jogosultságot. Ne legyen közös „admin” felhasználó ügynökség és ügyfél között. Korlátozd, ki telepíthet plugint és ki szerkeszthet fájlt az adminból. A DISALLOW_FILE_EDIT csökkenti annak esélyét, hogy egy megszerzett adminfiókból közvetlenül kódot írjanak a sablonba, de önmagában nem védelem egy sérülékeny plugin ellen.

Állíts riasztást szerepkörváltozásra, új adminra, jelszó- és e-mail-cserére. A bejelentkezési naplót külső helyen is őrizd meg, hogy a támadó ne tudja ugyanazzal a hozzáféréssel eltüntetni.

A hozzáférés helyreállítása után:

1. listázd és ellenőrizd az összes admint;
2. nézd át az aktív munkameneteket és kényszeríts kijelentkezést;
3. cseréld a salt értékeket;
4. ellenőrizd a pluginokat, sablonokat és mu-plugineket;
5. vizsgáld a cron feladatokat és az adatbázis-injektálást;
6. hasonlítsd össze a fájlokat tiszta forrásokkal;
7. azonosítsd a bejutási pontot;
8. csak tiszta állapot után cserélj újra minden jelszót.

Ha csak a jelszót állítod vissza, de a támadó backdoorja megmarad, rövid időn belül újra kizárhat. A visszafertőződés okairól szóló útmutató pontosan ezt a helyzetet bontja ki.

Sürgős üzleti oldalnál az első cél a kontrollált működőképesség, nem az admin képernyő bármi áron történő megnyitása. A bizonyítékok, a teljes tisztítás és a folyamatos monitorozás együtt adja vissza valóban a kontrollt.

• WordPress admin
• nem tudok belépni
• feltört WordPress
• admin helyreállítás