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? 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:
# 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:
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:
# 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 oldalon vannak.
Mit tegyen, ha shellt talál a webszerver alatt
- Dokumentálás: Mentse a
pskimenetét, a parancssort, a munkakönyvtárat és a nyitott kapcsolatokat egy, a webkönyvtáron kívüli fájlba. - Ne takarítson: Ne törölje a fájlokat, és ne fejezze be a folyamatokat, mielőtt a nyomokat biztosította volna.
- Elkülönítés: Vegye le a szervert a hálózatról, vagy korlátozza erősen a hozzáférést.
- 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.
- 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.
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 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 í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.