Röviden: Ha feltörték a weboldalát, ez az ellenőrzőlista segít, hogy semmit se felejtsen el: először megfékezni és bizonyítékot menteni, utána megtalálni az okot és megtisztítani, majd megújítani az összes hozzáférést, ellenőrizni a kötelezettségeket, és dokumentáltan lezárni az incidenst. A sorrend fontos, mert aki először töröl, nyomokat veszít, aki pedig csak megtisztít a rés lezárása nélkül, újra támadás célpontja lesz.
Mire érvényes ez az ellenőrzőlista, ha feltörték a weboldalt
Az ellenőrzőlista a vezetőséghez, a tulajdonosokhoz és az IT-felelősökhöz szól, egy weboldal, egy webshop vagy egy PHP-webszerver elleni megerősített vagy valószínű támadás után. A PHP2Shell után is alkalmas, ha egy szerver a frissítés előtt elérhető volt, és vannak jelek a feltörésre.
Nem minden pont illik minden környezetre. Ennek ellenére dolgozza át teljesen a listát, és minden pontnál jegyezze fel, hogy elvégezték, nem alkalmazható, vagy nyitott. Ez a jegyzőkönyv később értékes a biztosítás, az adatvédelem és a belső utómunka számára.
Minden lépéshez írja be a dátumot, az időpontot, a felelős személyt és az eredményt. Ha több személy érintett, jelöljön ki egy személyt, aki vezeti a listát, és rögzíti a döntéseket.
1. fázis: azonnali megfékezés és mentés
- A kár korlátozása: Tegye a weboldalt karbantartási módba, vagy vegye le a hálózatról, ha a látogatók veszélyeztetettek, vagy adatok szivároghatnak ki. A BSI (a német Szövetségi Információbiztonsági Hivatal) a PHP2Shellnél azt javasolja, hogy a javítatlan webszervereket átmenetileg vegyék le a hálózatról, ha a frissítés nem lehetséges azonnal.
- Ne törölje semmit: Ne távolítson el fájlokat, ne telepítse újra a szervert, és ne ürítse a naplókat, mielőtt a nyomokat le nem mentették.
- Naplók mentése: Másolja az access-, error-, PHP-FPM- és rendszernaplókat egy másik rendszerre, és rögzítse az ellenőrző összegeket. A PHP2Shellről a szakmai sajtó azt javasolja, hogy a naplókat 2026. 10. 20-tól őrizze meg.
- Lemezkép mentése: Hozzon létre a fájlokról és az adatbázisról egy másolatot, virtuális szervereknél pillanatképet (snapshot) bizonyítási állapotként, és ne módosítsa.
- Felelősök tájékoztatása: Vonja be korán a vezetőséget, az adatvédelmi felelőst, a tárhelyszolgáltatót és ha van, a kiberbiztosítót. Sok biztosításnak bejelentési kötelezettségei vannak.
2. fázis: az ok megtalálása és a megtisztítás
- A behatolási pont megállapítása: Értékelje ki a naplókat, a fájlmódosításokat és a verziókat. Ellenőrizze magát a PHP-t, a CMS-t, a témákat, a bővítményeket, a hozzáférési adatokat és a szerverszolgáltatásokat. Ismert ok nélkül megmarad az ismételt támadás kockázata.
- A rés lezárása: Vigye a PHP-t javított verzióra (8.5.12, 8.4.27, 8.3.36 vagy 8.2.35, illetve a szolgáltató igazolt backportja), frissítse a CMS-t és a bővítményeket, indítsa újra az összes PHP-workert.
- Az időszak behatárolása: Határozza meg a gyanús tevékenység legkorábbi időpontját. Ez dönti el, mely mentések lehetnek tiszták, és mely adatok lehetnek érintettek.
- Hátsó ajtók eltávolítása: Ellenőrizze és távolítsa el a webshelleket, a feltöltési és gyorsítótár-mappákban lévő idegen PHP-fájlokat, a módosított alapfájlokat, a cron-feladatokat, az SSH-kulcsokat és a rendszerszolgáltatásokat. Cserélje az alapfájlokat tiszta forrásból.
- Az adatbázis megtisztítása: Távolítsa el az ismeretlen rendszergazdai fiókokat, a tartalmakban és beállításokban lévő bejuttatott szkripteket, valamint a spam-tartalmakat.
- Az újraépítés megfontolása: A szerver mélyreható feltörése esetén a friss, javított rendszeren, ellenőrzött adatokkal végzett újraépítés gyakran megbízhatóbb út, mint a futó rendszeren végzett megtisztítás.
3. fázis: hozzáférések megújítása és keményítés
- Jelszavak megváltoztatása: A CMS, a tárhelyfiók, a panel, az adatbázis, az FTP, az SFTP, az SSH és az e-mail esetében, mégpedig egy tiszta eszközről.
- Kulcsok és tokenek cseréje: Hozza létre újra az API-kulcsokat, a fizetési és szállítási szolgáltatások interfészeit, a CMS alkalmazáskulcsait, az SSH-kulcsokat és a szerveren lévő tanúsítványokat.
- Munkamenetek megszüntetése: Jelentkeztesse ki az összes aktív bejelentkezést a CMS-ben és a szolgáltatásoknál, és ellenőrizze a regisztrált kétfaktoros eszközöket.
- Kétfaktoros bejelentkezés aktiválása: Az összes admin hozzáféréshez, a tárhelyet, a domaint és a DNS-t is beleértve.
- A szerver megerősítése: Ellenőrizze és dokumentálja a PHP-beállításokat, a fájljogosultságokat, a feltöltési mappák végrehajtási tiltásait, a tűzfalat és a biztonsági fejléceket.
4. fázis: kötelezettségek, kommunikáció és lezárás
- A bejelentési kötelezettségek ellenőrzése: Ha személyes adatok érintettek lehetnek, a GDPR 33. cikke szerint szükség lehet egy 72 órán belüli bejelentésre. Az értékelés az adatvédelmi felelősre vagy ügyvédre tartozik. Az ágazati kötelezettségeket, például a NIS2 szerintieket, külön ellenőrizze.
- Feljelentés megfontolása: A rendőrség kiberbűnözés központi kapcsolattartó pontjai (Zentrale Ansprechstellen Cybercrime, Németország) felveszik a vállalkozások feljelentéseit. A lementett naplók ehhez fontos alapot jelentenek.
- Az ügyfelek és a Google tájékoztatása: Az érintetteket tárgyszerűen és egyeztetetten tájékoztassa. Ha a Google figyelmeztetést mutat, a megtisztítás után kérjen felülvizsgálatot, ahogy azt a Google-figyelmeztetés eltávolítása leírja.
- A lezárás dokumentálása és felügyelet: Rögzítse jelentésben az okot, az időszakot, az intézkedéseket és a nyitott pontokat, vezesse le a tanulságokat a vészhelyzeti tervhez, és a következő hetekben fokozottan felügyelje a rendszereket.
Gyakori hibák az utómunkánál
Sok incidens elhúzódik, mert az első izgalomban rossz helyen spórolnak vagy túl gyorsan cselekszenek. Ezeket a hibákat kerülje el:
- Csak a láthatót távolítja el: Egy törölt spam-oldal vagy egy eltávolított átirányítás nem bizonyítéka a tiszta weboldalnak. A hátsó ajtók gyakran észrevétlenek maradnak.
- A jelszavakat az érintett rendszerről változtatja meg: Ha a gépen vagy a szerveren még fut kártékony szoftver, az új hozzáférési adatok azonnal ismét kiszivároghatnak.
- Vakon visszatölt egy mentést: Lezárt rés és a mentés ellenőrzése nélkül a támadó gyorsan újra az ajtóban áll.
- A javítást felmentésnek tekinti: A javított PHP-verzióra való frissítés nem bizonyítja, hogy korábban nem történt semmi, és nem távolít el bejuttatott kártékony szoftvert.
- A kötelezettségeket túl későn ellenőrzi: A határidők az incidens tudomásszerzésével kezdődnek, nem a megtisztítás végével.
- Nincs dokumentáció: Jegyzőkönyv nélkül a biztosítók, hatóságok vagy ügyfelek kérdéseire később alig lehet válaszolni.
Ez az ellenőrzőlista nem pótol jogi tanácsadást. A bejelentési kötelezettségekkel, a felelősséggel vagy a biztosítással kapcsolatos kérdésekben forduljon az adatvédelmi felelőséhez, egy ügyvédhez vagy a biztosítójához.
Hogyan segít konkrétan a PHP SOS?
- Átvesszük a strukturált incidenskezelést (incident response), és Önnel együtt, pontról pontra, jegyzőkönyvvel végigvisszük az ellenőrzőlistát.
- Úgy mentjük a naplókat és a rendszerállapotokat, hogy a biztosítás, a hatóságok és egy lehetséges IT-forenzika számára felhasználhatók maradjanak.
- Lezárjuk a rést, megtisztítunk vagy újraépítünk, és a helyes sorrendben megújítjuk a hozzáféréseket.
- Záró jelentést adunk az okkal, az intézkedésekkel és az ajánlásokkal, és kívánságra ezután is felügyeljük a rendszereket.
Gyakori kérdések
Mi az első, amit tennem kell, ha feltörték a weboldalamat?
Őrizze meg a nyugalmát, ne töröljön semmit, és korlátozza a kárt. Szükség esetén vegye le a weboldalt a hálózatról vagy tegye karbantartási módba, és mentse a naplókat és a fájlokat, mielőtt megtisztít. Ezután jön az ok keresése és a megtisztítás.
Elég a weboldalt egy mentésből visszaállítani?
Többnyire nem. A mentés már tartalmazhat kártékony kódot, és a rés, amelyen a támadó bejutott, a visszatöltés után még nyitva van. Először zárja le az okot, utána egy ellenőrzött, tiszta állapotot töltsön vissza egy frissített rendszerre.
Be kell jelentenem egy feltörést az adatvédelmi hatóságnak?
Ha személyes adatok érintettek lehetnek, a GDPR 33. cikke alapvetően a tudomásszerzéstől számított 72 órán belüli bejelentést ír elő, ha az érintettekre nézve a kockázat nem valószínűtlen. Az értékelés az adatvédelmi felelősre vagy egy ügyvédre tartozik.
Mikor van egy incidens valóban lezárva?
Amikor az ok le van zárva, az összes ismert hátsó ajtó el van távolítva, a hozzáférések meg vannak újítva, a kötelezettségek teljesítve vannak, és az intézkedések dokumentálva vannak. Ide tartozik egy ezt követő fokozott felügyeleti időszak is, hogy az átnézett nyomokat felismerjék.
Források
- GDPR 33. cikk: bejelentés a felügyeleti hatóságnak (német nyelvű)
- Rendőrség: a kiberbűnözés központi kapcsolattartó pontjai (Zentrale Ansprechstellen Cybercrime, Németország)
- BSI: tudnivalók IT-biztonsági incidensekről (a német Szövetségi Információbiztonsági Hivatal)
- php.net: biztonsági közlemények a PHP2Shellről