Röviden: Hogy egy szervert a PHP2Shell révén feltörtek-e, azt nem lehet egyetlen jellemzőről leolvasni. Nincsenek közzétett, megerősített Indicators of Compromise; a felismerés viselkedéselemzésen alapul. Tipikus jelek az új PHP-fájlok, az ismeretlen cron-feladatok és a szokatlan kapcsolatok. Először mentse a naplókat október 20-tól, mielőtt bármit megváltoztatna.
Vannak egyértelmű jelei egy PHP2Shell-támadásnak?
Nem, és ez az őszinte válasz. Sok ismert résnél a gyártók vagy a biztonsági cégek konkrét nyomokat tesznek közzé: fájlneveket, ellenőrző összegeket, IP-címeket. A PHP2Shell-hez ilyen megerősített Indicators of Compromise eddig nincsenek.
Ami ismert: médiabeszámolók szerint egy első támadási kísérletet október 17-én figyeltek meg, négy nappal a október 21-i javítások előtt. A Cloudflare további kísérletekről számolt be. Széles körben megerősített sikeres támadások a BSI szerint kezdetben nem voltak ismertek. Aki október 17. és a saját javítása között védtelenül volt elérhető, ezért ellenőrizzen, ne reménykedjen.
Az értékelésnél elsősorban az időszak számít. Az első megfigyelt támadási kísérlet október 17-én és a javítások október 21-én között nem volt hivatalos frissítés. Minden nyilvánosan elérhető PHP-szerver ebben az időben potenciálisan támadható volt. Hogy a szervere ezen túl meddig volt nyitva, az attól függ, mikor telepítették a frissítést, és mikor indították újra a PHP-t. Minél hosszabb ez az időszak, és minél érzékenyebbek az adatok, például ügyfélfiókok, rendelések vagy jelentkezések, annál alaposabbnak kell lennie az ellenőrzésnek.
A szerver feltörésének tipikus jelei
Egy sikeres kódfuttatás után a támadók többnyire megpróbálnak berendezkedni, és a szervert használni. Ebből olyan jelek adódnak, amelyek nem a PHP2Shell-re jellemzők, de minden behatolás-ellenőrzésnél számítanak:
- Új vagy módosított PHP-fájlok, főként feltöltési, gyorsítótár- vagy képkönyvtárakban, ahol egyébként nincsenek PHP-fájlok.
- Ismeretlen cron-feladatok vagy ütemezett feladatok, például a webszerver-felhasználóhoz.
- Szokatlan kimenő kapcsolatok ismeretlen címekre, nagy hálózati terhelés, vagy olyan levélküldés, amelyet senki sem indított.
- Új rendszergazdai fiókok a CMS-ben vagy a webshopban, megváltozott jelszavak, ismeretlen SSH-kulcsok.
- Feltűnő terhelés: tartósan magas CPU-kihasználtság ismeretlen folyamatoktól, gyakran kriptobányászat jele.
- Látható következmények: átirányítások idegen oldalakra, spam-oldalak a Google indexében, figyelmeztetések a böngészőben vagy a Search Console-ban.
E jelek egyike sem bizonyít önmagában behatolást, hiányuk pedig nem bizonyítja az ellenkezőjét. Az összkép a döntő.
Első ellenőrzések a nyomok megsemmisítése nélkül
Mielőtt bármit töröl vagy újraindít: mentse a naplókat. A szakmai sajtó azt tanácsolja, hogy a szervernaplókat október 20-tól őrizzék meg. Másolja a webszerver-, PHP- és rendszernaplókat egy biztonságos helyre a szerveren kívül.
Utána segítenek a kizárólag olvasó ellenőrzések. Az útvonalak és a felhasználónevek rendszerenként eltérnek:
# Az október 17. óta módosított PHP-fájlok
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP-fájlok a feltöltési könyvtárakban (példa: WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# A webszerver-felhasználó és a rendszerszintű cron-feladatok
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# Aktív hálózati kapcsolatok folyamattal
ss -tunp
# Az utolsó bejelentkezések
last -n 30
Vegye figyelembe: a támadók meghamisíthatják a fájlok időbélyegét. A find feltűnésmentes eredménye ezért nem felmentés. Hogyan értékelheti ki célzottan a naplókat, azt a Webszerver-naplók kiértékelése támadás után írja le; hogyan találja meg a hátsó ajtókat, azt a Webshellek felismerése és eltávolítása.
Ha konkrét jeleket talál, például egy ismeretlen PHP-fájlt a feltöltési mappában: ne törölje, ne telepítsen újra, ne „javítsa meg gyorsan“ az alkalmazást. Válassza le vagy szigetelje el a szervert a hálózatról, mentse a naplókat és a rendszer lemezképét, és kezdjen strukturált incidenskezelést.
Amit nem szabad tennie
- Csak javítani, és továbbmenni. A javítás nem távolítja el a már bejuttatott kártékony szoftvert.
- A gyanús fájlokat azonnal törölni. Ezzel eltűnnek a bizonyítékok arra, mi történt és mely adatok lehetnek érintettek.
- A szervert újratelepíteni, mielőtt mentés készült. Az ok tisztázatlan marad, és az adatbázisban vagy a hozzáférési adatokban lévő hátsó ajtó túléli az újratelepítést.
- Régi mentéseket ellenőrzés nélkül visszaállítani. Egy mentés is tartalmazhatja már a hátsó ajtót.
- Elfelejteni a hozzáférési adatokat. Kódfuttatás után az adatbázis-jelszavak, API-kulcsok és más hozzáférési adatok kiszivároghattak a konfigurációs fájlokból. Újítsa meg őket a tisztítás után, nem előtte, hogy egy még aktív támadó ne olvassa rögtön az újakat is.
Ha a gyanú beigazolódik
Ilyenkor többről van szó, mint technikáról. Az adatvédelmi felelőssel vizsgálja meg, szükséges-e a GDPR szerinti bejelentés; a határidő a tudomásszerzéstől számított 72 óra, részletek a GDPR szerinti bejelentési kötelezettség oldalon. Tájékoztassa korán a kiberbiztosítóját, ha van, és egy ügyvéddel tisztázza, szükséges-e feljelentést tenni. Ehhez általános tudnivalókat adunk, jogi tanácsot nem.
Hogyan segít konkrétan a PHP SOS?
Az incident response szolgáltatásunkkal strukturáltan dolgozzuk fel a gyanút:
- Mentés: A naplók október 20-tól és szükség esetén a rendszer lemezképe, mielőtt bármi megváltozna.
- Vizsgálat: A fájlok, folyamatok, kapcsolatok és fiókok viselkedéselemzése; szükség esetén bíróság előtt is felhasználhatóan az IT-forenzikával.
- Tisztítás és lezárás: Hátsó ajtók eltávolítása, a PHP frissítése, a hozzáférési adatok megújítása, a szerver keményítése.
- Dokumentálás, amíg az incidens le nem zárul és dokumentálva nincs, az adatvédelem, a biztosítás és a vezetés alapjaként.
Gyakori kérdések
Bizonyítja a PHP-frissítés, hogy a szerverem tiszta?
Nem. A javítás a jövőre nézve lezárja a rést, de nem távolítja el a már bejuttatott kártékony szoftvert. Azt sem mondja meg, hogy a javítás előtt behatolt-e valaki.
Van olyan szkenner, amely biztosan felismeri a PHP2Shell támadásokat?
Eddig nincs. Nincsenek közzétett, megerősített Indicators of Compromise, amelyekre egy szkenner célzottan kereshetne. A kártevőkeresők megtalálják az ismert webshelleket, egy szerver értékelése azonban viselkedéselemzésen alapul.
Be kell jelentenem egy gyanút az adatvédelmi hatóságnak?
Ez attól függ, hogy személyes adatok érintettek lehetnek-e. A GDPR a bejelentésköteles adatvédelmi incidensekre a tudomásszerzéstől számított 72 órás határidőt ír elő. Tisztázza ezt korán az adatvédelmi felelőssel vagy egy ügyvéddel; mi ehhez nem adunk jogi tanácsot.
Állítsam fel egyszerűen újra a feltört szervert?
Nem első lépésként. Először mentse a naplókat, és ha lehet, a rendszer egy lemezképét. Aki azonnal újratelepít, elveszíti azokat a nyomokat, amelyek megmutatják, mi történt és mely adatok lehetnek érintettek.