Röviden: A php.ini biztonsága szempontjából négy terület számít leginkább: ne kerüljenek hibaüzenetek kifelé, biztonságos munkamenet-cookie-k, korlátozott feltöltések, és olyan lezárt értékek, amelyeket az alkalmazások nem tudnak felülírni. A PHP2Shell után ide jönnek a php.net átmeneti intézkedései, mindenekelőtt a session.upload_progress.enabled=0. A biztonságos konfiguráció azonban soha nem pótolja a frissítést.
Miért kerül ismét a figyelem középpontjába a php.ini a PHP2Shell után
A php.ini a PHP központi konfigurációs fájlja. Sok szerveren egyszer beállították, és utána alig nyúltak hozzá. A PHP2Shell ezt megváltoztatta: a CVE-2026-109618 és CVE-2026-109619 résekhez a php.net olyan átmeneti intézkedéseket nevez meg, amelyek éppen itt hatnak.
Maguk a rések a PHP-értelmezőben vannak. A PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban javították őket, 2026. 10. 21-én kiadva. Egy jó konfiguráció ennek ellenére két módon segít: megnehezítheti a kihasználást, és korlátozza a kárt, ha egyszer mégis átjut valami.
Sok üzemeltető ráadásul pontosan nem tudja, mely beállítások érvényesek a szerverén. Ez az első lépés.
Melyik php.ini érvényes a szerverén?
A PHP üzemmódtól függően különböző konfigurációs fájlokat olvashat. A parancssor, a PHP-FPM és az Apache mod_php-val Debianon és Ubuntun például mind saját mappával rendelkezik a /etc/php/<version>/ alatt. Aki csak a CLI-fájlt módosítja, a weboldalon semmit sem változtat.
# A parancssor konfigurációs fájljai
php --ini
# A PHP-FPM konfigurációja (a verziószámot igazítsa)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# A PHP-FPM egyes értékeinek ellenőrzése
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Emellett az értékek lehetnek az FPM-poolban, az Apache-konfigurációban, a .htaccess-ben (csak mod_php) vagy a .user.ini-ben (FPM és CGI). Hogy ténylegesen melyik verzió fut a szerveren, és van-e benne backport, azt a A PHP-verzió és a javítási állapot helyes ellenőrzése cikk tisztázza.
Alapbeállítások a nagyobb php.ini-biztonságért
A következő értékek a legtöbb éles szerveren célszerűek. Használat előtt egy tesztkörnyezetben ellenőrizze, hogy az alkalmazása megbirkózik-e az összes értékkel.
; Ne legyen verziókijelzés a HTTP-fejlécben
expose_php = Off
; A hibákat naplózza, de soha ne jelenítse meg a böngészőben
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Ne töltsön be fájlokat távoli címekről
allow_url_include = Off
; Az allow_url_fopen csak akkor maradjon bekapcsolva, ha az alkalmazásnak szüksége van rá
allow_url_fopen = Off
; Munkamenetek: szigorú, csak HTTPS-en, JavaScripttel nem olvasható
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Futásidő és bemenetek korlátozása
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
Az allow_url_fopen-re egyes alkalmazásoknak frissítésekhez vagy interfészekhez szükségük van. Csak akkor kapcsolja ki, ha ezt előtte ellenőrizte. A rendszerparancsokat végrehajtó függvények emellett letilthatók; hogy ez hogyan sikerül mellékhatások nélkül, azt a A disztribúció szerinti disable_functions helyes használata útmutató magyarázza.
A php.net átmeneti intézkedései a PHP2Shell ellen
Ha nem tud azonnal javítani, a php.net több olyan beállítást nevez meg, amely csökkenti a kockázatot. Ezek kifejezetten nem jelentenek teljes védelmet, hanem hidat a frissítésig.
; A session upload progress kikapcsolása (a CVE-2026-115560 miatt is)
session.upload_progress.enabled = 0
; A kérés méretének korlátozása: 8M feltöltések nélkül, 32M feltöltésekkel
post_max_size = 8M
upload_max_filesize = 6M
; Csak PHP 8.5: ne legyen backtrace súlyos hibáknál
fatal_error_backtraces = 0
Emellett a php.net azt ajánlja, hogy a memory_limit=-1 értéket úgy állítsa be, hogy az alkalmazások ne írhassák felül, a memóriahatárt pedig konténeren vagy cgroup-on keresztül húzza meg, ne az RLIMIT_AS vagy RLIMIT_DATA használatával. Ez az intézkedés az FPM-poolba vagy a szerverkonfigurációba tartozik, és működő cgroup-határral kell kombinálni. A teljes áttekintést a Azonnali intézkedések, ha még nem tud javítani oldalon találja.
A session.upload_progress.enabled=0 csak a php.ini-ből, az FPM-poolból vagy a szerverkonfigurációból hat. Ha ini_set()-tel vagy .user.ini-vel állítják be, az intézkedés nem érvényesül. Ezután indítsa újra az összes workert.
Értékek lezárása a felülírás ellen
Sok alkalmazás saját értékeket állít be, például a memóriára vagy a feltöltésekre. A php_admin_value és a php_admin_flag segítségével úgy rögzítheti a beállításokat, hogy sem az ini_set(), sem a .user.ini ne tudja módosítani őket. Az FPM-poolban ez így néz ki:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (részlet)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log
Apache mod_php-val ugyanez a logika érvényes a php_admin_value és php_admin_flag használatával a VirtualHost-konfigurációban. Ezután töltse újra a szolgáltatást, és ellenőrizze az aktív értéket:
sudo systemctl reload php8.3-fpm
# A folyamatok indulási ideje: a módosítás után van?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
A reload újraindítja a PHP-FPM workereit. Egy PHP-frissítés után ezzel szemben az összes PHP-folyamat teljes újraindítása szükséges, hogy ne fusson tovább régi folyamat a memóriában. Ha több weboldal van egy szerveren, érdemes weboldalanként külön poolt használni, erről többet az open_basedir és weboldalankénti elkülönítés útmutatóban talál.
Gyakori hibák és egy rövid ellenőrzőlista
A php.ini-vel kapcsolatos problémák többsége nem hibás értékekből, hanem rossz helyen lévő értékekből ered. Tipikus a módosított CLI-fájl, miközben a weboldal PHP-FPM-en fut. Ugyanilyen gyakori, hogy módosítás után elmarad az újraindítás, vagy egy tárhelypanel a következő mentéskor felülírja a saját beállítást.
A második klasszikus a látható hibaüzenet az éles weboldalon. Elárulják az útvonalakat, az adatbázisneveket vagy a verziókat, és megkönnyítik a támadók tájékozódását. Éppen költözés vagy újratelepítés után áll a display_errors gyakran ismét On értéken.
Ezeket a pontokat minden módosítás és minden PHP-frissítés után ellenőrizze:
- Melyik konfigurációs fájlt olvassa a webes üzemmód, és tartalmazza-e az Ön értékeit?
- Ki van-e kapcsolva a
display_errorsés azexpose_php, írható-e a hibanapló? - A
session.upload_progress.enabledértéke0, a php.ini-n vagy poolon keresztül beállítva? - A feltöltések és a kérések mérete az alkalmazáshoz illően korlátozott?
- Az összes PHP-folyamat indulási időpontja az utolsó módosítás után van?
Az eredményt rögzítse dátummal. Így később igazolható, hogy mikor melyik beállítás volt érvényben.
Hogyan segít konkrétan a PHP SOS?
- Megállapítjuk, hogy melyik üzemmódban melyik konfiguráció ténylegesen aktív.
- Bevezetünk egy összehangolt alapkonfigurációt és a PHP2Shell átmeneti intézkedéseit, az Ön alkalmazásával tesztelve.
- A biztonsági szempontból lényeges értékeket lezárjuk a felülírás ellen, és az összes workert ellenőrzötten újraindítjuk.
- Dokumentáljuk a beállításokat és az ellenőrzés eredményét, hogy a későbbi módosítások nyomon követhetők maradjanak.
Hogy hogyan néz ki a tartós védelem, azt a Szerver-keményítés PHP-webszerverekhez szolgáltatás írja le.
Gyakori kérdések
Valójában melyik php.ini-t használja a webszerverem?
Ez gyakran nem ugyanaz, mint a parancssorban. A PHP-FPM, az Apache mod_php-val és a CLI többnyire saját konfigurációs mappával rendelkezik. Az aktív fájlt ezért az adott üzemmódon keresztül ellenőrizze, például php-fpm -i paranccsal vagy egy rövid ideig elhelyezett ellenőrző fájllal.
Pótolja a biztonságos php.ini a PHP-frissítést?
Nem. A beállítások csökkentik a támadási felületet és megnehezítik a kihasználást, de nem zárnak le rést a PHP-értelmezőben. A php.net PHP2Shell elleni átmeneti intézkedései sem jelentenek kifejezetten teljes védelmet.
Mi a különbség a php_value és a php_admin_value között?
A php_value-val beállított értékeket az alkalmazás futásidőben újra megváltoztathatja. Az FPM-poolban vagy az Apache-konfigurációban a php_admin_value-val megadott értékek ezzel szemben le vannak zárva az alkalmazás elől, az ini_set() és a .user.ini elől is.
Újra kell indítani a php.ini módosítása után?
Igen. A PHP-FPM és az Apache mod_php-val csak induláskor olvassa a konfigurációt. Az új értékek csak az összes érintett szolgáltatás újraindítása vagy újratöltése után érvényesek.