# PHP alapismeretek adminoknak

> PHP alapismeretek fejlesztői háttér nélküli adminoknak: binárisok, php.ini-szintek, FPM-poolok, parancsok, naplók és ellenőrzőlista a PHP2Shell után.

Forrás: https://phpsos.de/hu/php/php-grundwissen-admins/  
Á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 fejlesztői háttér nélküli adminoknak öt alapismeret elég a PHP biztonságos üzemeltetéséhez: a PHP több programból áll (parancssor, PHP-FPM, Apache-modul), mindegyiknek saját verziója van; a beállítások szintekben hatnak a php.ini-től az alkalmazásig; a PHP-FPM a kéréseket poolokban lévő workerekre osztja el; egy frissítés csak az összes folyamat újraindítása után hat; a naplók pedig a legfontosabb jelzések, ha valami nincs rendben. Aki ezeket a pontokat ismeri, az olyan réseket, mint a PHP2Shell, gyorsan és igazolhatóan bezárhatja.

## Miből áll a PHP egy szerveren

A PHP nem egyetlen program. Egy tipikus Linux-szerveren több változat található, amelyek mindegyike egy szerverfelületen (SAPI) keresztül csatlakozik:

| Változat | Tipikus név | Mire való |
|---|---|---|
| Parancssor (CLI) | `php`, `php8.3` | cronjobok, Composer, karbantartó szkriptek |
| PHP-FPM | `php-fpm`, `php-fpm8.3` | webkérések Nginx vagy Apache mögött |
| Apache-modul | `mod_php`, `libphp` | webkérések közvetlenül az Apache-folyamatban |
| CGI | `php-cgi` | régebbi felépítések |

