Feltört WordPress oldal helyreállítása keresési szempontból: mi a teendők sorrendje

Scheo · 2026-09-25 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A feltört oldal egyszerre két baj. Az egyik a szerveren ül, a másik a Google indexében, és a kettő nem egy tempóban gyógyul. A kódot jó esetben egy délután alatt kitakarítod, a keresési következmények viszont hetekig kísértenek. Az alábbi sorrend abból indul ki, hogy mindkettővel foglalkozni kell, csak nem egyszerre és nem azonos sürgősséggel.

Mit csinálj az első órában, ha kiderül, hogy feltörték az oldalt?

Rövid válasz. Izoláld az oldalt, és ne kezdj el takarítani, mert a takarítás első mozdulata pont azt semmisíti meg, amiből később megtudod, hol jött be a támadó.

Az izolálás nem azonos a teljes lekapcsolással. Gyakorlatban ez annyit tesz, hogy a látogatók felé ideiglenes karbantartási állapotot adsz vissza 503-as státuszkóddal, a saját IP-dről viszont továbbra is eléred az oldalt. Hivatalosan igazolt, hogy a Google dokumentációja szerint a rövid ideig tartó 503-as válasz a szokásos karbantartás jelzése, a keresőrobot ilyenkor később visszatér. A tartósan fennálló 503 már más kategória, ezért ez néhány órás eszköz, nem heti megoldás.

Az első órában ezek férnek bele.

• Jegyezd fel percre pontosan, mikor és miből vetted észre a fertőzést, és mit láttál (átirányítás, idegen oldal, figyelmeztetés a keresőben).
• Állítsd le a WordPress ütemezett feladatait és a külső cronhívást, különben a kártevő újratelepíti magát takarítás közben.
• Tiltsd le a PHP futtatását a feltöltési mappában szerverszinten.
• Zárd le az adminfelületet IP-korlátozással vagy szerveroldali jelszóval.
• Szólj a tulajdonosnak, hogy ne küldjön ki aznap hírlevelet és ne indítson hirdetést az oldalra.

Saját tapasztalat. A pár órás izolálás rendre kevesebb kárt okoz, mint az a fél nap, amíg a támadó által generált több ezer spamoldal bekerül az indexbe. A visszanyert forgalom nem éri meg a később napokig tartó tisztogatást.

Miért ments bizonyítékot, mielőtt hozzányúlsz a fájlokhoz?

Rövid válasz. Mert a fertőzött állapot az egyetlen forrás arról, hogyan jutottak be, és takarítás után ezt már nem tudod rekonstruálni.

Készíts teljes másolatot a fájlrendszerről és az adatbázisról, külön névvel, dátummal, és semmiképp ne a meglévő biztonsági mentés helyére. Mentsd le a webszerver hozzáférési és hibanaplóit, az FTP vagy SFTP naplót, és ha a tárhelyszolgáltató ad ilyet, a belépési előzményeket is. Vedd ki a wp_users és wp_usermeta táblák pillanatképét, valamint a telepített bővítmények és sablonok verziólistáját.

A naplóban az a sor ér a legtöbbet, ahol egy POST kérés fut le olyan fájlra, aminek nem kellene léteznie, vagy ahol egy ismert bővítmény végpontja szokatlanul sokszor szerepel. A fájlok módosítási ideje szintén támpont, bár szakmai feltételezés, hogy ezt a fejlettebb kártevők szándékosan hamisítják, ezért önmagában nem elég bizonyíték.

Ha személyes adat is érintett lehet, a mentés jogi szempontból is számít, mert az adatvédelmi bejelentés elkészítéséhez tudni kell, milyen adatokhoz lehetett hozzáférni. Ezt a részt érdemes időben jelezni a tulajdonosnak, mert nem marketinges döntés.

Mi a tisztítás helyes sorrendje WordPress alatt?

Rövid válasz. Cserélj, ne foltozz. A mag, a bővítmények és a sablon friss forrásból történő újratelepítése gyorsabb és biztosabb, mint a fertőzött fájlok egyenkénti javítása.

A sorrend, ami a gyakorlatban bevált, így néz ki.

1. WordPress mag újratelepítése az eredeti csomagból, a wp-content érintése nélkül.
2. Minden bővítmény és sablon törlése, majd újratelepítése a hivatalos forrásból, az aktuális verzióval. Amit nem használ az oldal, az ne kerüljön vissza.
3. Egyedi fejlesztésű sablon esetén fájlszintű összehasonlítás a verziókezelőben lévő tiszta állapottal.
4. A wp-content/uploads átvizsgálása futtatható kiterjesztésekre, mert ott csak média fájlnak van helye.
5. A rejtett belépési pontok ellenőrzése, tehát a mu-plugins mappa, az object-cache.php, az advanced-cache.php és a wp-config.php eleje és vége.
6. Az adatbázis átnézése, mert a takarítás leggyakrabban itt marad félbe.

Ellenőrzésre a WP-CLI a leggyorsabb, a wp core verify-checksums és a wp plugin verify-checksums --all megmutatja, mely fájlok térnek el a hivatalos kiadástól. Az egyedi kódban a klasszikus minta így kereshető.

