Trenutno stanje: PHP2Shell. Dve kritični ranljivosti PHP (CVSS 9,2) omogočata izvedbo škodljive kode brez prijave. Popravki od 21. 10. 2026.Kaj je zdaj treba storiti →

Obratovanje PHP v vsebnikih

PHP v vsebniku potrebuje ustrezno različico slike, produkcijsko konfiguracijo, smiselne meje pomnilnika in postopek, ki sliko ob vsaki varnostni izdaji zgradi znova.

Stanje 4 min branjaZnanje o PHP

Na kratko: Za obratovanje PHP v vsebnikih izberite ustrezno različico uradne slike (fpm, apache ali cli), vklopite produkcijski php.ini, namestite samo potrebne razširitve in nastavite meje pomnilnika in procesov, ki se med seboj ujemajo. Vsebniki so nespremenljivi: varnostna posodobitev PHP, kot tista za PHP2Shell, učinkuje šele, ko je slika zgrajena znova in je vsak vsebnik znova zagnan. Ta ponovna gradnja zato sodi kot fiksen postopek v vsako obratovanje vsebnikov.

Zakaj PHP v vsebnikih?

Vsebniki PHP, razširitve in konfiguracijo zapakirajo v sliko, ki na vsakem strežniku teče enako. Za podjetja to pomeni: manj presenečenj med testom in produkcijo, hitrejša obnovitev in jasna stanja različic. Za varnost pa pomeni tudi novo obveznost: v vsebniku nihče samodejno ne nameša posodobitev.

Ta stran obravnava tekoče obratovanje. Kako obstoječe vsebnike konkretno popraviti proti PHP2Shell, je pod Popravljanje PHP v vsebnikih Docker.

Izbira prave različice slike

Različica Vsebina Tipična uporaba
php:<version>-fpm PHP-FPM, potrebuje predhodni spletni strežnik produkcija z Nginxom, Caddyjem ali ingressom
php:<version>-apache Apache z mod_php, privzeto mpm_prefork preproste postavitve, starejše aplikacije
php:<version>-cli ukazna vrstica, kot edina različica vsebuje tudi php-cgi cronjobi, delavci čakalnih vrst, koraki gradnje
…-alpine na Alpine Linux z musl majhne slike, pri nekaterih razširitvah potrebne prilagoditve
…-bookworm, …-trixie na navedeni različici Debian fiksna osnova za ponovljive gradnje

Za nove projekte se praviloma priporoča različica fpm z ločenim vsebnikom spletnega strežnika. Pri mod_php ekipa PHP v zvezi s PHP2Shell vidi najvišje tveganje; kdor uporablja sliko apache, deluje ravno v tem načinu.

Gradnja produkcijske slike

Vitek primer za aplikacijo z dostopom do MySQL:

FROM php:8.4-fpm-alpine

# Vklopiti produkcijsko konfiguracijo (po dokumentaciji slike nujno priporočeno)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

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

# Lastne nastavitve
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# Koda pripada uporabniku root; workerji FPM tečejo kot www-data in jo lahko samo berejo
COPY . /var/www/html

Pomožne skripte slike prevzamejo gradnjo razširitev: docker-php-ext-configure za možnosti, docker-php-ext-install za gradnjo, docker-php-ext-enable za vklop, na primer po pecl install. Če se z docker-php-source razpakira izvorna koda, jo je treba po dokumentaciji v isti plasti znova izbrisati. Datoteka zz-sicherheit.ini bi lahko izgledala takole:

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

Dve nadaljnji načeli slike naredita robustnejše. Prvič, dostavljena slika vsebuje samo to, kar je potrebno med izvajanjem; prevajalniki, predpomnilniki paketov in testne datoteke sodijo v lastno stopnjo gradnje. Drugič, uporabnik, pod katerim teče PHP, sme pisati samo tam, kjer je potrebno, na primer v imenikih za nalaganje ali predpomnilnik na vključenih nosilcih (volume). Številne ekipe vsebnik dodatno poganjajo z datotečnim sistemom, zaščitenim pred pisanjem. Vrinjeni datoteki PHP je tedaj bistveno težje ostati trajno, vsak ponovni zagon pa znova vzpostavi čisto stanje slike. To ne nadomesti preiskave po incidentu, opazno pa zmanjša napadalno površino.

Procesi, pomnilnik in dnevniki v vsebniku

