# Ασφάλεια του Apache με mod_php

> Apache mod_php μετά το PHP2Shell: αναγνώριση του τρόπου λειτουργίας, patch της μονάδας PHP, πλήρης επανεκκίνηση του Apache και σωστή προετοιμασία μετάβασης στο PHP-FPM.

Πηγή: https://phpsos.de/el/server/apache-mod-php/  
Ημερομηνία: 25/10/2026  
Πάροχος: PHP SOS, Επείγουσα βοήθεια PHP και ασφάλεια διακομιστών. Άμεση βοήθεια μέσω WhatsApp: https://wa.me/491736494914?text=%CE%93%CE%B5%CE%B9%CE%B1%20%CF%83%CE%B1%CF%82%2C%20PHP%20SOS%2C%20%CF%87%CF%81%CE%B5%CE%B9%CE%B1%CE%B6%CF%8C%CE%BC%CE%B1%CF%83%CF%84%CE%B5%20%CE%B2%CE%BF%CE%AE%CE%B8%CE%B5%CE%B9%CE%B1%20%CE%BC%CE%B5%20%CF%84%CE%BF%CE%BD%20%CE%B4%CE%B9%CE%B1%CE%BA%CE%BF%CE%BC%CE%B9%CF%83%CF%84%CE%AE%20PHP%20%CE%BC%CE%B1%CF%82.%20%CE%95%CF%84%CE%B1%CE%B9%CF%81%CE%B5%CE%AF%CE%B1%3A%20%E2%80%A6%20%CE%99%CF%83%CF%84%CF%8C%CF%84%CE%BF%CF%80%CE%BF%CF%82%3A%20%E2%80%A6

**Εν συντομία:** Στον Apache με mod_php η PHP εκτελείται απευθείας μέσα στον διακομιστή ιστού. Η ομάδα της PHP κατατάσσει τον κίνδυνο από το PHP2Shell ακριβώς σε αυτόν τον τρόπο λειτουργίας ως τον υψηλότερο, επειδή επιδείχθηκε exploit προτού καν εκτελεστεί κώδικας της εφαρμογής. Κάντε αμέσως patch, επανεκκινήστε πλήρως τον Apache και σχεδιάστε στη συνέχεια τη μετάβαση στο PHP-FPM.

## Τι είναι το mod_php και γιατί μετράει τώρα

Στο mod_php ο Apache φορτώνει την PHP ως μονάδα σε κάθε δική του διεργασία εργασίας. Κάθε αίτημα προς ένα αρχείο PHP εκτελείται απευθείας σε αυτή τη διεργασία. Αυτό ήταν για πολύ καιρό το πρότυπο και ρυθμίζεται εύκολα. Σημαίνει όμως επίσης: όλοι οι ιστότοποι του διακομιστή εκτελούνται με τον ίδιο χρήστη και η PHP μοιράζεται τη διεργασία με τον διακομιστή ιστού.