grep -rEl 'eval\(base64_decode|gzinflate\(base64|str_rot13\(' wp-content/

Az adatbázisban nézd meg a wp_options tábla siteurl és home értékét, az active_plugins sort, a bejegyzésekbe szúrt script elemeket, és azt, hogy nem jött-e létre új adminisztrátor. Utóbbi a wp user list --role=administrator paranccsal egy másodperc alatt látszik.

Miért kevés a jelszócsere, és mit kell még lecserélni?

Rövid válasz. Mert a támadó ritkán a jelszót viszi el, sokkal gyakrabban olyan hozzáférést hagy hátra, ami a jelszótól független.

A teljes csereligeta ennél hosszabb, mint amire a legtöbben számítanak. Cseréld a wp-config.php biztonsági sóit, ettől minden aktív munkamenet azonnal érvénytelen lesz, a WP-CLI-ben ez a wp config shuffle-salts. Utána jön az adatbázis felhasználója és jelszava, az FTP, SFTP és SSH belépés, a tárhelypanel, az összes WordPress adminfiók, és az alkalmazásjelszavak, amiket a felhasználói profilban külön kell visszavonni.

Ezen felül nézd át a külső kulcsokat, tehát az SMTP-adatokat, a fizetési és szállítási modulok API-kulcsait, a webhook végpontokat. Saját tapasztalat, hogy a visszatérő fertőzések jó része nem új támadás, hanem egy ottfelejtett kulcs vagy egy létrehozott SSH publikus kulcs.

Egy pont, ami szinte mindig kimarad. Nyisd meg a Search Console tulajdonosi listáját, és nézd meg, nem került-e rá idegen felhasználó vagy idegen igazolási mód. Ha a támadó tulajdonosként bejegyezte magát, látja a riportokat, és eltávolítási kérelmet is beküldhet az oldalad URL-jeire. Ugyanez vonatkozik a DNS TXT rekordokra, ahol egy régi igazoló sor évekig ott maradhat.

Hogyan deríted ki, mit csinált a támadó a keresési oldaladdal?

Rövid válasz. Abból, amit a keresőrobot lát, nem abból, amit te látsz böngészőben, mert a mai fertőzések nagy része felhasználótól függően viselkedik másként.

Négy tipikus keresési kár fordul elő. Beszúrt spamoldalak, amiket a támadó a te domainedről szolgál ki, jellemzően egy új mappa vagy egy paraméteres URL alatt. Feltételes átirányítás, ami csak akkor indul, ha a látogató keresőből érkezik vagy mobilon nyitja meg. Átírt sitemap, amiben a te oldalaid mellett idegen URL-ek sorakoznak. Végül a sablonba épített rejtett link, ami a láblécben, fehér szövegszínnel, egy display tulajdonsággal elrejtve ül.

A felderítéshez ezeket futtasd le.

• A Search Console Indexelt oldalak riportjában nézd át az újonnan indexelt URL-eket, és rendezd dátum szerint.
• A Teljesítmény riportban szűrj olyan keresési kifejezésekre, amiknek semmi közük az üzlethez, ezek árulják el a spam témáját.
• Az URL-ellenőrző eszközben futtass élő tesztet a gyanús oldalakra, és a megjelenített HTML-ben keresd az idegen tartalmat.
• Kérd le a sitemap fájlt közvetlenül, és vesd össze azzal, amit a sitemap-bővítményed generál.
• Kérd le a főoldalt Googlebot felhasználói ügynökkel és keresőoldali hivatkozóval, mert a feltételes átirányítás csak így jön elő.

404 vagy 410 a beszúrt URL-eknek?

Rövid válasz. Ha biztosan tudod, hogy az URL a támadótól származik és soha nem lesz rajta valódi tartalom, a 410 a pontosabb válasz, minden más esetben maradj a 404-nél.

Hivatalosan igazolt, hogy a Google mindkettőt eltávolításként kezeli, és a dokumentáció szerint a 410-re valamivel gyorsabban reagál, mert az véglegességet jelez. Szakmai feltételezés, hogy ez a különbség néhány nap nagyságrendű, tehát nem ettől múlik el a probléma, viszont ingyen van, így érdemes kihasználni.

Apache alatt egy mintaillesztéssel kiszolgálható a teljes beszúrt ág, a G jelző jelenti a 410-et.

RewriteRule ^(wp-content/uploads/cheap-|kupon-sale/) - [G,L]

Nginx alatt ugyanez egy blokk.

location ^~ /kupon-sale/ { return 410; }

Három hiba kerülendő. Ne irányítsd át a beszúrt URL-eket a főoldalra, mert abból lágy 404 lesz, ami lassabban tisztul. Ne tiltsd le őket a robots.txt-ben, mert akkor a keresőrobot le sem kéri az oldalt, és sosem látja meg a 410-es választ. Az ideiglenes eltávolítási eszközt pedig csak arra használd, amire való, ez néhány hónapra elrejti az URL-t a találatokból, de nem törli az indexből.

Mit tartalmazzon a Search Console ellenőrzőlista és az újravizsgálati kérelem?