Minden változatnak lehet más verziója és más php.ini-je. Sok szerveren emellett több PHP-verzió fut párhuzamosan, például a 8.2 és a 8.4. Frissítésnél mindegyiket külön kell megvizsgálni. Hogyan működnek a felületek, azt [A PHP-FPM elmagyarázva](https://phpsos.de/hu/php/php-fpm-erklaert/) oldal magyarázza.

Hogy melyik változat szolgálja ki ténylegesen a weboldalait, azt a futó folyamatokból és a webszerver-konfigurációból tudhatja meg:

```bash
ps -eo pid,user,lstart,cmd | grep -E "php|httpd|apache2" | grep -v grep
apachectl -M 2>/dev/null | grep -i php     # betölt az Apache PHP-modult?
ls /run/php/ 2>/dev/null                    # FPM-socketek, gyakran verziónként és poolonként
```

Az indítási időt tartalmazó oszlop később az újraindításnál fontos: az összes PHP-folyamatnak a frissítés időpontja után kellett elindulnia. Ha a folyamatok különböző felhasználók alatt futnak, az különálló poolokra utal, ami jó. Ha egy PHP-modul megjelenik az Apache-ban, noha az összes weboldalnak FPM-en keresztül kellene futnia, az egy eltávolítandó régi teherre utal. A tárhelyfelületekre, mint a Plesk vagy a cPanel, ugyanez az elv érvényes, csak hogy a felület weboldalanként mutatja a verziókat és a kezelőket; mérvadó azonban az marad, ami ténylegesen folyamatként fut.

## A legfontosabb parancsok adminoknak

```bash
php -v                    # a parancssor verziója
php --ini                 # betöltött php.ini és további beolvasott könyvtárak
php --ini=diff            # a PHP 8.5-től: eltérések az alapértelmezéstől
php -m                    # befordított és betöltött modulok
php --ri session          # egy bővítmény beállításai
php -l datei.php          # szintaxisellenőrzés futtatás nélkül
php-fpm8.3 -v             # az FPM-bináris verziója (a név disztribúciónként eltér)
php-fpm8.3 -t             # az FPM-konfiguráció tesztelése újraindítás nélkül
systemctl status php8.3-fpm
```

Két megjegyzés a kézikönyvből: a `php -l` szintaktikai hibákat talál, de nem azokat a hibákat, amelyek csak végrehajtáskor lépnek fel. A `php -i` pedig a `phpinfo()`-t hívja meg; a kimenet nem való a webkönyvtárban lévő nyilvános fájlokba.

## Hogyan hatnak a PHP-beállítások

Egy beállítás több helyen is megadható. Hogy ki hol mit módosíthat, azt minden direktíva módosítási módja szabályozza:

1. **php.ini és conf.d:** változatonkénti alapkonfiguráció, induláskor olvassa be.
2. **FPM-pool:** `php_value` és `php_admin_value` poolonként. A `php_admin_value`-val megadott értékeket az alkalmazás a kézikönyv szerint nem írhatja felül az `ini_set()`-tel.
3. **Könyvtárszint:** `.user.ini` az FPM-nél vagy `.htaccess` a mod_php-nál, csak az `INI_PERDIR` vagy `INI_ALL` módú direktívákhoz.
4. **Alkalmazás:** `ini_set()` futásidőben, csak az `INI_ALL` módú direktívákhoz.

Egy példa: a `memory_limit` módja `INI_ALL`, tehát az alkalmazás módosíthatja. A `post_max_size` módja `INI_PERDIR`, és nem módosítható az `ini_set()`-tel. Ezért követeli meg a php.net a PHP2Shell átmeneti intézkedéseinél, hogy az értékeket úgy állítsák be, hogy az alkalmazások ne írhassák felül őket. A szintek részleteit [A php.ini elmagyarázva](https://phpsos.de/hu/php/php-ini-erklaert/) oldal magyarázza.

## A PHP-FPM-poolok dióhéjban

A pool workerek csoportja saját felhasználóval, saját sockettel és saját beállításokkal. A legfontosabb direktívák a kézikönyv szerint:

```ini
[shop]
user = shop
group = shop
listen = /run/php/shop.sock
pm = dynamic                 ; static, dynamic vagy ondemand
pm.max_children = 20         ; legfeljebb 20 egyidejű kérés
pm.max_requests = 500        ; a worker megújítása 500 kérés után
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/shop-slow.log
php_admin_value[error_log] = /var/log/php-fpm/shop-error.log
php_admin_flag[log_errors] = on
```

A weboldalankénti saját pool saját felhasználóval elválasztja egymástól a weboldalakat. A `security.limit_extensions` alapértelmezés szerint `.php .phar`, és megakadályozza, hogy az FPM más fájlkiterjesztéseket PHP-ként hajtson végre. A `clear_env` alapértelmezés szerint be van kapcsolva, és távol tartja a környezeti változókat a workertől.

## Naplók: hová nézzenek az adminok

A PHP a hibákat az `error_log`-gal megadott célra írja, a PHP-FPM emellett a saját naplójába, a lassú kéréseket pedig backtrace-szel a slowlogba. Ehhez jönnek a webszerver hozzáférési és hibanaplói. Ügyeljen arra, hogy a `display_errors` éles üzemben ki, a `log_errors` pedig be legyen kapcsolva: a hibák a naplóba valók, nem a weboldalra. A naplókat emellett rotálni kell, és meghatározott ideig meg kell őrizni, hogy éles helyzetben még meglegyenek. A PHP2Shell után a szaksajtó azt ajánlja, hogy a szervernaplókat 2026. október 20-tól őrizzék meg. Erős figyelmeztető jel egy olyan PHP-FPM- vagy webszerver-folyamat, amely shellt indít; hogyan ismeri fel ezt, azt a [Figyelmeztető jel: a webszerver shellt indít](https://phpsos.de/hu/blog/webserver-startet-shell/) cikk írja le.

## Ellenőrzőlista adminoknak a PHP2Shell után

1. Sorolja fel a szerveren lévő összes PHP-változatot és -verziót, a nem használtakat is.
2. Ellenőrizze a csomagállapotot; a disztribúció backportjainál keresse át a changelogot a CVE-2026-109618 és a CVE-2026-109619 után.
3. Frissítsen a 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, illetve a megerősített backportra.
4. Indítsa újra a PHP-FPM-et, az Apache-ot és a LiteSpeedet, és ellenőrizze a folyamatok indítási idejét.
5. Ellenpróba a `php -r 'var_dump(ini_get("memory_hard_limit_percent"));'` paranccsal; a `bool(false)` a kézikönyv szerint érintett verziót jelent.
6. Biztosítsa a naplókat, és vizsgálja át őket feltűnő jelenségek szempontjából.

Hogyan igazolhatja megbízhatóan a verziót és a javítási állapotot, azt a [PHP-verzió és javítási állapot helyes ellenőrzése](https://phpsos.de/hu/php2shell/php-version-pruefen/) oldal írja le.

## Hogyan segít konkrétan a PHP SOS?

A [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében a PHP alapgondozását a csapatával együtt átvesszük:

- **Leltár:** az összes PHP-változat, -verzió, pool és konfigurációs hely szerverenként.
- **Konfiguráció:** a biztonsági szempontból releváns értékek `php_admin_value`-val beállítva, a poolok weboldalanként elválasztva.
- **Frissítések:** telepítés, újraindítás, ellenőrzés és dokumentálás minden biztonsági kiadásnál.
- **Tudás átadása:** Elmagyarázzuk az adminjainak, mit változtattunk és miért.


## Gyakori kérdések

**Miért mutat a php -v más verziót, mint a weboldal?**  
A parancssor, a PHP-FPM és az Apache-modul különálló programok saját verzióval és saját php.ini-vel. A php -v csak a parancssort mutatja. A weboldalnál a ténylegesen kéréseket feldolgozó bináris verziója számít.

**Melyik php.ini érvényes a szerveremen?**  
A parancssorra a php --ini mutatja meg. A PHP-FPM-nek többnyire saját php.ini-je és további pool-fájljai vannak. A PHP 8.5 óta a php --ini=diff megmutatja, mely értékek térnek el az alapértelmezéstől.

**Mi a különbség a php_value és a php_admin_value között?**  
Mindkettő beállításokat rögzít egy FPM-poolban. A php_admin_value-val megadott értékeket az alkalmazás a kézikönyv szerint nem írhatja felül az ini_set()-tel. A biztonsági szempontból releváns beállításokhoz ezért a php_admin_value a helyes választás.

**Elég egy frissítés újraindítás nélkül?**  
Nem. A futó PHP-folyamatok megtartják a régi kódot a memóriában. Frissítés után a PHP-FPM-et, az Apache-ot mod_php-val vagy a LiteSpeedet újra kell indítani, különben a sebezhető verzió fut tovább.

## Források

- [PHP-kézikönyv: A parancssor opciói](https://www.php.net/manual/en/features.commandline.options.php)
- [PHP-kézikönyv: FPM-konfiguráció](https://www.php.net/manual/en/install.fpm.configuration.php)
- [PHP-kézikönyv: Core-beállítások](https://www.php.net/manual/en/ini.core.php)
- [php.net: Biztonsági közlemények](https://www.php.net/)
