Röviden: A PHP disable_functions-szal olyan függvényeket tilt le, amelyeken keresztül a PHP rendszerparancsokat hajt végre, például az exec, a shell_exec vagy a proc_open. Ez megnehezíti a támadók következő lépését egy behatolás után. A beállítás csak a php.ini-ből vagy az FPM-poolból hat, az alkalmazáshoz kell illeszkednie, és nem pótolja a frissítést.
Miért érdemes éppen most a disable_functions
A PHP2Shell kártékony kód távoli, bejelentkezés nélküli futtatásáról szól. A két rés, a CVE-2026-109618 és a CVE-2026-109619, magában a PHP-értelmezőben van, a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban javították őket. A frissítés az egyetlen mód a lezárásukra.
A keményítés egy szinttel később kapcsolódik be. Aki egyszer kódot tud futtatni egy szerveren, az többnyire tovább akar menni: rendszerparancsokat indítani, eszközöket letölteni, tartós hátsó ajtót kialakítani. E lépések közül sok néhány PHP-függvényen keresztül zajlik. Ha ezek le vannak tiltva, az út nehezebbé és feltűnőbbé válik.
A disable_functions ezért nem helyettesíti a javításokat, hanem egy építőelem arra az esetre, ha minden elővigyázatosság ellenére átjut valami. Ez a jövőbeli rések esetén ugyanúgy érvényes, mint a PHP2Shellnél.
Mit tud a PHP disable_functions, és mit nem
A beállítás eltávolítja a megnevezett függvényeket a futtatókörnyezetből. Ha egy szkript letiltott függvényt hív meg, a PHP hibával megszakad. A tiltás minden olyan kódra érvényes, amely abban a PHP-folyamatban fut, tehát a bejuttatott kódra is.
A határokat érdemes ismernie:
- A beállítás nem zárt védőtér. PHP-bővítmények, az értelmezőben lévő hibák vagy a PHP-n kívüli programok megkerülhetik.
- Nem akadályozza meg, hogy a támadó olyan fájlokat olvasson vagy írjon, amelyekhez a PHP-felhasználónak hozzáférése van. Erre a fájljogosultságok és az elkülönítés valók.
- Csak a php.ini-ből vagy
php_admin_value-ként hat.ini_set()-tel,.user.ini-vel vagy.htaccess-szel nem állítható be.
A disable_functions a leginkább egy rendezett php.ini-vel, weboldalankénti külön felhasználókkal és szigorú fájljogosultságokkal együtt visz előre. Az alapokat a A php.ini biztonságos beállítása útmutatóban találja.
Mely függvényeket érdemes letiltani
A rendszerparancsokat nem igénylő, tipikus weboldalaknál az alábbi lista vált be. Folyamatok indítására és futó folyamatok vezérlésére szolgáló függvényeket foglal magában.
| Csoport | Függvények | Tipikus jogos felhasználás |
|---|---|---|
| Parancsok végrehajtása | exec, shell_exec, system, passthru |
Képszerkesztés, mentések szkripttel |
| Folyamatok megnyitása | proc_open, popen |
Composer, PDF-eszközök, levélküldés |
| Folyamatok vezérlése | proc_nice, proc_terminate, proc_get_status |
Várakozási sorok, háttérfeladatok |
| Folyamatkezelés | pcntl_exec, pcntl_fork |
többnyire csak a parancssorban |
| Szignálok és jogok | posix_kill, posix_setuid |
webes üzemben ritka |
Konfigurációként ez így néz ki:
; a webes üzemmód php.ini-je, pl. /etc/php/8.3/fpm/php.ini
disable_functions = exec,shell_exec,system,passthru,proc_open,popen,proc_nice,proc_terminate,proc_get_status,pcntl_exec,pcntl_fork,posix_kill,posix_setuid
Ha a lista nem érvényes a szerver összes weboldalára, állítsa be FPM-poolonként. Az újratöltés után ellenőrizze, hogy ténylegesen melyik lista érvényes az adott poolban:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (részlet)
php_admin_value[disable_functions] = exec,shell_exec,system,passthru,proc_open,popen
Az alkalmazás előzetes ellenőrzése: így kerüli el a kieséseket
Aki a listát ellenőrzés nélkül állítja be, azt kockáztatja, hogy a képátméretezés, a PDF-számlák vagy a levélküldés hirtelen nem működik. Ezért előtte keresse meg a kódban az érintett függvényeket:
# Hol és milyen gyakran használják a függvényeket a kódban?
grep -rnoE "\b(exec|shell_exec|system|passthru|proc_open|popen|pcntl_exec)\s*\(" /var/www/meine-seite --include="*.php" \
| cut -d: -f1 | sort | uniq -c | sort -rn | head -30
A találatok nem jelentik automatikusan, hogy a függvényre az üzemben szükség van. Sok könyvtár először megnézi, elérhető-e egy függvény, és ha nem, kitér. Döntő egy tesztelés staging környezetben az összes fontos folyamattal: rendelés, számla, űrlapküldés, képfeltöltés, ütemezett feladatok.
Ha egy alkalmazás kötelezően megkövetel egy ilyen függvényt, ellenőrizze a gyártó rendszerkövetelményeit a hivatalos oldalán. A feladat gyakran áthelyezhető egy különálló poolba vagy egy parancssori szkriptbe, amely a weben keresztül nem érhető el.
A beállítás aktiválása és a hatás ellenőrzése
A módosítás után a PHP-nek újra be kell olvasnia a konfigurációt. Ezután az értéket a weboldala üzemmódjában ellenőrizze, ne a parancssorban:
sudo systemctl reload php8.3-fpm
php-fpm8.3 -i | grep "^disable_functions"
# A hibanaplóban ellenőrizze a letiltott függvények hívásait
sudo grep -i "has been disabled" /var/log/php/*.log | tail -20
A hibanapló üzenetei később is értékesek. Ha ott hirtelen letiltott függvények hívásai tűnnek fel, noha az alkalmazása nem használja őket, az bejuttatott kódra utalhat. Hogyan járjon el ilyenkor, azt a Webshellek felismerése és eltávolítása útmutató írja le.
Tipikus hibák a disable_functions használatánál
A gyakorlatban a keményítés ritkán a technikán, inkább apróságokon bukik el. Ezek a hibák különösen elterjedtek:
- Rossz fájlt módosítottak: A lista csak a parancssor php.ini-jében áll, a weboldal PHP-FPM-en fut, és védtelen marad.
- Elmaradt az újraindítás: A fájl helyes, de a futó folyamatok még a régi konfigurációval dolgoznak.
- Túl széles tiltás: Az olyan függvényeket, mint az
ini_setvagy amail, is letiltják, és fontos folyamatok észrevétlenül megszakadnak. A hibák ilyenkor gyakran csak napokkal később tűnnek fel, például elmaradó rendeléspéldányok miatt. - Egyszer beállították, soha nem ellenőrizték: Egy költözés, egy PHP-verzióváltás vagy a tárhelypanelen keresztüli újratelepítés után a lista eltűnt.
- Hamis biztonságérzet: A tiltást a frissítések pótlékának tekintik. Az értelmezőben lévő rést azonban nem zárja le.
Vegye ezért fel az aktív érték ellenőrzését a rutinjába minden PHP-frissítés után. Egy rövid pillantás elég, alig vesz igénybe időt, és megakadályozza, hogy egy keményítés csendben elvesszen.
Ha több weboldal van egy szerveren: hozzon létre minden weboldalhoz külön poolt saját listával. Kiegészítésként az open_basedir korlátozza azokat a könyvtárakat, amelyekhez a PHP hozzáférhet.
Hogyan segít konkrétan a PHP SOS?
- Megvizsgáljuk az alkalmazás kódját és folyamatait a kritikus függvények használata szempontjából.
- Weboldalanként megállapítunk egy megfelelő tiltólistát, és élesítés előtt teszteljük.
- A tiltást poolokkal, fájljogosultságokkal és naplózással egy összhangban lévő keményítési koncepcióvá kombináljuk.
- Dokumentáljuk a beállításokat, és a hibanaplót figyeljük feltűnő hívások szempontjából.
Hogyan zajlik ez teljes csomagként, azt a Szerver-keményítés PHP-webszerverekhez szolgáltatás írja le.
Gyakori kérdések
Beállíthatom a disable_functions-t ini_set()-tel vagy .htaccess-szel?
Nem. A beállítás csak a php.ini-ből vagy az FPM-poolban, illetve az Apache-konfigurációban php_admin_value-ként hat. Futásidőben nem állítható be, és az alkalmazás a letiltott függvényeket sem tudja újra feloldani.
Véd a disable_functions a PHP2Shell ellen?
Nem. A PHP2Shell magát a PHP-értelmezőt érinti, a rést csak a frissítés zárja le. A letiltott függvények azonban korlátozhatják a támadó mozgásterét egy sikeres kihasználás után.
Miért mutat a php -i más listát, mint a weboldalam?
A parancssor gyakran saját php.ini-t olvas. A weboldalnak a PHP-FPM, a mod_php vagy a LiteSpeed konfigurációja számít. Az értéket ezért abban az üzemmódban ellenőrizze, amelyen a weboldala fut.
Mely alkalmazásoknak van szükségük a proc_open-re vagy az exec-re?
Ez az alkalmazástól függ. Tipikus a képszerkesztés külső programokkal, a PDF-készítés, a levélküldés a sendmailen keresztül, vagy az olyan eszközök, mint a Composer. Ellenőrizze a kódban és a gyártó rendszerkövetelményeiben.