Εν συντομία: Για να λειτουργήσετε την PHP σε containers, επιλέγετε την κατάλληλη παραλλαγή της επίσημης εικόνας (fpm, apache ή cli), ενεργοποιείτε το php.ini παραγωγής, εγκαθιστάτε μόνο τις απαραίτητες επεκτάσεις και ορίζετε όρια μνήμης και διεργασιών που ταιριάζουν μεταξύ τους. Τα containers είναι αμετάβλητα: μια ενημέρωση ασφαλείας της PHP όπως για το PHP2Shell γίνεται αποτελεσματική μόνο όταν η εικόνα ξαναχτιστεί και κάθε container επανεκκινηθεί. Αυτό το νέο χτίσιμο ανήκει γι' αυτό ως σταθερή διαδικασία σε κάθε λειτουργία containers.
Γιατί η PHP σε containers;
Τα containers συσκευάζουν την PHP, τις επεκτάσεις και τη διαμόρφωση σε μια εικόνα που εκτελείται με τον ίδιο τρόπο σε κάθε διακομιστή. Για τις επιχειρήσεις αυτό σημαίνει: λιγότερες εκπλήξεις μεταξύ δοκιμής και παραγωγής, ταχύτερη αποκατάσταση και σαφή επίπεδα εκδόσεων. Για την ασφάλεια σημαίνει όμως και μια νέα υποχρέωση: κανείς δεν εγκαθιστά αυτόματα ενημερώσεις σε ένα container.
Αυτή η σελίδα αφορά την τρέχουσα λειτουργία. Πώς θα διορθώσετε συγκεκριμένα τα υπάρχοντα containers έναντι του PHP2Shell, υπάρχει στη σελίδα Patch της PHP σε containers Docker.
Επιλογή της σωστής παραλλαγής εικόνας
| Παραλλαγή | Περιεχόμενο | Τυπική χρήση |
|---|---|---|
php:<version>-fpm |
PHP-FPM, χρειάζεται διακομιστή ιστού μπροστά | Παραγωγή με Nginx, Caddy ή ingress |
php:<version>-apache |
Apache με mod_php, από προεπιλογή mpm_prefork | απλές δομές, παλαιότερες εφαρμογές |
php:<version>-cli |
γραμμή εντολών, περιέχει ως μοναδική παραλλαγή και το php-cgi | Cronjobs, queue workers, βήματα build |
…-alpine |
σε Alpine Linux με musl | μικρές εικόνες, σε ορισμένες επεκτάσεις απαιτούνται προσαρμογές |
…-bookworm, …-trixie |
στην αναφερόμενη έκδοση Debian | σταθερή βάση για αναπαραγώγιμα builds |
Για νέα έργα συνιστάται συνήθως η παραλλαγή fpm με ξεχωριστό container διακομιστή ιστού. Στο mod_php η ομάδα της PHP βλέπει στο πλαίσιο του PHP2Shell τον υψηλότερο κίνδυνο· όποιος χρησιμοποιεί την εικόνα apache, λειτουργεί ακριβώς αυτόν τον τρόπο λειτουργίας.
Χτίσιμο μιας εικόνας παραγωγής
Ένα λιτό παράδειγμα για μια εφαρμογή με πρόσβαση σε MySQL:
FROM php:8.4-fpm-alpine
# Ενεργοποίηση της διαμόρφωσης παραγωγής (σύμφωνα με την τεκμηρίωση της εικόνας, συνιστάται έντονα)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
# Μόνο οι απαραίτητες επεκτάσεις
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql
# Δικές σας ρυθμίσεις
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"
# Ο κώδικας ανήκει στον root· οι workers του FPM εκτελούνται ως www-data και μπορούν μόνο να τον διαβάσουν
COPY . /var/www/html
Τα βοηθητικά σενάρια της εικόνας αναλαμβάνουν το χτίσιμο των επεκτάσεων: docker-php-ext-configure για επιλογές, docker-php-ext-install για το χτίσιμο, docker-php-ext-enable για την ενεργοποίηση, για παράδειγμα μετά από pecl install. Αν ο πηγαίος κώδικας αποσυμπιεστεί με το docker-php-source, πρέπει σύμφωνα με την τεκμηρίωση να διαγραφεί ξανά στο ίδιο στρώμα. Το αρχείο zz-sicherheit.ini θα μπορούσε να μοιάζει ως εξής:
expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1
Δύο ακόμη αρχές κάνουν τις εικόνες πιο στιβαρές. Πρώτον, η εικόνα που παραδίδεται περιέχει μόνο ό,τι χρειάζεται κατά την εκτέλεση· μεταγλωττιστές, caches πακέτων και αρχεία δοκιμών ανήκουν σε ξεχωριστό στάδιο build. Δεύτερον, ο χρήστης υπό τον οποίο εκτελείται η PHP επιτρέπεται να γράφει μόνο εκεί όπου χρειάζεται, για παράδειγμα σε καταλόγους μεταφορτώσεων ή cache σε συνδεδεμένα volumes. Πολλές ομάδες λειτουργούν επιπλέον το container με σύστημα αρχείων μόνο για ανάγνωση. Ένα αρχείο PHP που έχει εισαχθεί κακόβουλα δυσκολεύεται τότε σαφώς περισσότερο να παραμείνει μόνιμα και κάθε επανεκκίνηση αποκαθιστά την καθαρή κατάσταση της εικόνας. Αυτό δεν αντικαθιστά μια διερεύνηση μετά από περιστατικό, μειώνει όμως αισθητά την επιφάνεια επίθεσης.
Διεργασίες, μνήμη και logs στο container
Τρεις ρυθμιστικές βίδες καθορίζουν αν ένα container PHP εκτελείται σταθερά.
- Αριθμός workers: το
pm.max_childrenστο pool του FPM ορίζει πόσα αιτήματα επεξεργάζονται ταυτόχρονα. Κάθε worker μπορεί να καταλάβει έως τοmemory_limit. - Όριο μνήμης του container: περιορίζει όλες τις διεργασίες μαζί. Ως πρόχειρος κανόνας ισχύει: ο αριθμός workers επί τη μνήμη ανά worker συν απόθεμα πρέπει να χωρά κάτω από το όριο, διαφορετικά το σύστημα τερματίζει διεργασίες.
- Logs: τα containers γράφουν logs στην τυπική έξοδο. Στο PHP-FPM το
catch_workers_output = yesπροωθεί τις εξόδους των workers στο κύριο log· χωρίς τη ρύθμιση χάνονται σύμφωνα με το εγχειρίδιο στο κενό.
Χρήσιμο είναι επίσης το request_terminate_timeout, που τερματίζει μεμονωμένα αιτήματα μετά από ένα χρονικό διάστημα, όταν δεν ισχύει το max_execution_time. Πώς λειτουργείτε containers σε cluster, περιγράφει η σελίδα Patch της PHP στο Kubernetes.
Containers και ασφάλεια: τι έδειξε το PHP2Shell
Στο PHP2Shell τα containers παίζουν διπλό ρόλο. Αφενός είναι βοήθεια: το php.net συνιστά ως προσωρινό μέτρο για την CVE-2026-109618 τον συνδυασμό του memory_limit=-1 με ένα όριο μνήμης μέσω container ή cgroup, ιδανικά έτσι ώστε να τερματίζεται μόνο ο επηρεαζόμενος worker. Τα RLIMIT_AS και RLIMIT_DATA είναι γι' αυτό κατά το php.net ακατάλληλα. Αυτό το μέτρο δεν αποτελεί πλήρη προστασία και δεν αντικαθιστά την ενημέρωση.
Αφετέρου τα containers αποτελούν παγίδα, όταν οι εικόνες δεν ξαναχτίζονται. Μια εικόνα με PHP 8.4.26 παραμένει ευάλωτη, όσο συχνά κι αν επανεκκινείται το container. Μόνο ένα νέο χτίσιμο στην 8.4.27 ή νεότερη και η αντικατάσταση όλων των containers που εκτελούνται κλείνουν την ευπάθεια. Η κατάσταση μπορεί να ελεγχθεί απευθείας στο container που εκτελείται:
docker exec <container> php -v
docker exec <container> php-fpm -v
docker exec <container> php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Αν η τελευταία εντολή επιστρέψει bool(false), η PHP δεν γνωρίζει την οδηγία που εισήχθη με τις εκδόσεις διόρθωσης· σύμφωνα με το εγχειρίδιο η έκδοση επηρεάζεται τότε. Μόνιμα βοηθά μόνο ένα αυτόματο νέο χτίσιμο, όπως περιγράφεται στη σελίδα CI/CD: αυτόματο νέο χτίσιμο εικόνων PHP.
Ορίστε στο Dockerfile την ακριβή έκδοση PHP στο tag και αυξήστε την συνειδητά. Έτσι είναι ανιχνεύσιμο στον κώδικα πότε διατέθηκε ποια έκδοση.
Πώς βοηθά συγκεκριμένα η PHP SOS;
Στη θωράκιση διακομιστών ιστού PHP φροντίζουμε και για τα containers:
- Έλεγχος εικόνων: Βασική εικόνα, έκδοση PHP, επεκτάσεις και διαμόρφωση κάθε εικόνας.
- Θωράκιση διαμόρφωσης: ini παραγωγής, λιτή λίστα επεκτάσεων, κατάλληλα όρια workers και μνήμης.
- Στήσιμο νέου χτισίματος: Μια ροή που ξαναχτίζει και διαθέτει τις εικόνες σε νέες εκδόσεις PHP.
- Έλεγχος κατά την εκτέλεση: Αποδεικνύουμε ότι σε κάθε container που εκτελείται λειτουργεί η διορθωμένη έκδοση.
Συχνές ερωτήσεις
Ποια παραλλαγή της εικόνας PHP είναι η σωστή;
Για Nginx ή άλλον proxy η παραλλαγή fpm, για μια απλή δομή με Apache η παραλλαγή apache, για σενάρια και cronjobs η παραλλαγή cli. Οι παραλλαγές Alpine είναι μικρότερες, βασίζονται όμως στη musl αντί για τη glibc, κάτι που γίνεται αισθητό σε ορισμένες επεκτάσεις.
Ενημερώνεται αυτόματα η PHP σε container;
Όχι. Ένα container που εκτελείται δεν αλλάζει. Πρέπει να ξαναχτίσετε την εικόνα με τη νέα έκδοση PHP και να επανεκκινήσετε τα containers. Μόνο τότε εκτελείται η διορθωμένη έκδοση.
Πώς συμπεριφέρονται το memory_limit και το όριο του container;
Το memory_limit περιορίζει κάθε μεμονωμένο αίτημα PHP, το όριο του container ολόκληρο το container. Και τα δύο πρέπει να ταιριάζουν: ο αριθμός των workers επί τη μνήμη ανά worker πρέπει να βρίσκεται κάτω από το όριο του container.
Χρειάζομαι php.ini σε containers;
Ναι. Οι επίσημες εικόνες συνοδεύονται από τα php.ini-development και php.ini-production ως πρότυπα. Για παραγωγή η τεκμηρίωση της εικόνας συνιστά ρητά το πρότυπο παραγωγής· οι δικές σας ρυθμίσεις μπαίνουν στο conf.d.