Το PHP2Shell περιλαμβάνει τις ευπάθειες CVE-2026-109618 και CVE-2026-109619, και τις δύο με CVSS v4.0 9,2. Στη δεύτερη, εσωτερική κατάσταση ενός αιτήματος μπορεί να παραμείνει μετά την αποδέσμευση της μνήμης και να χρησιμοποιηθεί από ένα μεταγενέστερο αίτημα στην ίδια διεργασία. Για το mod_php η ομάδα της PHP διαπίστωσε τον υψηλότερο κίνδυνο. Το υπόβαθρο και η ένταξη περιγράφονται στη σελίδα [Γιατί το mod_php φέρει τον υψηλότερο κίνδυνο](https://phpsos.de/el/php2shell/mod-php-risiko/).

## Αναγνώριση του Apache mod_php και έλεγχος έκδοσης

Ελέγξτε πρώτα αν ο Apache σας χρησιμοποιεί καθόλου mod_php. Οι παρακάτω εντολές μόνο διαβάζουν. Τα ονόματα εντολών και πακέτων διαφέρουν ανά διανομή και είναι παραδείγματα.

```bash
# Debian/Ubuntu: φορτωμένες μονάδες
apache2ctl -M 2>/dev/null | grep -i php

# Οικογένεια RHEL
httpd -M 2>/dev/null | grep -i php

# Ποιο MPM είναι ενεργό; Το mod_php προϋποθέτει prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Επίπεδο πακέτου της μονάδας (παραδείγματα)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
```

Αν εμφανίζεται μονάδα όπως η `php_module`, εκτελείται mod_php. Η εμφανιζόμενη έκδοση PHP από μόνη της δεν αποτελεί απόδειξη για το patch, επειδή οι διανομές εφαρμόζουν συχνά τις διορθώσεις ως backport. Διορθωμένες εκδόσεις του έργου PHP είναι οι 8.5.12, 8.4.27, 8.3.36 και 8.2.35. Στα πακέτα διανομής μετράει το changelog με τους αριθμούς CVE.

## Patch και πλήρης επανεκκίνηση του Apache

Εφαρμόστε την ενημέρωση μέσω του διαχειριστή πακέτων. Επειδή η PHP βρίσκεται μέσα στη διεργασία του Apache, πρέπει στη συνέχεια να επανεκκινηθεί ολόκληρη η υπηρεσία. Η επαναφόρτωση της διαμόρφωσης δεν είναι εδώ ο ασφαλής δρόμος.

```bash
# Debian/Ubuntu
systemctl restart apache2

# Οικογένεια RHEL
systemctl restart httpd

# Έλεγχος: ώρα εκκίνησης όλων των διεργασιών του Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
```

Όλες οι διεργασίες του Apache πρέπει να δείχνουν ώρα εκκίνησης μετά την ενημέρωση. Αν στον ίδιο διακομιστή εκτελείται επιπλέον PHP-FPM ή php-cgi, επανεκκινήστε και αυτές τις υπηρεσίες.

> **Δράστε άμεσα:**
> Αν για την έκδοση PHP σας δεν υπάρχει ακόμη διαθέσιμο patch, το BSI (Ομοσπονδιακή Υπηρεσία Ασφάλειας Πληροφοριών της Γερμανίας) συνιστά να αποσυνδέσετε προσωρινά τον διακομιστή ιστού από το δίκτυο. Στο mod_php αυτό βαραίνει ιδιαίτερα, επειδή η επίθεση μπορεί να πετύχει πριν από τον κώδικα της εφαρμογής.

## Προσωρινά μέτρα στη διαμόρφωση του Apache

Το php.net αναφέρει προσωρινά μέτρα που μειώνουν τον κίνδυνο, αλλά δεν προσφέρουν πλήρη προστασία. Στο mod_php ορίζετε τις τιμές με `php_admin_value` ή `php_admin_flag` στη διαμόρφωση του Apache, ώστε το `.htaccess` και οι εφαρμογές να μην μπορούν να τις αντικαταστήσουν.

```apache
# Παράδειγμα: στη διαμόρφωση VirtualHost ή σε επίπεδο διακομιστή
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>
```

Με λειτουργία upload το php.net αναφέρει `post_max_size = 32M`, με το `upload_max_filesize` χαμηλότερα. Στην PHP 8.5 προστίθεται το `fatal_error_backtraces=0`. Την υπόδειξη για το `memory_limit=-1` την εφαρμόζετε μόνο μαζί με όριο μνήμης για την υπηρεσία μέσω cgroups, για παράδειγμα με `MemoryMax` σε συμπλήρωμα του systemd, και όχι μέσω `RLIMIT_AS` ή `RLIMIT_DATA`. Στη συνέχεια επανεκκινήστε πλήρως τον Apache. Όλα τα μέτρα με μια ματιά: [Άμεσα μέτρα χωρίς patch](https://phpsos.de/el/php2shell/sofortmassnahmen-ohne-patch/).

## Ο δρόμος μακριά από το mod_php

Μετά το οξύ patch αξίζει η μετάβαση στο PHP-FPM. Εκεί η PHP εκτελείται σε δικές της διεργασίες, χωριστά από τον διακομιστή ιστού. Κάθε ιστότοπος μπορεί να αποκτήσει δικό του pool με δικό του χρήστη, τα όρια μπορούν να οριστούν ανά pool και οι επανεκκινήσεις αφορούν μόνο την PHP. Ο Apache συνδέει το PHP-FPM μέσω `mod_proxy_fcgi` και μπορεί τότε να χρησιμοποιεί αντί για prefork ένα πιο σύγχρονο MPM όπως το event.

Σχεδιάστε τη μετάβαση σε περιβάλλον δοκιμών: δημιουργία pools ανά ιστότοπο, προσαρμογή των δικαιωμάτων αρχείων στους νέους χρήστες, μεταφορά των καταχωρίσεων `.htaccess` με `php_value` στις ρυθμίσεις του pool, εκτέλεση δοκιμών φορτίου. Πώς μοιάζει μια σωστή δομή, δείχνει η σελίδα [Ασφάλεια Nginx με PHP-FPM](https://phpsos.de/el/server/nginx-php-fpm/)· οι αρχές ισχύουν εξίσου για τον Apache με PHP-FPM.

Ανεξάρτητα από τον τρόπο λειτουργίας ισχύει: ένα patch δεν αφαιρεί κακόβουλο λογισμικό που έχει ήδη εισαχθεί. Διατηρήστε τα logs από τις 20/10/2026 και ελέγξτε τον διακομιστή για ίχνη.

Στην αναζήτηση ιχνών σε διακομιστές mod_php αξίζει μια ματιά στον κοινό χρήστη. Επειδή όλοι οι ιστότοποι εκτελούνται με τον χρήστη του Apache, για παράδειγμα `www-data` ή `apache`, ένας επιτιθέμενος που έχει αναλάβει έναν ιστότοπο μπορεί κατά κανόνα να διαβάσει και να τροποποιήσει και τα αρχεία των υπόλοιπων. Ελέγξτε γι' αυτό όχι μόνο τον ιστότοπο που σας φαίνεται ύποπτος, αλλά όλα τα document roots του διακομιστή. Προσέξτε ιδιαίτερα αρχεία PHP με πρόσφατη ημερομηνία τροποποίησης σε καταλόγους uploads και cache, κώδικα προγράμματος που ανήκει στον χρήστη του Apache και άγνωστες καταχωρίσεις στο crontab αυτού του χρήστη. Αν βρείτε κάτι, διασώστε πρώτα την κατάσταση και μη διαγράψετε βιαστικά, ώστε η αιτία να παραμείνει αργότερα ανιχνεύσιμη.

## Πώς βοηθά συγκεκριμένα το PHP SOS;

- Ελέγχουμε τον τρόπο λειτουργίας, το MPM και το επίπεδο των πακέτων και αξιολογούμε αν ο διακομιστής σας έχει πράγματι patch.
- Μέσω της [υπηρεσίας PHP-Patch](https://phpsos.de/el/leistungen/php-patch-service/) εφαρμόζουμε την ενημέρωση, επανεκκινούμε πλήρως τον Apache και τεκμηριώνουμε την απόδειξη.
- Μέχρι το patch ορίζουμε τα προσωρινά μέτρα με τρόπο που δεν αντικαθίσταται και περιορίζουμε τη μνήμη σε επίπεδο υπηρεσίας.
- Στο πλαίσιο της [σκλήρυνσης διακομιστών](https://phpsos.de/el/leistungen/server-haertung/) σχεδιάζουμε και δοκιμάζουμε τη μετάβαση στο PHP-FPM με ξεχωριστά pools.


## Συχνές ερωτήσεις

**Πώς θα καταλάβω αν ο διακομιστής μου χρησιμοποιεί mod_php;**  
Αν ο Apache έχει φορτώσει μονάδα PHP, εμφανίζεται στη λίστα μονάδων ως php_module ή με αριθμό έκδοσης στο όνομα. Επιπλέον, η έξοδος phpinfo δείχνει στο Server API την καταχώριση Apache 2.0 Handler. Διαγράψτε αμέσως ένα τέτοιο δοκιμαστικό αρχείο.

**Γιατί το mod_php είναι ιδιαίτερα κρίσιμο στο PHP2Shell;**  
Σύμφωνα με την ομάδα της PHP ο κίνδυνος εκεί είναι ο υψηλότερος· επιδείχθηκε exploit προτού καν εκτελεστεί κώδικας της εφαρμογής. Έτσι ούτε μια καλά συντηρημένη εφαρμογή προστατεύει. Μια γρήγορη ενημέρωση έχει γι' αυτό την υψηλότερη προτεραιότητα.

**Αρκεί ένα reload του Apache μετά την ενημέρωση;**  
Ασφαλής είναι η πλήρης επανεκκίνηση της υπηρεσίας, επειδή η PHP βρίσκεται ως μονάδα μέσα στις διεργασίες του Apache. Ελέγξτε στη συνέχεια την ώρα εκκίνησης όλων των διεργασιών του Apache. Δεν επιτρέπεται να παραμείνουν διεργασίες παλαιότερες από την ενημέρωση.

**Είναι δύσκολη η μετάβαση στο PHP-FPM;**  
Συνήθως προγραμματίζεται εύκολα: εγκατάσταση του PHP-FPM, δημιουργία pools, μετάβαση του Apache στο proxy_fcgi και αλλαγή από prefork σε άλλο MPM. Δοκιμάστε το πρώτα σε αντίγραφο του περιβάλλοντος.

## Πηγές

- [php.net: Ανακοινώσεις ασφαλείας](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)