Popravljanje PHP v containerjih Docker

Na kratko: Posodobitev slike PHP Docker je proti PHP2Shell obvezna in se ne zgodi sama od sebe. Sliko z odpravljeno različico PHP morate znova zgraditi ali prenesti, vsak container iz nje ustvariti znova in preveriti, da v tekočem containerju teče 8.5.12, 8.4.27, 8.3.36 ali 8.2.35. Preprost ponovni zagon containerja ne zadošča.

Zakaj containerji niso samodejno varni

Slika Docker je zamrznjen posnetek. PHP v njej ostane na stanju, ki ga je imel ob gradnji, tudi če so na gostitelju že zdavnaj nameščene posodobitve. Posodobitev paketov na gostiteljskem sistemu PHP v containerju ne spremeni.

Dodajo se tipične pasti: slike, zgrajene pred meseci in od takrat nedotaknjene, osnovne slike s fiksno oznako, kot je php:8.3.35-fpm, lokalni predpomnilniki, ki ob gradnji znova uporabijo staro osnovno sliko, in containerji, ki so bili sicer znova zagnani, a nikoli ustvarjeni znova. Prizadeti so vsi načini delovanja, ki so običajni v containerjih: PHP-FPM, Apache z mod_php in FrankenPHP.

Doda se še vprašanje odgovornosti. V številnih podjetjih je agencija ali razvijalec sliko enkrat zgradil, upravlja pa jo notranja IT ali ponudnik gostovanja. Takrat se nihče ne čuti odgovornega za stanje PHP v sliki. Zato najprej razjasnite, kdo sliko gradi, kje leži Dockerfile in kdo sme nameščati nove slike.

Preverjanje različice PHP v containerju

Preverite tekoči container, ne samo Dockerfile. Ukazi so izključno bralni.

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}"
docker exec <container> php -v
docker exec <container> php -i | grep -E "^PHP Version|Server API"
docker image inspect <image> --format "{{.Created}}"

Če slika uporablja pakete distribucije namesto uradnih gradenj PHP, preverite stanje paketa v containerju. Imena paketov se po osnovni distribuciji razlikujejo:

docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"

Pri paketih distribucij je lahko backport nameščen, čeprav številka različice ostane stara. Takrat šteje dnevnik sprememb paketa. Uradne slike PHP pa PHP večinoma prinašajo sami prevedenega; tam je merodajna vrednost številka različice iz php -v. Kako prepoznate backporte, opisuje stran Pravilno preverjanje različice PHP in stanja popravkov.

Posodobitev slike PHP Docker: zgraditi in namestiti

Lastna slika na osnovi slike PHP: osnovno sliko znova prenesti in zgraditi brez predpomnilnika.

docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # pred uvedbo preveriti različico

Z Docker Compose: slike prenesti oziroma zgraditi in container ustvariti znova.

docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate

Nato z docker exec <container> php -v znova preverite, ali teče nova različica. Če ima container v Dockerfile fiksno oznako različice, na primer FROM php:8.3.35-fpm, morate oznako dvigniti. Oznaka na vejo, kot je php:8.3-fpm, prejema nova stanja popravkov, vendar samo, če sliko znova prenesete.

Prejšnjo sliko hranite pripravljeno, dokler nova različica ni preizkušena. Ob napaki lahko tako preklopite nazaj, ne da bi aplikacija dolgo ostala brez povezave. Stara slika pa znova vsebuje ranljiv PHP; pot nazaj je zato upravičena samo kratek čas in z vmesnimi ukrepi.

Kdor uporablja Kubernetes, novo sliko namesti prek deploymenta. Podrobnosti so na strani Popravljanje PHP v Kubernetesu. Za slike FrankenPHP velja enak postopek; napotke o načinu delovanja najdete na strani Zavarovanje FrankenPHP.

Vmesni ukrepi v containerju

Če posodobitev še ni mogoča, vmesni ukrepi php.net veljajo tudi v containerju. Niso popolna zaščita. Omejitev pomnilnika sodi pri tem na container, saj jo php.net priporoča prek containerja ali cgroup, ne prek RLIMIT_AS ali RLIMIT_DATA:

; npr. kot datoteka v sliki: /usr/local/etc/php/conf.d/zz-uebergang.ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0

docker run --memory=1g ...         # ali v Compose: deploy.resources.limits.memory

Vrednost prilagodite svoji aplikaciji. Pazite, da aplikacija memory_limit ne more sama prepisati; pri PHP-FPM zato vrednosti nastavite v poolu s php_admin_value. Nova konfiguracija deluje šele, ko je container ustvarjen znova ali znova zagnan; ozadje o ponovnem zagonu je na strani Ponovni zagon PHP-FPM in vseh workerjev.

Da bo naslednjič hitreje

• Slike redno in samodejno zgraditi znova, ne samo ob spremembah kode.
• Uporabljati osnovne slike z oznako veje ter zgrajeno stanje označiti z datumom ali digestom.
• Slike pred namestitvijo dati preveriti glede znanih ranljivosti in containerje upravljati brez pravic root.
• Voditi popis, kateri container uporablja katero sliko.

Kako konkretno pomaga PHP SOS?

• Zabeležiti stanje: preverimo vse tekoče containerje, njihove slike in različice PHP, tudi stranske containerje in staging.
• Zgraditi in namestiti: prek storitve popravljanja PHP zgradimo slike z odpravljeno različico in containerje nadzorovano ustvarimo znova.
• Zavarovati prehod, kjer je posodobitev odvisna od aplikacije: vrednosti php.net, omejitev pomnilnika na containerju.
• Trajno nadzirati: z varnostnim nadzorom imamo v očeh stanja slik in sumljivo vedenje containerjev.

Pogosta vprašanja

Viri

• php.net: varnostna obvestila
• PHP 8 ChangeLog
• OWASP Cheat Sheets