# Feltörték a WordPress oldalam — mit tegyek az első órában | RootCore LLC > Incidenskezelés lépésről lépésre: mit csinálj azonnal, mit ne csinálj soha, hogyan találod meg a bejutás módját, és hogyan állsz vissza úgy, hogy ne törjék fel újra. Oldal: https://cyber-security.rootcr.com/tudastar/feltort-wordpress/ Frissítve: 2026-08-20 --- # Feltörték a WordPress oldalam — mit tegyek az első órában? > **Röviden:** Ne törölj semmit, és ne állj vissza azonnal mentésből. Először szigeteld el az oldalt, rögzítsd a bizonyítékokat, majd derítsd ki, hogyan jutottak be — mert ha ezt kihagyod, a visszaállított oldalt napokon belül újra feltörik ugyanazon az úton. A helyes sorrend: elszigetelés, bizonyítás, ok megkeresése, tisztítás, jelszócsere, csak ezután visszakapcsolás. ## Előbb: mit NE csinálj Ez a három lépés az, amivel a legtöbben tönkreteszik a saját helyreállításukat. 1. **Ne töröld a gyanús fájlokat azonnal.** Azok a bizonyítékok. Ha eltűnnek, sosem derül ki, hogyan jutottak be — és nem tudod megakadályozni, hogy megint megtörténjen. 2. **Ne állj vissza rögtön mentésből.** Ha a mentés már fertőzött (és jellemzően az, mert a behatolás hetekkel korábbi), akkor a hátsó kaput állítod vissza. Ha pedig tiszta, de a bejutás módja megvan, akkor ugyanazon az úton visszajönnek. 3. **Ne jelentsd ki, hogy „csak egy fájl volt".** A WordPress-feltörések túlnyomó része több helyre szór: bővítménymappa, feltöltési könyvtár, `wp-config.php`, adatbázis, ütemezett feladatok, admin-felhasználók. ## Az első óra, sorrendben ### 1. Szigeteld el (0–5. perc) A cél, hogy a látogatók ne kapjanak kártékony tartalmat, és a támadó ne dolgozhasson tovább, de a bizonyítékok maradjanak meg. - Kapcsold az oldalt karbantartási módba, vagy tedd a webszervert olyan állapotba, hogy statikus üzenetet adjon. - Ne állítsd le a szervert teljesen, ha kerülhető: a memóriában lévő nyomok elvesznek. - Zárd le az adminisztrációs felületet IP-korlátozással. ### 2. Rögzíts (5–20. perc) Mielőtt bármihez hozzányúlnál, készíts pillanatképet: - Teljes fájlrendszer-másolat, időbélyegekkel együtt (`rsync -a` vagy pillanatkép a tárhelyen). - Adatbázis-mentés. - A webszerver naplói, legalább a behatolás feltételezett időpontja előtti hetekre. - A jelenlegi folyamatok, ütemezett feladatok és admin-felhasználók listája. Ez a másolat lesz az egyetlen lehetőséged arra, hogy később rekonstruáld, mi történt. ### 3. Keresd meg a bejutás módját (20–45. perc) Négy irányban érdemes nézni, ebben a sorrendben: | Hol | Mit keress | Mire utal | |---|---|---| | Fájlok módosítási ideje | Ami az utolsó frissítés után változott, főleg a `wp-content/uploads` alatt | Feltöltött webshell | | Webszerver-napló | POST kérések ismeretlen PHP-fájlokra, `wp-login.php` sorozatos hívása | Bejutás módja, időpontja | | Adatbázis | Ismeretlen admin-felhasználó, módosított `siteurl`, gyanús tartalom a bejegyzésekben | Perzisztencia | | Ütemezett feladatok | Ismeretlen `wp-cron` bejegyzés vagy rendszerszintű cron | Visszatérési útvonal | A tipikus okok sorrendben: elavult bővítmény ismert sérülékenységgel, gyenge vagy újrahasznált admin-jelszó, elavult PHP vagy WordPress, illetve egy másik oldal ugyanazon a tárhelyen (a legtöbb megosztott tárhelyen a fiókok elérik egymást). ### 4. Zárd le a hozzáféréseket (45–60. perc) Ha megvan a bejutás módja — vagy ha az idő szorít: - Cseréld az összes admin-jelszót, az FTP/SFTP-jelszót, az adatbázis-jelszót és a tárhely-fiók jelszavát. - Töröld az ismeretlen admin-felhasználókat. - Generálj új biztonsági kulcsokat a `wp-config.php`-ban (`AUTH_KEY` és társai) — ettől minden bejelentkezett munkamenet érvénytelen lesz, a támadóé is. - Nézd meg az API-kulcsokat és a webhook-titkokat: ha a `wp-config.php` kikerült, azok is kikerültek. ## A helyreállítás Az elszigetelés után jön a lassabb rész. Itt már nem az óra ketyeg, hanem az számít, hogy alapos legyél. 1. **Tiszta alap.** A WordPress-magot és minden bővítményt a hivatalos forrásból telepíts újra, ne a meglévő fájlokat javítsd. Ami nem hivatalos forrásból van (feltört prémium sablon, „nulled" bővítmény), az menjen ki. 2. **A saját tartalom átvizsgálva.** A feltöltési könyvtárban csak média legyen; ott PHP-fájlnak semmi keresnivalója. 3. **Adatbázis-tisztítás.** Beszúrt szkriptek a bejegyzésekben, gyanús `option` értékek, idegen felhasználók. 4. **Frissítés.** WordPress, bővítmények, sablon, PHP-verzió. 5. **Megerősítés**, hogy ne ismétlődjön: fájlszerkesztés kikapcsolása az adminban, PHP-futtatás tiltása a feltöltési könyvtárban, kétlépcsős azonosítás az adminfiókokon, [WAF a bejelentkezés és a `wp-admin` elé](/waf-konfiguracio/), automatikus biztonsági frissítések. 6. **Feketelista-ellenőrzés.** Ha a Google megjelölte az oldalt, a tisztítás után kérned kell a felülvizsgálatot, különben a figyelmeztetés megmarad a találatokban. ## Mikor kell bejelenteni? Ha személyes adat is érintett — és egy webshopnál vagy űrlapos oldalnál jellemzően igen —, akkor a GDPR szerint az adatvédelmi incidenst a tudomásszerzéstől számított **72 órán belül** be kell jelenteni a felügyeleti hatóságnak, hacsak nem valószínűsíthető, hogy nem jár kockázattal. Ha az érintettekre nézve magas a kockázat, őket is tájékoztatni kell. A pontos megítéléshez érdemes jogi tanácsot kérni — de a 72 órás órát a felfedezés indítja, nem a helyreállítás vége. Ezért is fontos a 2. lépés: bejelentéskor meg kell tudni mondani, mi történt, mikor, és milyen adatkör érintett. Naplók nélkül ez nem megy. ## Honnan tudod, hogy tényleg tiszta? Nem attól, hogy „már nem látszik a hiba". A gyakorlati mércék: - A fájlrendszerben nincs olyan futtatható fájl, ami nem a hivatalos telepítésből származik. - Az adminfelhasználók listája megegyezik azzal, amit vársz. - A naplókban a behatolás óta nincs újabb gyanús kérés. - Egy külső vizsgálat sem talál hátsó kaput. - És ami a legfontosabb: **meg tudod nevezni, hogyan jutottak be**, és azt az utat lezártad. Ha az utolsó pontra nem tudsz válaszolni, akkor a helyreállítás nem fejeződött be — csak eltűnt a tünet. ## Gyakori kérdések ### A tárhelyszolgáltatóm azt mondja, ő nem foglalkozik ezzel. Igaza van? Jellemzően igen. A tárhely az infrastruktúráért felel; ami az oldalon fut — WordPress, bővítmények, jelszavak — az a tiéd. Managed WordPress csomagnál ez részben átfedhet, de a szerződés dönti el, mit vállalnak. ### Elég, ha telepítek egy biztonsági bővítményt? Fertőzött oldalon nem. A biztonsági bővítmény ugyanabban a rendszerben fut, amit a támadó már ural — ki tudja kapcsolni vagy meg tudja kerülni. A bővítménynek a tisztítás **után** van értelme, megelőzésként. ### Mennyi idő ez az egész? Egy egyszerű eset (egy sérülékeny bővítmény, korán észrevéve) fél nap. Egy hónapok óta fertőzött, több oldalt futtató tárhely több nap. A leghosszabb rész mindig a bejutás módjának megkeresése — és pont ez az, amit nem szabad kihagyni. ### Vissza tudom állítani mentésből, ha nem tudom, hogyan törtek be? Vissza tudod, de nagy eséllyel újra feltörik, mert a sérülékenység ott marad. Ha muszáj gyorsan élesíteni, akkor a visszaállítással egyidejűleg zárd le a legvalószínűbb utakat: minden jelszó csere, minden frissítés, `wp-admin` IP-korlátozás, és a feltöltési könyvtárban PHP-futtatás tiltása. ### Van értelme utána külső vizsgálatnak? Van, mert a hátsó kapuk többsége nem látszik az oldalon. Egy [sérülékenységi vizsgálat](/penetracios-teszt/) a tisztítás után megmondja, maradt-e nyitva valami — és ez az egyetlen mód arra, hogy ne csak reméld, hogy vége. --- Ha most történik, és nem akarod egyedül csinálni: [írj nekünk](/#kapcsolat) — az első felmérés díjtalan, és az első órában azt is meg tudjuk mondani, mit ne csinálj.