WordPress incidenskezelés
Google Safe Browsing piros képernyő WordPress oldalon – hogyan tüntethető el?
Google Safe Browsing piros képernyő WordPress oldalon – hogyan tüntethető el?
A Google Safe Browsing veszélyes weboldal figyelmeztetés nem egy kikapcsolható böngészőhiba. A piros képernyő azt jelzi, hogy a Google rendszere kártevőt, adathalászatot, kéretlen szoftvert vagy feltört tartalmat észlelt az oldalon. Ilyenkor a látogatók jelentős része visszafordul, a hirdetések leállhatnak, és a keresési találat mellett is megjelenhet a figyelmeztetés.
A helyes sorrend nem az, hogy először felülvizsgálatot kérsz. Előbb meg kell találni és el kell távolítani a fertőzést, le kell zárni a támadás útvonalát, majd bizonyítani kell, hogy az oldal már tiszta. Ha a piros képernyő sürgősen jelent meg, az első 30 percben elvégzendő lépések segítenek megőrizni a használható nyomokat.
Mitől jelenik meg a piros figyelmeztetés?
A Google többféle biztonsági problémát különböztet meg. A tulajdonos számára mind hasonlóan nézhet ki, technikailag mégsem ugyanazok:
- rosszindulatú JavaScript vagy PHP kód töltődik be;
- a webhely másik, kártékony domainre irányít;
- adathalász űrlap próbál jelszót vagy bankkártyaadatot megszerezni;
- a támadó spamoldalakat hozott létre;
- fertőzött letöltés vagy kéretlen szoftver kerül a látogató gépére;
- harmadik féltől betöltött script vagy hirdetés vált veszélyessé.
A Google Security Issues jelentése gyakran csak minta URL-eket mutat. Ezek nem feltétlenül jelentik az összes fertőzött oldalt. Ha egyetlen példát látsz, attól még a támadó lehet, hogy száz generált URL-t, több backdoort és egy rejtett admin felhasználót hagyott hátra.
Miért nem elég, ha nálad nem jelenik meg?
Gyakori mondat: „Nálam rendesen betölt az oldal.” Ez semmit nem bizonyít. A kártevő feltételekhez kötheti a működését:
- csak mobiltelefonról irányít át;
- csak Google-ből érkező látogatónak jelenik meg;
- adminisztrátorként bejelentkezve kikapcsol;
- adott ország vagy IP-tartomány esetén aktiválódik;
- sütivel megjegyzi, hogy egyszer már lefutott;
- csak néhány száz kérésenként támad.
Ezért az inkognitó ablakban végzett egyetlen próba nem vizsgálat. Meg kell nézni a forráskódot, a hálózati kéréseket, a fájlváltozásokat, az adatbázist és a szervernaplókat is. A WordPress átirányításokról szóló útmutató részletesen bemutatja a feltételes átirányítások tipikus működését.
Az első technikai ellenőrzések
Nyisd meg a Search Console Biztonsági problémák jelentését, és jegyezd fel a probléma típusát, az első észlelés dátumát, valamint a minta URL-eket. Ezután készíts mentést a jelenlegi állapotról. A fertőzött mentés nem visszaállításra kell, hanem bizonyítéknak: később összehasonlítható vele, mi változott.
Ellenőrizd legalább ezeket:
wp-config.php
.htaccess
index.php
wp-content/plugins/
wp-content/themes/
wp-content/uploads/
wp-content/mu-plugins/
wp-admin/ és wp-includes/
Az uploads könyvtárban található PHP fájl többnyire erős gyanújel. Ugyanígy gyanús egy nem ismert plugin, frissen létrejött admin, szokatlan cron feladat vagy olyan wp_options rekord, amely hosszú kódolt karakterláncot tartalmaz.
Core fájloknál használható a WP-CLI ellenőrzése:
wp core verify-checksums --include-root --version=$(wp core version)
wp plugin verify-checksums --all --strict
A sikeres core ellenőrzés nem jelenti azt, hogy az egész oldal tiszta. A parancs nem igazolja az egyedi vagy prémium komponenseket, az adatbázist, az admin felhasználókat és az összes feltöltött fájlt. A WordPress hivatalos checksum dokumentációja is az ismert core fájlok összevetéséről szól, nem teljes incidensvizsgálatról.
Hogyan működik egy ilyen fertőzés?
A támadó gyakran sérülékeny plugint, ellopott adminjelszót vagy kiszivárgott tárhely-hozzáférést használ. Az első bejutás után ritkán elégedik meg egyetlen módosítással. Létrehoz egy vagy több visszajáratot, hogy a látható kód törlése után is visszatérjen.
Tipikus lánc:
- Egy sérülékeny végpont fájlfeltöltést vagy távoli kódfuttatást enged.
- Megjelenik egy kisméretű PHP loader.
- A loader további kódot tölt le, admin felhasználót vagy cron feladatot hoz létre.
- A látogatók egy része átirányítást vagy adathalász oldalt kap.
- A Google feltérképezője észleli a viselkedést, majd veszélyesnek jelöli a domaint.
Ha csak a negyedik lépéshez tartozó JavaScriptet törlöd, a loader újra létrehozhatja. Ez az oka annak, hogy a piros képernyő sokszor néhány nap múlva visszatér.
A tisztítás helyes sorrendje
Először korlátozd a károkat. Ha az oldal aktívan adathalász vagy kártékony fájlt terjeszt, ideiglenesen tedd elérhetetlenné a nyilvánosság számára, de őrizd meg a naplókat. Ezután:
- készíts állapotmentést és gyűjtsd össze a naplókat;
- azonosítsd a fertőzött és ismeretlen fájlokat;
- vesd össze a core, plugin- és sablonfájlokat tiszta forrással;
- vizsgáld át az adatbázist, cron feladatokat és adminokat;
- távolítsd el az összes perzisztenciát;
- javítsd vagy kapcsold ki a bejutást lehetővé tevő komponenst;
- cseréld le a WordPress-, tárhely-, adatbázis- és SFTP-jelszavakat;
- frissítsd a WordPress salt értékeket;
- ellenőrizd az oldalt több böngészési helyzetből;
- csak ezután kérj Google-felülvizsgálatot.
A részletes professzionális WordPress tisztítási folyamat megmutatja, miért kell a fájlok mellett a kiváltó HTTP kéréseket és a későbbi változásokat is figyelni.
Mikor tekinthető tisztának az oldal?
Nem attól, hogy a főoldal betölt. A minimális bizonyíték ennél több:
- a fájl-összehasonlítás nem mutat megmagyarázatlan eltérést;
- nincs ismeretlen admin, plugin, sablon vagy cron feladat;
- az adatbázisban nincs injektált script vagy spam;
- a szervernaplóban nem folytatódik ugyanaz a támadási minta;
- mobilról, keresőből érkezve és kijelentkezve sincs eltérő viselkedés;
- a sérülékeny belépési pont frissítve vagy eltávolítva lett;
- a tisztítás után újra futtatott ellenőrzés is tiszta.
A WebShield a fájlváltozásokat bejövő HTTP kérésekkel tudja összekapcsolni, figyeli az adminokat és az új komponenseket, valamint 2 óránként inkrementális mentést készít. Ez azért számít, mert a cél nem csupán a Google-jelzés eltüntetése, hanem annak megakadályozása, hogy ugyanaz a fertőzés újra létrejöjjön.
A felülvizsgálat nem tisztítóeszköz
Gyakori félresikerült javítások
Az első tipikus hiba egy régebbi mentés azonnali visszatöltése. Ez akkor működhet, ha bizonyítottan tudod, mikor történt a behatolás, a mentés valóban tiszta, és a bejutási pontot a visszaállítás előtt lezárod. Ha ugyanaz a sérülékeny plugin és ugyanazok a jelszavak kerülnek vissza, a támadó ugyanazon az ajtón térhet vissza. Webshopnál ráadásul a megrendelések és készletváltozások elvesztése külön üzleti kárt okoz.
A második hiba egyetlen biztonsági plugin „clean” eredményének elfogadása. A scanner futhat a már manipulált WordPress környezetben, nem férhet hozzá minden fájlhoz, kihagyhat prémium komponenst, és nem feltétlenül látja az adatbázisban vagy cronban tárolt perzisztenciát. A mentés vagy tisztítás dilemmájáról szóló cikk segít eldönteni, melyik helyzetben melyik módszer indokolt.
Harmadik hiba az összes frissen módosított fájl törlése. Egy pluginfrissítés több száz legitim fájlt írhat át, miközben a támadó egy régi időbélyeget másolhat a backdoorra. A fájl tartalma, eredete, hash-e és a kapcsolódó kérések együtt adnak értelmezhető képet.
Adatbázisban és böngészőben keresendő IOC-k
A fájlrendszer mellett nézd meg a WordPress adatbázisát. Gyanús lehet a wp_options rekordban tárolt, hosszú Base64-szerű érték, ismeretlen JavaScript a widgetekben, átírt siteurl, váratlan admin-e-mail, vagy tömegesen létrehozott bejegyzés. Multisite esetén minden blog tábláit vizsgáld, ne csak a fő webhelyet.
A böngésző fejlesztői eszközeiben keresd az ismeretlen domainekre menő kéréseket, a document.location módosítását, dinamikusan létrehozott script elemeket és a service worker regisztrációkat. A service worker a szerver tisztítása után is befolyásolhat egy korábban fertőzött böngészőprofilt, ezért friss profilból is tesztelj.
Hasznos hálózati ellenőrzés:
curl -sS -D headers.txt -o page.html https://example.com/
curl -sS -A 'Googlebot' -e 'https://www.google.com/' https://example.com/ -o googlebot.html
curl -sS -A 'Mozilla/5.0 (Linux; Android 13)' https://example.com/ -o mobile.html
diff -u page.html googlebot.html
Az eltérés önmagában nem malware: reszponzív vagy személyre szabott oldal is adhat más HTML-t. Ismeretlen script, iframe vagy átirányítás viszont tovább vizsgálandó.
Mit kommunikálj az ügyfeleknek?
Ha az oldal ügyféladatot, bejelentkezést vagy fizetést kezel, a technikai javítás mellett incidensértékelés is kell. Vizsgáld meg, hozzáférhetett-e a támadó személyes adatokhoz, módosíthatta-e a fizetési folyamatot, és szükséges-e értesítés. Ne állítsd automatikusan, hogy „adat nem szivárgott”, ha nincsenek ezt bizonyító naplók.
A látogatóknak szóló tájékoztatás legyen tényszerű. Ne kérd meg őket a böngészőfigyelmeztetés megkerülésére, és ne tereld át őket egy ellenőrizetlen tartalék domainre. Ha átmeneti státuszoldalt használsz, az legyen külön, tiszta infrastruktúrán.
Megelőzés a jelzés eltűnése után
A szükséges minimum a menedzselt frissítés, egyedi és többtényezős hozzáférések, a nem használt komponensek eltávolítása, a PHP-futtatás korlátozása feltöltési könyvtárakban, sűrű mentés, központi naplózás és fájlváltozás-figyelés. A napi scanner önmagában későn jelezhet: a kár már az első sikeres kérés után megtörténik.
Állíts riasztást új adminra, pluginra, sablonra és módosuló kritikus fájlokra. Egy új komponensnél ne csak a nevét nézd meg; azt is, van-e valódi funkcionalitása, honnan származik és melyik kérés hozta létre. Így a következő incidensnél nem a Google piros képernyője lesz az első riasztásod.
A felülvizsgálati kérelemben röviden, konkrétan írd le, mit találtál, mit távolítottál el, melyik sérülékenységet zártad le, és milyen ellenőrzést futtattál. A „mindent kijavítottunk” mondat kevés információt ad. A Google külön jelzi, hogy csak valóban megtisztított oldalnál érdemes kérelmet küldeni; a sikertelen felülvizsgálat meghosszabbíthatja a figyelmeztetés idejét.
A pontos beküldési folyamatról külön útmutató készül. Addig a lényeg: ne a piros képernyőt próbáld elrejteni. A fertőzést szüntesd meg. Ha az oldal üzletileg kritikus, hirdetéseket futtat vagy ügyféladatokat kezel, az SOS incidenskezelés általában olcsóbb, mint több sikertelen, bizonyítékokat eltüntető saját tisztítási kör.