WordPress diagnosztika
Google Search Console „Biztonsági problémák” hiba – mit jelentenek a jelzések?
Google Search Console „Biztonsági problémák” hiba – mit jelentenek a jelzések?
A Google Search Console biztonsági problémák jelentése nem egy hagyományos SEO-hibalista. Ha itt megjelenik egy találat, a Google szerint a webhelyet feltörhették, kártékony kódot szolgálhat ki, vagy megtévesztő tartalommal veszélyeztetheti a látogatókat. A jelzéshez tartozó néhány URL csak minta, nem a teljes javítási feladat.
A legrosszabb reakció az, ha valaki kizárólag a felsorolt oldalt törli, majd azonnal felülvizsgálatot kér. A Search Console a tünet helyét mutatja. A támadás útvonalát, a backdoort és a további fertőzött fájlokat neked kell megtalálnod.
A jelentés három fő problémacsoportja
Feltört tartalom
Ide tartozhat a kódinjektálás, a támadó által létrehozott új oldal és a tartalommanipuláció. WordPressnél gyakori a gyógyszeres, szerencsejátékos vagy felnőtt tartalmú SEO-spam. Az is előfordul, hogy a normál látogató az eredeti oldalt látja, a Googlebot viszont spamet kap.
Ha a kereső tömegesen indexel ismeretlen URL-eket, olvasd el a Google által indexelt spamoldalak megállításáról szóló cikket is.
Malware és kéretlen szoftver
Ez lehet közvetlenül kiszolgált kártékony fájl, böngészőben futó fertőzött JavaScript, drive-by download vagy más domainről betöltött kompromittált komponens. Nem biztos, hogy a rosszindulatú fájl WordPress pluginban van. Kerülhet az uploads mappába, cache-be, ideiglenes könyvtárba vagy akár egy szerveroldali konfigurációba.
Social engineering
Az oldal megbízható szolgáltatásnak adja ki magát, hamis bejelentkezést, frissítést, ügyfélszolgálati telefonszámot vagy letöltést kínál. Egy feltört WordPress oldalon ezt sokszor teljesen új könyvtárban létrehozott phishing oldal végzi. A főoldal eközben érintetlen maradhat.
Mit jelent a minta URL?
A Google hivatalos leírása szerint az érintett URL-ek listája nem feltétlenül teljes. Egy példa URL több dolgot jelenthet:
- azon az oldalon közvetlenül szerepel a fertőzött kód;
- egy közös sablonfájl minden oldalon betölti a payloadot;
- egy feltételes átirányítás csak ott aktiválódott a feltérképezéskor;
- az URL már csak nyom, miközben a generáló backdoor máshol van;
- a külső script azóta megváltozott, ezért te nem tudod reprodukálni.
Mentsd le a példákat, de ne szűkítsd rájuk a vizsgálatot. Nézd meg az azonos időben módosult fájlokat, a webszerver access logját és azt is, melyik HTTP kérés előzte meg a változást.
Gyors vizsgálati lista WordPresshez
Először dokumentálj. Írd fel a probléma pontos nevét, az első észlelés idejét és a minta URL-eket. Készíts fájl- és adatbázismentést, majd vizsgáld meg:
Ismeretlen adminok és friss felhasználók
Új vagy kikapcsoltnak látszó pluginok
wp-content/mu-plugins és drop-in fájlok
PHP fájlok az uploads könyvtárban
wp_options autoload értékek
wp_posts és wp_postmeta injektált scriptek
WordPress cron események
.htaccess és webszerver-konfiguráció
Keress obfuszkációt és dinamikus kódfuttatást, de ne törölj automatikusan minden találatot:
rg -n "base64_decode|gzinflate|eval\(|shell_exec|assert\(" public_html
find public_html -type f -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n'
Ezek indikátorok, nem ítéletek. Egy legitim plugin is használhat kódolást, és a malware is elkerülheti ezeket a függvényeket. A fájldátum ráadásul manipulálható. A biztos fertőzésvizsgálatról szóló cikk részletesebb ellenőrzési pontokat ad.
Miért lehet üres a jelentés, miközben még látszik a figyelmeztetés?
A Safe Browsing, a Search Console és a Chrome figyelmeztetési adatai nem mindig ugyanabban a pillanatban frissülnek. Az is lehet, hogy a Google algoritmikusan észlelt egy problémát, de nem mutat kézzel felülvizsgálható elemet. Ellenőrizd a Safe Browsing Transparency Reportot, a Search Console üzeneteket, a Kézi műveletek jelentését és a konkrét URL-eket is.
Fordított helyzet is előfordul: te már nem látod a fertőzést, a jelentés azonban még aktív. Ez nem bizonyítja, hogy téves a Google jelzése. A feltételes malware lehet, hogy éppen nem neked szolgál ki tartalmat.
A tisztítás ne a riport „kipipálásáról” szóljon
Példa: kódinjektálás egy plugin végpontján keresztül
Tegyük fel, hogy a jelentés egyetlen furcsa URL-t mutat, miközben a webhely normálisan működik. Az access logban az URL első feltérképezése előtt egy ismeretlen IP több POST kérést küldött egy plugin AJAX végpontjára. Ugyanabban a percben létrejött egy PHP fájl az uploads alatt, majd egy cron esemény. A sablon header.php fájljába csak később került a látogatóknak szánt script.
Ebben a helyzetben a header.php tisztítása és a minta URL törlése kevés. Az uploads loader, a cron, a sérülékeny végpont és az esetleges admin is az incidens része. A napló és a fájlváltozás sorrendje mutatja meg az ok-okozati kapcsolatot.
Cloaking vizsgálata
A feltört tartalom gyakran mást ad a Googlebotnak, mobilnak vagy keresőből érkező látogatónak. Kérd le ugyanazt az URL-t több fejléccel, és hasonlítsd össze a válasz státuszát, átirányításait és külső erőforrásait. Ne csak a végső HTML-t nézd: a 302-es lánc, a Location fejléc és a JavaScript által indított navigáció is számít.
curl -sSIL https://example.com/gyanus-url
curl -sSIL -A 'Googlebot' https://example.com/gyanus-url
curl -sSIL -e 'https://www.google.com/' https://example.com/gyanus-url
CDN, nyelvválasztó és A/B teszt is okozhat eltérést. Az eltérés akkor IOC, ha nem illeszkedik az ismert működéshez vagy veszélyes célra vezet.
Kézi művelet és biztonsági probléma nem ugyanaz
A Kézi műveletek jelentés keresési spam-szabálysértést jelez, a Biztonsági problémák jelentés pedig feltörést, malware-t vagy megtévesztő működést. Egy kompromittált webhelyen mindkettő megjelenhet, és eltérő javítási, illetve felülvizsgálati folyamat tartozhat hozzájuk. A Search Console URL-eltávolító eszköze sem tisztít: ideiglenesen elrejthet találatokat, de a backdoor és a generáló mechanizmus megmarad.
A naplók hiánya is információ
Olcsó tárhelyen előfordul, hogy csak néhány napnyi access log áll rendelkezésre. Ilyenkor nem lehet biztosan kijelenteni, hogy mi volt a belépési pont vagy hozzáfértek-e adatokhoz. Használj fájl-összehasonlítást, adatbázis-időpontokat és más rendszerek naplóit, de a következtetések bizonytalanságát dokumentáld.
A következő időszakra növeld a megőrzést, és a naplókat lehetőleg külső helyre továbbítsd. A támadó a helyi naplót is törölheti, ha megfelelő jogosultságot szerez.
Utóellenőrzés több időpontban
Egy egyszeri tiszta scan kevés egy olyan malware ellen, amely óránként vagy naponta aktiválódik. Ellenőrizd az oldalt közvetlenül a tisztítás után, majd cronfutás, forgalmi csúcs és legalább egy teljes nap elteltével. Figyeld a fájlrendszert, adminokat, kimenő kapcsolatokat és a Search Console új minta URL-jeit.
A 2 óránkénti inkrementális mentés itt forenzikai előny is: kisebb időablakban lehet megkeresni, mikor és milyen változás történt, miközben nem kell egy teljes napi adatot visszagörgetni.
A teljes oldal állapotát kell visszaállítani. Hasonlítsd össze a core fájlokat a hivatalos csomaggal, a pluginokat és sablonokat tiszta forrással, vizsgáld meg az egyedi komponenseket, majd keresd meg a perzisztenciát. Cseréld a hozzáféréseket, frissítsd vagy távolítsd el a sérülékeny komponenst, és csak tiszta állapotban nyisd vissza az oldalt.
Ha a tárhelyszolgáltató is küldött listát, ne kezeld azt teljes leletként. A tárhelyszolgáltatói vírusriasztás általában szintén mintákat ad.
Milyen bizonyíték kell a felülvizsgálathoz?
Jegyezd fel:
- a fertőzés típusát és helyét;
- az eltávolított fájlokat, rekordokat és felhasználókat;
- a kijavított sérülékenységet vagy kompromittált hozzáférést;
- a jelszó- és saltcserét;
- az utóellenőrzés módszerét;
- azt, hogyan akadályozod meg az újrafertőződést.
A Google Security Issues dokumentációja szerint a felülvizsgálat néhány naptól akár több hétig is tarthat a probléma típusától függően. Ezt nem lehet megbízhatóan gyorsítani egy újabb, tartalom nélküli kérelemmel.
A WebShield ilyen helyzetben nem csak scannel. A fájlváltozásokat és a bejövő HTTP kéréseket együtt vizsgálja, figyeli az új adminokat, pluginokat és sablonokat, majd a tisztítás után is monitoroz. Ez a különbség a jelentés eltüntetése és az incidens tényleges lezárása között.