Rövid válasz. A kérelem akkor jó, ha egy külsős ember is el tudja olvasni belőle, mi történt, mit javítottál, és mi akadályozza meg az ismétlődést.

Beküldés előtti ellenőrzőlista.

1. A Biztonsági problémák riport minden tétele megvan és beazonosítva, tehát tudod, melyik URL-ek miatt jelölt meg a rendszer.
2. Az összes megjelölt URL valóban tiszta, élő teszttel ellenőrizve, nem csak a gyorsítótárazott másolat alapján.
3. A feltételes átirányítás megszűnt mobilon, asztali gépen és keresőből érkezve is.
4. A sitemap újragenerálva, benne kizárólag a saját URL-ek.
5. A robots.txt visszaállítva az eredeti tartalomra.
6. A beszúrt URL-ek 410-et adnak, és nincsenek letiltva a robots.txt-ben.
7. A tulajdonosi lista tiszta, idegen felhasználó és idegen igazolási mód nélkül.
8. A karbantartási 503 kikapcsolva, az oldal normálisan kiszolgál.

A kérelem szövege legyen tárgyszerű. Írd le, mikor észlelted, mi volt a belépési pont (például egy elavult bővítmény ismert sérülékenysége), mit cseréltél, milyen hozzáféréseket állítottál vissza, és milyen védelmet vezettél be. Ne ígérj semmit, és ne kérj méltányosságot. Saját tapasztalat, hogy a hiányosan kitakarított oldal újra elutasított kérelme után a következő kör mindig lassabb, ezért jobban megéri egy nappal később beküldeni, alaposabban.

Mit ellenőrizz 30 nappal később?

Rövid válasz. Azt, hogy a fertőzés nem jött vissza csendben, és hogy az index tényleg letisztult, nem csak a figyelmeztetés tűnt el.

Egy hónappal a takarítás után ezek a pontok árulkodóak.

• Az Indexelt oldalak riportban a nem indexelt kategóriák aránya, itt kell látszódnia a 410-es URL-ek tömeges kiesésének.
• A találatokban maradt spamcímek és leírások, mert a címke néha tovább él, mint maga az oldal.
• A Teljesítmény riportban a korábbi spamkifejezések megjelenéseinek lecsengése.
• A fájlok módosítási ideje, tehát nem íródott-e felül valami a takarítás óta emberi beavatkozás nélkül.
• Az adminisztrátorok listája és az alkalmazásjelszavak.
• A naplóban visszatérő kérések a már törölt kártevő fájlok címére, ez azt jelenti, hogy a támadó még próbálkozik.
• A korábbi kulcsoldalak organikus forgalma, hogy lásd, mennyi jött vissza a kiesésből.

Ha a spamoldalak nagy része még mindig indexben van, az általában kettőn múlik. Vagy nem mindegyik ad 410-et, vagy a robots.txt kizárja őket a lekéréstől. Mindkettő ellenőrizhető néhány perc alatt.

Miért tart hetekig a keresési takarítás, és hogyan mondd el ezt a tulajdonosnak?

Rövid válasz. Mert a keresőnek minden egyes beszúrt URL-t külön kell újra lekérnie ahhoz, hogy törölje, és ennek a tempóját nem te állítod be.

Ez az a pont, ahol a legtöbb konfliktus keletkezik, és saját tapasztalat szerint majdnem mindig azért, mert senki nem mondta el előre. A tulajdonos abban a hitben van, hogy ha a fejlesztő kitakarította a szervert, akkor másnap minden a régi. A valóságban a kód tisztulása és az index tisztulása két külön folyamat, és a második lassabb. Néhány ezer beszúrt URL feldolgozása jó eséllyel hetekbe telik, és ez alatt a márkanévre keresve még előjöhet furcsa találat.

Amit érdemes az első napon leírni a tulajdonosnak, az három mondat. A szerver takarítása rövid, az index takarítása hosszabb. A köztes időben látszódhatnak még régi spamtalálatok, ez nem azt jelenti, hogy visszatért a fertőzés. A keresési láthatóság visszaépülése fokozatos, és nem garantált, hogy minden oldal ugyanoda tér vissza, ahol a támadás előtt állt.

Ez a három mondat előre elmondva szakmai tájékoztatás. Ugyanez három hét múlva, kérdésre elmondva már mentegetőzésnek hangzik, pedig szó szerint ugyanaz a tartalom.

Források és további olvasnivalók

• Google Search Central, Feltört oldalak dokumentációja és a hackelt tartalommal kapcsolatos hibaelhárítási útmutatók
• Google Search Central, Újravizsgálati kérelem beküldése
• Google Search Central, A HTTP állapotkódok és a Google Kereső kapcsolata
• Google Search Console Súgó, Biztonsági problémák jelentés és az Eltávolítások eszköz
• WordPress.org, Hardening WordPress és a FAQ My site was hacked fejezet
• WP-CLI kézikönyv, core verify-checksums és config shuffle-salts parancsok
• OWASP, Web Application Security Testing Guide
• IETF RFC 9110, HTTP Semantics (a 404 és 410 státuszkódok meghatározása)
• MDN Web Docs, HTTP response status codes