Rad PHP-a u containerima

Ukratko: Za rad PHP-a u containerima odaberite odgovarajuću varijantu službene slike (fpm, apache ili cli), aktivirajte produkcijski php.ini, instalirajte samo potrebne ekstenzije i postavite granice memorije i procesa koje su međusobno usklađene. Containeri su nepromjenjivi: PHP sigurnosno ažuriranje, kao ono za PHP2Shell, djeluje tek kad se slika iznova izgradi i svaki se container ponovno pokrene. Ta ponovna gradnja zato u svaki rad s containerima pripada kao čvrst proces.

Zašto PHP u containerima?

Containeri pakiraju PHP, ekstenzije i konfiguraciju u sliku koja na svakom poslužitelju radi jednako. Za poduzeća to znači: manje iznenađenja između testa i produkcije, brži oporavak i jasna stanja verzija. Za sigurnost to ipak znači i novu obvezu: u containeru nitko automatski ne instalira ažuriranja.

Ova stranica obrađuje tekući rad. Kako postojeće containere konkretno zakrpati protiv PHP2Shella, piše na stranici Zakrpa PHP-a u Docker containerima.

Odabir prave varijante slike

Za nove projekte u pravilu se preporučuje varijanta fpm sa zasebnim containerom web-poslužitelja. Kod mod_php-a PHP tim u vezi s PHP2Shellom vidi najviši rizik; tko koristi sliku apache, upravo taj način rada i vodi.

Izgradnja produkcijske slike

Vitak primjer za aplikaciju s pristupom MySQL-u:

FROM php:8.4-fpm-alpine

# Aktivirati produkcijsku konfiguraciju (prema dokumentaciji slike dosta preporučeno)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

# Samo potrebne ekstenzije
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql

# Vlastite postavke
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# Kod pripada rootu; FPM workeri rade kao www-data i mogu ga samo čitati
COPY . /var/www/html

Pomoćne skripte slike preuzimaju gradnju ekstenzija: docker-php-ext-configure za opcije, docker-php-ext-install za gradnju, docker-php-ext-enable za aktiviranje, primjerice nakon pecl install. Ako se s docker-php-source raspakira izvorni kod, prema dokumentaciji treba ga obrisati u istom sloju. Datoteka zz-sicherheit.ini mogla bi izgledati ovako:

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

Još dva načela čine slike otpornijima. Prvo, isporučena slika sadrži samo ono što je potrebno tijekom izvođenja; kompilatori, predmemorije paketa i testne datoteke pripadaju u zasebnu fazu gradnje. Drugo, korisnik pod kojim PHP radi smije pisati samo ondje gdje je nužno, primjerice u direktorije za upload ili cache na priključenim volumenima. Mnogi timovi container dodatno pokreću sa zaštićenim od pisanja datotečnim sustavom. Ubačena PHP datoteka tada se znatno teže trajno zadržava, a svako ponovno pokretanje vraća čisto stanje slike. To ne zamjenjuje istragu nakon incidenta, ali osjetno smanjuje površinu napada.

Procesi, memorija i zapisnici u containeru

Tri vijka određuju radi li PHP container stabilno.

1. Broj workera: pm.max_children u FPM poolu određuje koliko se zahtjeva istodobno obrađuje. Svaki worker može zauzeti do memory_limit.
2. Ograničenje memorije containera: Ograničava sve procese zajedno. Kao gruba pravila vrijedi: broj workera puta memorija po workeru plus rezerva mora stati ispod ograničenja, inače sustav prekida procese.
3. Zapisnici: Containeri zapisnike pišu na standardni izlaz. U PHP-FPM-u catch_workers_output = yes izlaze workera preusmjerava u glavni zapisnik; bez te postavke prema priručniku nestaju u ništa.

Korisna je i request_terminate_timeout, koja pojedine zahtjeve prekida nakon određenog vremena ako max_execution_time ne djeluje. Kako containere voditi u klasteru, opisuje Zakrpa PHP-a u Kubernetesu.

Containeri i sigurnost: što je pokazao PHP2Shell

Kod PHP2Shella containeri imaju dvostruku ulogu. S jedne strane pomažu: php.net kao prijelaznu mjeru za CVE-2026-109618 preporučuje kombiniranje memory_limit=-1 s ograničenjem memorije putem containera ili cgroupa, idealno tako da se prekida samo pogođeni worker. RLIMIT_AS i RLIMIT_DATA prema php.net za to nisu prikladni. Ta mjera nije potpuna zaštita i ne zamjenjuje ažuriranje.

S druge strane, containeri su zamka ako se slike ne grade iznova. Slika s PHP-om 8.4.26 ostaje ranjiva koliko god puta se container ponovno pokrenuo. Tek ponovna gradnja na 8.4.27 ili noviju i zamjena svih pokrenutih containera zatvaraju ranjivost. Stanje se može provjeriti izravno u pokrenutom containeru:

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

Ako posljednja naredba vrati bool(false), PHP ne poznaje direktivu uvedenu s verzijama s ispravkom; prema priručniku je verzija tada pogođena. Trajno pomaže samo automatska ponovna gradnja, kako je opisano u članku CI/CD: automatska ponovna gradnja PHP slika.

Kako PHP SOS konkretno pomaže?

Pri ojačavanju poslužitelja za PHP web-poslužitelje brinemo se i za containere:

• Provjeriti slike: Osnovna slika, verzija PHP-a, ekstenzije i konfiguracija svake slike.
• Ojačati konfiguraciju: Produkcijski ini, vitak popis ekstenzija, odgovarajuće granice workera i memorije.
• Postaviti ponovnu gradnju: Tijek koji slike iznova gradi i pušta pri novim PHP izdanjima.
• Kontrolirati vrijeme izvođenja: Dokazujemo da u svakom pokrenutom containeru radi ispravljena verzija.

Česta pitanja

Izvori

• Docker Official Image: PHP
• PHP priručnik: FPM konfiguracija
• php.net: Sigurnosna obavijest od 21. 10. 2026.