# Figyelmeztető jel: a webszerver shellt indít

> A PHP-FPM vagy az Apache shellt indít? Így olvassa a folyamatfát, választja külön az ártalmatlan eseteket a behatolás nyomaitól, és figyeli tartósan a mintát.

Forrás: https://phpsos.de/hu/blog/webserver-startet-shell/  
Á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:** Ha a PHP-FPM, az Apache vagy egy másik webszerver-folyamat shellt, például `sh`-t vagy `bash`-t indít, az a weboldalon keresztüli behatolás egyik legerősebb figyelmeztető jele. Mielőtt bármit leállítana, ellenőrizze a shell folyamatfáját, parancssorát és munkakönyvtárát. Az egyes rövid shellek lehetnek jogosak; a hosszan futó, hálózati eszközöket használó shellek szinte soha.

## Miért mond ennyit ez a minta

A webszerver kéréseket válaszol meg. A PHP-FPM, vagyis az a folyamatkezelő, amely a PHP-szkripteket végrehajtja a webszerver számára, ehhez normál esetben nem indít további programokat. A webszerver alatti shell azt jelenti, hogy a PHP-kód szándékosan hívott egy programot. Vagy az alkalmazás teszi ezt szándékosan, vagy valaki más csempészett be kódot.

A PHP2Shellre nincsenek közzétett, megerősített Indicators of Compromise, vagyis rögzített felismerési jegyek listája. A felismerés a viselkedésen alapul. A rendelkezésünkre álló beszámolók szerint a shellt indító webszerver- vagy PHP-FPM-folyamatok az általános figyelmeztető jelek legerősebbjei közé tartoznak. Ez minden olyan résre igaz, amelyen keresztül a támadók kódot hajtanak végre a szerveren. A további jelekről áttekintést ad a [Megfertőzték már a rendszeremet?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) oldal.

Miért olyan fontos a shell a támadónak? Egy réssel eleinte csak egyes parancsokat tud kiadni a PHP-folyamaton keresztül. A shell ebből kényelmes munkahelyet csinál: körülnézhet, eszközöket tölthet le, hozzáférési adatokat olvashat ki konfigurációs fájlokból, és tartósan berendezkedhet. Aki felismeri a shellt, a támadót gyakran éppen abban a pillanatban ismeri fel, amikor az első hozzáféréstől áttér az igazi tervére.

## PHP-FPM bash-t indít: a folyamatfa olvasása

Minden Linux alatti folyamatnak van szülőfolyamata. A kérdés az, hogy egy shell egy webszerver-folyamat gyermekeként fut-e. A következő parancsok csak olvasnak:

```bash
# Folyamatfa felhasználóval, szülő-PID-del és indulási idővel
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"

# Tipikus webszerver-felhasználók alatt futó shellek
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"

# A fa a legrégebbi PHP-FPM-folyamattól kezdve
pstree -alp "$(pgrep -o php-fpm)"
```

Ha talált egy gyanús shellt, a `/proc` alatti bejegyzések további támpontokat adnak, szintén csak olvasva:

```bash
PID=12345   # a gyanús shell PID-je
tr '\0' ' ' < /proc/$PID/cmdline; echo        # a teljes parancssor
ls -l /proc/$PID/cwd /proc/$PID/exe            # munkakönyvtár és programfájl
ls -l /proc/$PID/fd 2>/dev/null | grep socket  # nyitott hálózati kapcsolatok
```

A Debianon és Ubuntun a folyamatnevek gyakran `php8.3-fpm` vagy hasonlók; igazítsa a keresési mintákat. A `/tmp`, a `/dev/shm` vagy a feltöltési mappák munkakönyvtárként egyértelmű jelek.

## Jogos kivételek és valódi figyelmeztető jelek

Egyes alkalmazások programokat hívnak a PHP-n keresztül. Ilyenkor rövid időre shell keletkezhet, például ha a PHP a `sendmail_path` révén adja át a leveleket, vagy egy alkalmazás külső eszközzel dolgoz fel képeket. Az ilyen shellek csak másodpercekig élnek, és mindig ugyanazt a programot hívják. Ezeket a várt eseteket egyszer dokumentálja tisztán; akkor minden eltérés azonnal feltűnik, ahelyett hogy elmerülne az ismert jelzések áradatában.

| Megfigyelés | Inkább ártalmatlan, ha | Gyanús, ha |
|---|---|---|
| Rövid shell a PHP-FPM alatt | az alkalmazás egy ismert programját indítja | a cél és a rendeltetés tisztázatlan |
| Hosszabban futó shell | soha | percekig vagy órákig fut |
| Hálózati eszközök gyermekfolyamatként | az alkalmazás ismert frissítési vagy API-lekérdezése | letöltések következnek ideiglenes könyvtárakba |
| Munkakönyvtár | az alkalmazás projektmappája | `/tmp`, `/dev/shm`, feltöltési mappa |
| Időpont | egy ismert művelethez illik, például levélküldéshez | éjszaka, felhasználói tevékenység nélkül, halmozottan |

Ha nem tudja, hogy az alkalmazása hív-e programokat, kérdezze meg a fejlesztőt, vagy keressen a kódban olyan függvényeket, mint az `exec`, `shell_exec`, `system`, `passthru`, `proc_open` és `popen`. A saját kódban lévő találatok normálisak, az ismeretlen fájlokban lévők nem.

## Tartós figyelés az egyszeri ránézés helyett

A `ps` pillanatfelvétele csak az éppen futó shelleket kapja el. A rövid életű folyamatok átcsúsznak. Megbízhatóbb, ha a webszerver-felhasználó programindításait tartósan naplózza. Linuxon ezt az auditd audit-szolgáltatás végzi egy, a webszerver-felhasználó programindításaira vonatkozó szabállyal. Az értékelés olvasva történik:

