Pe scurt: Imaginea PHP oficială de pe Docker Hub există în multe taguri, care combină versiunea, varianta (de exemplu cli, fpm, apache) și sistemul de bază. Un tag este un pointer care se mută spre niveluri noi după reconstruiri; doar digest-ul desemnează exact un nivel. Împotriva PHP2Shell aveți nevoie de o imagine cu PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, verificată cu php -v, și de o reconstruire a propriilor imagini pe aceasta.
De ce tagul singur spune puțin
Multe echipe scriu în Dockerfile un rând precum FROM php:8.3-fpm și apoi îl uită. Funcționează atât timp cât nu întreabă nimeni ce versiune PHP rulează de fapt. De la PHP2Shell, întreabă toată lumea.
Răspunsul nu se află în Dockerfile. Un tag precum 8.3-fpm indică, în momentul descărcării, cel mai nou nivel al acestei ramuri. Dacă imaginea a fost descărcată înainte de 21 octombrie și nu a fost reînnoită de atunci, ea conține o versiune vulnerabilă, deși tagul indică astăzi un nivel corectat. Conform directivelor Docker Official Images, imaginile sunt reconstruite activ, inclusiv la corecții de securitate. Nivelul dumneavoastră local nu este însă atins de aceasta.
Desfășurarea completă, de la reconstruire la containerul recreat, o descrie Patch PHP în containere Docker. Aici este vorba despre întrebarea preliminară: care este imaginea potrivită și cum dovediți nivelul ei?
Taguri de imagini Docker PHP: cum sunt construite
Tagurile se compun din până la trei părți. Docker Hub arată exemple precum php:8.2-cli, php:8.2-fpm-alpine sau php:8.4.27-zts-alpine3.24.
| Componentă | Exemplu | Semnificație |
|---|---|---|
| Indicarea versiunii | 8.4.27 sau 8.4 |
versiunea completă rămâne la acest nivel, indicarea ramurii se mută odată cu patchurile noi |
| Variantă | cli, fpm, apache, zts |
modul de operare al PHP în container |
| Sistem de bază | alpine3.24, bookworm, trixie |
versiunea Alpine sau Debian aflată la bază |
Variantele nu sunt echivalente pentru PHP2Shell. fpm operează PHP-FPM, apache operează PHP ca modul Apache, deci mod_php. Echipa PHP încadrează acest mod de operare drept cel mai ridicat, deoarece acolo a fost demonstrat un exploit înainte de a rula vreun cod al aplicației. Mai multe la De ce mod_php este deosebit de expus. Varianta cli este destinată sarcinilor din linia de comandă.
Și sistemul de bază are consecințe. Imaginile Alpine sunt mici, dar folosesc o altă bibliotecă C decât imaginile Debian; unele extensii sau biblioteci precompilate se comportă acolo diferit. Nu schimbați de aceea sistemul de bază în trecere, odată cu actualizarea de securitate, ci rămâneți mai întâi la ceea ce cunoaște aplicația dumneavoastră.
Important pentru înțelegere: în imaginea oficială, PHP nu provine din pachetele distribuției de bază. Docker Hub descrie că sursele PHP se află în imagine, iar extensiile se integrează prin scripturi auxiliare precum docker-php-ext-install. O actualizare de pachete a sistemului de bază în propriul Dockerfile nu schimbă de aceea nimic la versiunea PHP. Decisiv este doar pe ce nivel al imaginii oficiale construiți.
Tag sau digest: ce se schimbă și când
Un digest este o sumă de control peste conținutul unei imagini, scrisă ca sha256: urmat de un șir lung de caractere. Se schimbă cu fiecare reconstruire. Prin aceasta este potrivit ca dovadă: cine cunoaște digest-ul știe exact ce nivel rulează.
În practică s-a dovedit utilă o împărțire a sarcinilor:
- În Dockerfile folosiți tagul ramurii, de exemplu
php:8.4-fpm, pentru ca o reconstruire să primească automat cel mai nou patch al acestei ramuri. - În rollout folosiți digest-ul propriei imagini construite complet, pentru ca ceea ce se livrează să fie neechivoc.
- În documentație consemnați ambele: tagul, digest-ul și versiunea verificată cu
php -v.
Cine fixează în schimb un tag cu versiune completă, precum 8.3.35-fpm, nu primește niciodată automat un patch. Aceasta poate fi voit, dar necesită un proces care ridică tagul la fiecare anunț de securitate.
PHP2Shell: verificarea unei imagini înainte de utilizare
Comenzile următoare descarcă o imagine și citesc informații. Ele nu modifică niciun container care rulează.
# Descărcarea nivelului actual al tagului ramurii
docker pull php:8.4-fpm
# Ce versiune PHP se află în imagine?
docker run --rm php:8.4-fpm php -v
# Afișarea digest-ului imaginii descărcate
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Interogarea directă a digest-ului și a platformelor în registry
docker buildx imagetools inspect php:8.4-fpm
Interogarea cu imagetools arată la imaginile multi-platformă un digest superior și, dedesubt, câte unul propriu pentru fiecare platformă, de exemplu linux/amd64 sau linux/arm64. Documentați digest-ul pe care îl descarcă efectiv serverele dumneavoastră și rețineți că calculatoarele de dezvoltare cu altă arhitectură primesc un alt digest de platformă.
Dacă php -v nu arată cel puțin versiunea corectată a ramurii, imaginea este depășită sau provine dintr-o memorie intermediară. Verificați atunci dacă mediul dumneavoastră folosește o oglindă de registry care livrează niveluri vechi.
Pentru PHP 8.1 și mai vechi, proiectul PHP nu mai livrează lansări oficiale. O imagine oficială a acestor ramuri nu poate deci conține o versiune corectată obișnuită. Tagurile care nu mai sunt întreținute rămân, conform directivelor Docker, disponibile, dar nu mai sunt actualizate.
Conform Docker Hub, imaginea aduce php.ini-development și php.ini-production și recomandă insistent versiunea de producție pentru operarea productivă. Setările proprii le plasați ca fișier în $PHP_INI_DIR/conf.d/, inclusiv valorile provizorii de la php.net.
Greșeli tipice la alegerea imaginii
- Varianta aleasă din obișnuință: Se alege varianta apache pentru că pornește simplu, deși fpm cu server web separat ar fi posibil.
- Lipsa reconstruirii propriilor imagini: Imaginea de bază este actuală, imaginea de aplicație construită din ea nu.
- Build-uri în mai multe etape trecute cu vederea: Într-un Dockerfile cu mai multe rânduri
FROMeste adaptat doar unul. - Imagini secundare uitate: Workerii, containerele cron și instrumentele de administrare folosesc taguri proprii.
- Mizarea doar pe
latest: Tagul nu spune nimic despre ramură și variantă și poate sări neașteptat la o nouă ramură principală.
Cum automatizați reconstruirile, pentru ca o imagine depășită să nu ruleze prea mult, descrie CI/CD: reconstruirea automată a imaginilor PHP. Bazele PHP în containere le explică PHP în containere.
Cum ajută PHP SOS concret?
- Verificarea inventarului: Citim ce taguri, digest-uri și versiuni PHP se află în imaginile și containerele dumneavoastră care rulează.
- Evaluarea variantei: Verificăm dacă mod_php este necesar sau dacă fpm cu server web separat reduce riscul.
- Reconstruire și dovedire: Prin serviciul de patch PHP reconstruim imaginile pe o bază corectată și documentăm tagul, digest-ul și versiunea.
- Fixarea procesului: Configurăm Dockerfile-urile și rollout-urile astfel încât următorul patch să ajungă planificat.
Întrebări frecvente
Care este diferența dintre tag și digest?
Un tag precum php:8.4-fpm este un nume care, după fiecare reconstruire, poate indica un nivel nou. Un digest este o sumă de control care desemnează exact un singur nivel imuabil. Pentru dovezi și rollout-uri reproductibile, digest-ul este indicația mai de încredere.
Ce tag conține corecția PHP2Shell?
Sunt corectate PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Un tag cu număr complet de versiune arată direct nivelul. La taguri mai scurte, precum 8.4-fpm, verificați după descărcare cu php -v ce versiune este efectiv inclusă.
Există o imagine oficială actualizată pentru PHP 8.1?
Proiectul PHP nu mai livrează lansări oficiale pentru 8.1 și mai vechi. O imagine oficială a acestor ramuri nu poate deci conține o versiune corectată obișnuită. Planificați trecerea la o ramură acceptată.
Este varianta apache mai riscantă decât fpm?
Varianta apache operează PHP ca modul Apache, deci mod_php. Echipa PHP încadrează acest mod de operare drept cel mai ridicat la PHP2Shell. Ambele variante necesită actualizarea; la mod_php graba este deosebit de justificată.