PHP üzemeltetése konténerekben

Röviden: Ha a PHP-t konténerekben üzemelteti, válassza ki a hivatalos kép megfelelő változatát (fpm, apache vagy cli), kapcsolja be az éles php.ini-t, csak a szükséges bővítményeket telepítse, és olyan memória- és folyamathatárokat állítson be, amelyek illeszkednek egymáshoz. A konténerek megváltoztathatatlanok: egy PHP-os biztonsági frissítés, mint a PHP2Shellhez tartozó, csak akkor hat, ha a képet újraépítették, és minden konténert újraindítottak. Ez az újraépítés ezért fix folyamatként minden konténeres üzem része legyen.

Miért PHP a konténerekben?

A konténerek a PHP-t, a bővítményeket és a konfigurációt egyetlen képbe csomagolják, amely minden szerveren ugyanúgy fut. A vállalatoknak ez kevesebb meglepetést jelent a teszt és az éles üzem között, gyorsabb helyreállítást és világos verzióállapotokat. A biztonság szempontjából viszont új kötelezettséget is jelent: a konténerben senki nem telepít automatikusan frissítéseket.

Ez az oldal a folyamatos üzemmel foglalkozik. Hogyan javíthatja meg konkrétan a meglévő konténereket a PHP2Shell ellen, azt a PHP javítása Docker-konténerekben oldal írja le.

A megfelelő képváltozat kiválasztása

Új projektekhez általában az fpm-változat ajánlott külön webszerver-konténerrel. A mod_php-nál a PHP-csapat a PHP2Shell kapcsán a legmagasabb kockázatot látja; aki az apache képet használja, éppen ezt az üzemmódot üzemelteti.

Éles kép építése

Egy karcsú példa egy MySQL-hozzáférésű alkalmazáshoz:

FROM php:8.4-fpm-alpine

# Az éles konfiguráció bekapcsolása (a képdokumentáció szerint erősen ajánlott)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

# Csak a szükséges bővítmények
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql

# Saját beállítások
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# A kód a rooté; az FPM-workerek www-data-ként futnak, és csak olvasni tudják
COPY . /var/www/html

A kép segédszkriptjei átveszik a bővítmények építését: a docker-php-ext-configure az opciókhoz, a docker-php-ext-install az építéshez, a docker-php-ext-enable a bekapcsoláshoz, például egy pecl install után. Ha a docker-php-source-szal kicsomagolják a forráskódot, a dokumentáció szerint ugyanabban a rétegben ismét törölni kell. A zz-sicherheit.ini fájl így nézhet ki:

expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1

Két további alapelv teszi robusztusabbá a képeket. Először, a kiszállított kép csak azt tartalmazza, amit futásidőben használnak; a fordítók, a csomaggyorsítótárak és a tesztfájlok külön build-szakaszba valók. Másodszor, az a felhasználó, amelyként a PHP fut, csak ott írhat, ahol szükséges, például a feltöltési vagy gyorsítótár-könyvtárakban a csatolt volume-okon. Sok csapat emellett írásvédett fájlrendszerrel üzemelteti a konténert. Egy beszivárogtatott PHP-fájlnak ekkor sokkal nehezebb tartósan megmaradnia, és minden újraindítás visszaállítja a kép tiszta állapotát. Ez nem helyettesíti az incidens utáni vizsgálatot, de érezhetően csökkenti a támadási felületet.

Folyamatok, memória és naplók a konténerben

Három állítócsavar dönti el, hogy egy PHP-konténer stabilan fut-e.

1. A workerek száma: az FPM-pool pm.max_children értéke határozza meg, hány kérést dolgoznak fel egyidejűleg. Minden worker legfeljebb a memory_limit-ig foglalhat.
2. A konténer memóriahatára: az összes folyamatot együtt korlátozza. Durva szabály: a workerek száma szorozva a workerenkénti memóriával plusz tartalék a korlát alá kell, hogy férjen, különben a rendszer folyamatokat állít le.
3. Naplók: a konténerek a naplókat a szabványos kimenetre írják. A PHP-FPM-ben a catch_workers_output = yes a workerek kimeneteit a fő naplóba irányítja; e beállítás nélkül a kézikönyv szerint a semmibe vesznek.

Hasznos emellett a request_terminate_timeout, amely egy időtartam után leállítja az egyes kéréseket, ha a max_execution_time nem érvényesül. Hogyan üzemeltethet konténereket fürtben, azt a PHP javítása Kubernetesben írja le.

Konténerek és biztonság: amit a PHP2Shell megmutatott

A PHP2Shellnél a konténerek kettős szerepet játszanak. Egyfelől segítséget jelentenek: a php.net a CVE-2026-109618 elleni átmeneti intézkedésként azt ajánlja, hogy a memory_limit=-1 értéket konténeren vagy cgroupon keresztüli memóriahatárral kombinálják, ideális esetben úgy, hogy csak az érintett worker álljon le. Az RLIMIT_AS és az RLIMIT_DATA erre a php.net szerint alkalmatlan. Ez az intézkedés nem teljes védelem, és nem helyettesíti a frissítést.

Másfelől a konténerek csapdát jelentenek, ha a képeket nem építik újra. Egy PHP 8.4.26-os kép sebezhető marad, akárhányszor indul újra a konténer. Csak a 8.4.27-re vagy újabbra való újraépítés és az összes futó konténer cseréje zárja be a rést. Az állapotot közvetlenül a futó konténerben lehet ellenőrizni:

docker exec <container> php -v
docker exec <container> php-fpm -v
docker exec <container> php -r 'var_dump(ini_get("memory_hard_limit_percent"));'

Ha az utolsó parancs bool(false) értéket ad, a PHP nem ismeri a javított verziókkal bevezetett direktívát; a kézikönyv szerint a verzió ilyenkor érintett. Tartósan csak az automatikus újraépítés segít, ahogyan a CI/CD: PHP-képek automatikus újraépítése cikk leírja.

Hogyan segít konkrétan a PHP SOS?

A PHP-webszerverek keményítésénél a konténerekkel is foglalkozunk:

• Képek ellenőrzése: az alapkép, a PHP-verzió, a bővítmények és az egyes képek konfigurációja.
• A konfiguráció keményítése: éles ini, karcsú bővítménylista, megfelelő worker- és memóriahatárok.
• Az újraépítés beállítása: olyan folyamat, amely az új PHP-kiadásoknál újraépíti és kiadja a képeket.
• Futásidő ellenőrzése: igazoljuk, hogy minden futó konténerben a javított verzió fut.

Gyakori kérdések

Források

• Docker Official Image: PHP
• PHP-kézikönyv: FPM-konfiguráció
• php.net: Biztonsági közlemény, 2026. 10. 21.