# Már feltörték a rendszeremet? Jelek a PHP2Shell után

> Feltörték a szervert? Tipikus jelek a PHP2Shell után, első ellenőrzések nyomvesztés nélkül, és mit tegyen gyanú esetén, lépésről lépésre.

Forrás: https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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:

```bash
# 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](https://phpsos.de/hu/ratgeber/logfiles-auswerten/) írja le; hogyan találja meg a hátsó ajtókat, azt a [Webshellek felismerése és eltávolítása](https://phpsos.de/hu/ratgeber/webshell-erkennen/).

> **Azonnal cselekedjen:**
> 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](https://phpsos.de/hu/compliance/dsgvo-meldepflicht-72-stunden/) 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](https://phpsos.de/hu/leistungen/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](https://phpsos.de/hu/leistungen/it-forensik/).
- **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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/)
- [GDPR 33. cikk: bejelentés a felügyeleti hatóságnak](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)