```bash
# Egy szabálykulcs alatt naplózott programindítások megjelenítése (a kulcs példa)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="
```

Hogy a szabály hogyan néz ki, az a disztribúciótól és a felhasználói azonosítótól függ; először tesztelje, mert erősen terhelt szervereken sok bejegyzés keletkezik.

Két kiegészítés teszi megbízhatóvá a figyelést. Először: a naplókat érdemes emellett egy központi rendszerbe is továbbítani, mert egy root jogú támadó törölheti a helyi naplókat. Másodszor: riasztás is kell. A webszerver-felhasználó olyan programindítása, amely nincs rajta a várt programok rövid listáján, jelzést váltson ki, ne csak naplóbejegyzést. Aki már használ végpontokon vagy szervereken felismerő megoldást, ugyanezt a szabályt ott is leképezheti. Megelőzésként a `disable_functions` zárolhatja, amire az alkalmazásnak nincs szüksége. Ez nem zár be rést az értelmezőben, de megnehezíti a támadó következő lépését. A részletek a [A disable_functions helyes használata](https://phpsos.de/hu/ratgeber/disable-functions/) oldalon vannak.

## Mit tegyen, ha shellt talál a webszerver alatt

1. **Dokumentálás:** Mentse a `ps` kimenetét, a parancssort, a munkakönyvtárat és a nyitott kapcsolatokat egy, a webkönyvtáron kívüli fájlba.
2. **Ne takarítson:** Ne törölje a fájlokat, és ne fejezze be a folyamatokat, mielőtt a nyomokat biztosította volna.
3. **Elkülönítés:** Vegye le a szervert a hálózatról, vagy korlátozza erősen a hozzáférést.
4. **Az ok keresése:** Ellenőrizze a naplókat, az új fájlokat és a perzisztenciát, például a cron-feladatokat, lásd [Gyanús folyamatok keresése Linux-szervereken](https://phpsos.de/hu/blog/verdaechtige-prozesse-linux/).
5. **Hozzáférések cseréje:** Minden jelszó és kulcs, amely a szerveren volt, ismertnek tekintendő.

Ha az alkalmazás konténerekben fut, ugyanez az elv kicsiben érvényes. A PHP-konténerben lévő shell ugyanolyan gyanús, mint egy klasszikus szerveren, és a konténer-image-ek gyakran csak azért tartalmazzák, mert az alapimage hozza magával. A konténer újraindítása előtt mentse az állapotát, mert a konténerrel együtt eltűnnek a nyomok a tünékeny fájlrendszerben.

Ellenőrizze a szomszédságot is. Egy webszerveren shellt szerzett támadó gyakran onnan próbál elérni más rendszereket, például az adatbázist, a mentési tárolókat vagy a belső felügyeleti felületeket. Az alkalmazás konfigurációs fájljaiban lévő hozzáférési adatok ezt megkönnyítik számára.

> **Azonnal cselekedjen:**
> Egy ügyféladatokat tartalmazó szerveren a PHP-FPM alatt hosszan futó shell biztonsági incidens. Úgy kezelje: mentse, különítse el, dolgozza fel strukturáltan, és ellenőriztesse a bejelentési kötelezettségeket.

## Hogyan segít konkrétan a PHP SOS?

- **A lelet értékelése:** Ellenőrizzük a folyamatfát, a parancssorokat és a kapcsolatokat, és elválasztjuk az alkalmazás viselkedését a behatolás nyomaitól.
- **Nyomok mentése:** Visszakövethetően mentjük a rendszer állapotát, mielőtt bármit megváltoztatnánk.
- **Az incidens kezelése:** Az [Incident Response](https://phpsos.de/hu/leistungen/incident-response/) szolgáltatással a megfékezéstől a dokumentált lezárásig vezetjük.
- **Tartós védelem:** Beállítjuk a programindítások naplózását, és a PHP-függvényeket a szükségesre korlátozzuk. Hogy a PHP-FPM belül hogyan működik, azt a [A PHP-FPM magyarázata](https://phpsos.de/hu/php/php-fpm-erklaert/) írja le.


## Gyakori kérdések

**Minden shell a PHP-FPM alatt támadás?**  
Nem mindegyik. Egyes alkalmazások szándékosan hívnak programokat a PHP-n keresztül, például képfeldolgozáshoz vagy levélküldéshez, és ilyenkor rövid időre shell keletkezhet. Gyanússá akkor válik, ha a shell tovább fut, hálózati eszközöket indít, vagy szokatlan könyvtárakból dolgozik.

**Azonnal be kell fejeznem a gyanús folyamatot?**  
Először dokumentáljon, aztán cselekedjen. Rögzítse a folyamatadatokat, a parancssort, a munkakönyvtárat és a hálózati kapcsolatokat. Utána különítse el a szervert. A kapkodó leállítás nyomokat semmisít meg, és nem akadályozza meg, hogy a támadó visszatérjen.

**Vannak megerősített felismerési jegyek a PHP2Shellre?**  
Nem. Nincsenek közzétett, megerősített Indicators of Compromise. A webszerver alatti shellek a webalkalmazásokon keresztüli behatolások általános figyelmeztető jelei, nem a PHP2Shellre jellemzőek.

**Hogyan akadályozhatom meg, hogy a PHP egyáltalán shelleket indítson?**  
A disable_functions segítségével zárolhatók az olyan függvények, mint az exec, shell_exec, system és proc_open, ha az alkalmazásnak nincs rájuk szüksége. Ez nem zár be rést a PHP-értelmezőben, de megnehezíti a kihasználást.

## Források

- [BSI: a német szövetségi információbiztonsági hivatal](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: biztonsági közlemények](https://www.php.net/)