Tri nastavitve določajo, ali vsebnik PHP stabilno teče.

  1. Število workerjev: pm.max_children v poolu FPM določa, koliko zahtev se obdeluje hkrati. Vsak worker lahko zaseda do memory_limit.
  2. Meja pomnilnika vsebnika: omejuje vse procese skupaj. Kot groba velja: število workerjev krat pomnilnik na workerja plus rezerva mora ustrezati meji, sicer sistem procese konča.
  3. Dnevniki: vsebniki dnevnike pišejo na standardni izhod. V PHP-FPM catch_workers_output = yes izpise workerjev preusmeri v glavni dnevnik; brez te nastavitve po priročniku pristanejo v nič.

Koristen je tudi request_terminate_timeout, ki posamezne zahteve po določenem času konča, kadar max_execution_time ne deluje. Kako vsebnike obratovati v gruči, opisuje Popravljanje PHP v Kubernetes.

Vsebniki in varnost: kaj je pokazal PHP2Shell

Pri PHP2Shell imajo vsebniki dvojno vlogo. Na eni strani so pomoč: php.net kot prehodni ukrep za CVE-2026-109618 priporoča kombinacijo memory_limit=-1 z mejo pomnilnika prek vsebnika ali cgroup, idealno tako, da se konča samo prizadeti worker. RLIMIT_AS in RLIMIT_DATA sta za to po php.net neprimerna. Ta ukrep ni popolna zaščita in posodobitve ne nadomesti.

Na drugi strani so vsebniki past, če se slike ne zgradijo znova. Slika s PHP 8.4.26 ostane ranljiva, ne glede na to, kako pogosto se vsebnik znova zažene. Šele ponovna gradnja na 8.4.27 ali novejši in zamenjava vseh tekočih vsebnikov vrzel zapreta. Stanje je mogoče preveriti neposredno v tekočem vsebniku:

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

Če zadnji ukaz vrne bool(false), PHP ne pozna direktive, uvedene s popravljenimi različicami; po priročniku je različica tedaj prizadeta. Trajno pomaga samo samodejna ponovna gradnja, kot je opisana pod CI/CD: samodejna ponovna gradnja slik PHP.

Nasvet

V Dockerfile določite natančno različico PHP v oznaki in jo zvišujte zavestno. Tako je v kodi sledljivo, kdaj je bila katera različica razdeljena.

Kako PHP SOS pomaga konkretno?

Pri utrjevanju strežnikov PHP skrbimo tudi za vsebnike:

  • Preveriti slike: osnovna slika, različica PHP, razširitve in konfiguracija vsake slike.
  • Utrditi konfiguracijo: produkcijski ini, vitek seznam razširitev, ustrezne meje workerjev in pomnilnika.
  • Vzpostaviti ponovno gradnjo: potek, ki slike ob novih izdajah PHP zgradi znova in jih razdeli.
  • Nadzorovati izvajalno okolje: dokažemo, da v vsakem tekočem vsebniku teče popravljena različica.

Pogosta vprašanja

Katera različica slike PHP je prava?

Za Nginx ali drug proxy različica fpm, za preprosto postavitev z Apacheem različica apache, za skripte in cronjobe različica cli. Različice Alpine so manjše, a temeljijo na musl namesto glibc, kar pri nekaterih razširitvah pride do izraza.

Ali se PHP v vsebniku posodablja samodejno?

Ne. Tekoči vsebnik se ne spreminja. Sliko z novo različico PHP je treba zgraditi znova in vsebnike znova zagnati. Šele potem teče popravljena različica.

Kako sta povezana memory_limit in meja vsebnika?

memory_limit omejuje vsako posamezno zahtevo PHP, meja vsebnika pa celoten vsebnik. Obe se morata ujemati: število workerjev krat pomnilnik na workerja naj bo pod mejo vsebnika.

Ali v vsebnikih potrebujem php.ini?

Da. Uradne slike kot predlogi prinašajo php.ini-development in php.ini-production. Za produkcijo dokumentacija slik izrecno priporoča produkcijsko predlogo; lastne nastavitve pridejo v conf.d.

Viri

Takojšnji stik

Vsaka ura šteje. Pišite nam zdaj.

Na kratko opišite sistem, različico PHP in opažanje. Odzovemo se, razjasnimo stanje in delamo na daljavo, dokler incident ni zaključen in dokumentiran.

Takojšnja pomoč