# A php.ini biztonságos beállítása

> A php.ini biztonságos beállítása: hibák, munkamenetek, feltöltések és memória, a php.net PHP2Shell elleni átmeneti intézkedései másolható formában.

Forrás: https://phpsos.de/hu/ratgeber/php-ini-sicher-konfigurieren/  
Á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:** 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.

```bash
# 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](https://phpsos.de/hu/php2shell/php-version-pruefen/) 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.

```ini
; 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](https://phpsos.de/hu/ratgeber/disable-functions/) ú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.

```ini
; 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](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) oldalon találja.

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

```ini
; /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:

```bash
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](https://phpsos.de/hu/ratgeber/open-basedir/) ú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:

1. Melyik konfigurációs fájlt olvassa a webes üzemmód, és tartalmazza-e az Ön értékeit?
2. Ki van-e kapcsolva a `display_errors` és az `expose_php`, írható-e a hibanapló?
3. A `session.upload_progress.enabled` értéke `0`, a php.ini-n vagy poolon keresztül beállítva?
4. A feltöltések és a kérések mérete az alkalmazáshoz illően korlátozott?
5. 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](https://phpsos.de/hu/leistungen/server-haertung/) 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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI IT-Grundschutz (német Szövetségi Információbiztonsági Hivatal)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)