Lühidalt: PHP käitamiseks konteinerites valite ametliku kujutise sobiva variandi (fpm, apache või cli), aktiveerite tootmise php.ini, paigaldate ainult vajalikud laiendid ning seate omavahel sobivad mälu- ja protsessipiirangud. Konteinerid on muutumatud: PHP turvauuendus nagu PHP2Shelli puhul mõjub alles siis, kui kujutis on uuesti ehitatud ja iga konteiner uuesti käivitatud. See uuesti ehitamine kuulub seetõttu kindla protsessina igasse konteinertöösse.
Miks PHP konteinerites?
Konteinerid pakivad PHP, laiendid ja seadistuse kujutisse, mis töötab igas serveris ühtemoodi. Ettevõtetele tähendab see: vähem üllatusi testi ja tootmise vahel, kiirem taastamine ja selged versiooniseisud. Turvalisuse jaoks tähendab see aga ka uut kohustust: konteineris ei paigalda keegi uuendusi automaatselt.
See leht käsitleb jooksvat tööd. Kuidas olemasolevaid konteinereid PHP2Shelli vastu konkreetselt paikada, on lehel PHP paikamine Dockeri konteinerites.
Õige kujutise variandi valimine
| Variant | Sisu | Tüüpiline kasutus |
|---|---|---|
php:<version>-fpm |
PHP-FPM, vajab ette ühendatud veebiserverit | tootmine Nginxi, Caddy või Ingressiga |
php:<version>-apache |
Apache koos mod_php-ga, vaikimisi mpm_prefork | lihtsad ülesehitused, vanemad rakendused |
php:<version>-cli |
käsurida, ainsa variandina sisaldab ka php-cgi | cron-tööd, järjekorra workerid, ehitussammud |
…-alpine |
Alpine Linuxil koos musl'iga | väikesed kujutised, mõne laiendi puhul vajalikud kohandused |
…-bookworm, …-trixie |
nimetatud Debiani versioonil | kindel alus reprodutseeritavate ehituste jaoks |
Uute projektide jaoks soovitub tavaliselt fpm-variant eraldi veebiserveri konteineriga. mod_php puhul näeb PHP meeskond PHP2Shelli seoses kõrgeimat riski; kes kasutab apache-kujutist, käitab just seda töörežiimi.
Tootmiskujutise ehitamine
Kitsas näide rakenduse kohta MySQL-i ligipääsuga:
FROM php:8.4-fpm-alpine
# Aktiveerida tootmisseadistus (kujutise dokumentatsiooni järgi tungivalt soovitatav)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
# Ainult vajalikud laiendid
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql
# Oma sätted
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"
# Kood kuulub root'ile; FPM workerid töötavad kasutajana www-data ja saavad seda ainult lugeda
COPY . /var/www/html
Kujutise abiskriptid võtavad laiendite ehitamise üle: docker-php-ext-configure valikute jaoks, docker-php-ext-install ehitamiseks, docker-php-ext-enable aktiveerimiseks, näiteks pärast pecl install. Kui käsuga docker-php-source lähtekood lahti pakitakse, peaks see dokumentatsiooni järgi samas kihis uuesti kustutatama. Fail zz-sicherheit.ini võiks välja näha selline:
expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1
Kaks täiendavat põhimõtet muudavad kujutised töökindlamaks. Esiteks sisaldab väljastatav kujutis ainult seda, mida käitamisel vaja läheb; kompilaatorid, paketivahemälud ja testifailid kuuluvad eraldi ehitusastmesse. Teiseks tohib kasutaja, kelle alt PHP töötab, kirjutada ainult seal, kus see on vajalik, näiteks üleslaadimis- või vahemälukataloogides ühendatud köidetel. Paljud tiimid käitavad konteinerit lisaks kirjutuskaitstud failisüsteemiga. Sissetoodud PHP-failil on siis tunduvalt raskem püsima jääda ja iga taaskäivitus taastab kujutise puhta seisu. See ei asenda uurimist pärast intsidenti, kuid vähendab ründepinda märgatavalt.
Protsessid, mälu ja logid konteineris
Kolm reguleerimiskruvi määravad, kas PHP konteiner töötab stabiilselt.
- Workerite arv:
pm.max_childrenFPM-poolis määrab, mitut päringut töödeldakse samaaegselt. Iga worker võib hõivata kunimemory_limit. - Konteineri mälupiir: See piirab kõiki protsesse kokku. Jämeda reeglina kehtib: workerite arv korrutatud workeri mäluga pluss reserv peab mahtuma piiri alla, muidu lõpetab süsteem protsesse.
- Logid: Konteinerid kirjutavad logid standardväljundisse. PHP-FPM-is suunab
catch_workers_output = yesworkerite väljundid põhilogisse; ilma selle sätteta lähevad need käsiraamatu järgi eikuhugi.
Abiks on lisaks request_terminate_timeout, mis lõpetab üksikud päringud pärast ajavahemikku, kui max_execution_time ei rakendu. Kuidas konteinereid klastris käitada, kirjeldab PHP paikamine Kubernetes'es.
Konteinerid ja turvalisus: mida PHP2Shell näitas
PHP2Shelli puhul mängivad konteinerid kahetist rolli. Ühelt poolt on need abiks: php.net soovitab CVE-2026-109618 ajutise meetmena kombineerida memory_limit=-1 mälupiiriga konteineri või cgroupi kaudu, ideaalis nii, et lõpetatakse ainult mõjutatud worker. RLIMIT_AS ja RLIMIT_DATA on selleks php.net järgi sobimatud. See meede ei ole täielik kaitse ega asenda uuendust.
Teiselt poolt on konteinerid lõks, kui kujutisi uuesti ei ehitata. Kujutis PHP 8.4.26-ga jääb haavatavaks, ükskõik kui tihti konteiner uuesti käivitub. Alles uuesti ehitamine versioonile 8.4.27 või uuemale ja kõigi töötavate konteinerite väljavahetamine sulgevad turvaaugu. Seisu saab kontrollida otse töötavas konteineris:
docker exec <container> php -v
docker exec <container> php-fpm -v
docker exec <container> php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Kui viimane käsk annab bool(false), ei tunne PHP parandatud versioonidega kasutusele võetud direktiivi; käsiraamatu järgi on versioon siis mõjutatud. Püsivalt aitab ainult automaatne uuesti ehitamine, nagu on kirjeldatud lehel CI/CD: PHP kujutiste automaatne uuesti ehitamine.
Määrake Dockerfile'is täpne PHP versioon sildis ja tõstke seda teadlikult. Nii on koodis jälgitav, millal milline versioon välja veeretati.
Kuidas PHP SOS konkreetselt aitab?
PHP veebiserverite karastamise raames hoolitseme ka konteinerite eest:
- Kujutiste kontroll: Iga kujutise baaskujutis, PHP versioon, laiendid ja seadistus.
- Seadistuse karastamine: Tootmise ini, kitsas laiendite nimekiri, sobivad workerite ja mälu piirid.
- Uuesti ehitamise sisseseadmine: Kulg, mis ehitab kujutised uute PHP väljalaskete korral uuesti ja veeretab välja.
- Töökeskkonna kontroll: Tõendame, et igas töötavas konteineris töötab parandatud versioon.
Korduma kippuvad küsimused
Milline PHP kujutise variant on õige?
Nginxi või muu puhverserveri jaoks fpm-variant, lihtsa ülesehituse jaoks Apache'iga apache-variant, skriptide ja cron-tööde jaoks cli-variant. Alpine'i variandid on väiksemad, kuid põhinevad glibc asemel musl'il, mis mõne laiendi puhul ilmneb.
Kas PHP uuendatakse konteineris automaatselt?
Ei. Töötav konteiner ei muutu. Peate kujutise uue PHP versiooniga uuesti ehitama ja konteinerid uuesti käivitama. Alles siis töötab parandatud versioon.
Kuidas suhtuvad memory_limit ja konteineri piir?
memory_limit piirab iga üksikut PHP päringut, konteineri piir kogu konteinerit. Mõlemad peavad kokku sobima: workerite arv korrutatud workeri mäluga peaks jääma konteineri piirist allapoole.
Kas ma vajan konteinerites php.ini?
Jah. Ametlikud kujutised tarnivad malliks php.ini-development ja php.ini-production. Tootmise jaoks soovitab kujutise dokumentatsioon selgesõnaliselt tootmismalli; oma sätted lähevad kataloogi conf.d.