# Ασφαλής διαμόρφωση του Apache για PHP

> Ασφαλής διαμόρφωση Apache για PHP: PHP-FPM μέσω mod_proxy_fcgi, AllowOverride None, ServerTokens, TraceEnable και LimitRequestBody σωστά ορισμένα και ελεγμένα.

Πηγή: https://phpsos.de/el/blog/apache-fuer-php-absichern/  
Ημερομηνία: 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 με ασφάλεια για PHP, συνδέετε την PHP μέσω PHP-FPM και `mod_proxy_fcgi`, απενεργοποιείτε το `.htaccess` με `AllowOverride None` και ορίζετε `ServerTokens Prod`, `ServerSignature Off`, `TraceEnable Off` και `Options -Indexes`. Το `LimitRequestBody` το προσαρμόζετε στα όρια της PHP, τις μονάδες που δεν χρειάζονται τις απενεργοποιείτε. Η διαμόρφωση δεν αντικαθιστά την ενημέρωση της PHP, μικραίνει όμως σημαντικά την επιφάνεια επίθεσης.

## Ο Apache μετά το PHP2Shell: περισσότερα από μια επανεκκίνηση

Οι φορείς λειτουργίας Apache βρέθηκαν τον Οκτώβριο 2026 υπό ιδιαίτερη πίεση. Η ομάδα της PHP κατατάσσει τον κίνδυνο στο mod_php ως τον υψηλότερο, επειδή εκεί έχει επιδειχθεί exploit προτού καν εκτελεστεί κώδικας της εφαρμογής. Τα επείγοντα βήματα, δηλαδή patch και πλήρη επανεκκίνηση, περιγράφει η σελίδα [Γιατί το mod_php φέρει τον υψηλότερο κίνδυνο](https://phpsos.de/el/php2shell/mod-php-risiko/).

Μετά το patch μένει το ερώτημα πόσο καλή είναι η ίδια η διαμόρφωση του Apache. Οι διακομιστές που έχουν αναπτυχθεί με τον καιρό φέρουν συχνά ρυθμίσεις πολλών ετών: λίστες φακέλων, ανοιχτά δικαιώματα `.htaccess`, μονάδες που κανείς δεν χρειάζεται πια. Καθεμία από αυτές μπορεί να κάνει ένα μεταγενέστερο σφάλμα μεγαλύτερο από όσο θα έπρεπε.

Αυτό το άρθρο περιγράφει μια λιτή, ασφαλή βασική διαμόρφωση για Apache 2.4 με PHP-FPM. Τα παραδείγματα χρησιμοποιούν διαδρομές Debian και Ubuntu· στην οικογένεια RHEL τα αρχεία βρίσκονται στο `/etc/httpd/`.

## Σύνδεση της PHP μέσω PHP-FPM αντί για mod_php

Με το PHP-FPM η PHP εκτελείται σε δικές της διεργασίες, χωριστά από τον διακομιστή ιστού. Ο Apache προωθεί τα αιτήματα μέσω `mod_proxy_fcgi`. Σύμφωνα με την τεκμηρίωση του Apache, η σύνδεση μέσω `SetHandler` έχει ένα πλεονέκτημα έναντι του `ProxyPassMatch`: ο Apache αντιστοιχίζει πρώτα ο ίδιος το αίτημα σε ένα αρχείο του συστήματος αρχείων και μόνο τότε το προωθεί στο PHP-FPM.

```apache
<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
</FilesMatch>
```

Τις μονάδες τις ενεργοποιείτε σε Debian και Ubuntu με `a2enmod proxy_fcgi`. Όποιος μεταβαίνει από το mod_php, απενεργοποιεί τη μονάδα PHP και αλλάζει στη συνέχεια από το MPM Prefork στο MPM Event. Το υπόβαθρο του παλιού τρόπου λειτουργίας εξηγεί το [mod_php εξηγημένο: η PHP μέσα στη διεργασία του Apache](https://phpsos.de/el/php/mod-php-erklaert/).

Στην πλευρά του PHP-FPM, το `security.limit_extensions = .php` ανήκει σε κάθε pool. Σύμφωνα με το εγχειρίδιο της PHP, το FPM εκτελεί αλλιώς και αρχεία `.phar`.

## Ασφαλής διαμόρφωση Apache για PHP: οι βασικές επιλογές

Ορισμένες ρυθμίσεις ισχύουν για ολόκληρο τον διακομιστή και ανήκουν σε ξεχωριστό αρχείο διαμόρφωσης, π.χ. `/etc/apache2/conf-available/haertung.conf`, που ενεργοποιείται με `a2enconf haertung`.

```apache
# Συντόμευση των ενδείξεων έκδοσης (δυνατό μόνο σε επίπεδο διακομιστή)
ServerTokens Prod
ServerSignature Off

# Απενεργοποίηση της μεθόδου TRACE
TraceEnable Off

# Καταρχήν δεν ελευθερώνεται τίποτα, οι ιστότοποι επιτρέπονται στοχευμένα
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>
```

Ο παρακάτω πίνακας κατατάσσει τις σημαντικότερες επιλογές. Οι προεπιλογές και η δράση προέρχονται από την τεκμηρίωση του Apache.

| Οδηγία | Προεπιλογή | Σύσταση | Γιατί |
|---|---|---|---|
| `ServerTokens` | `Full` | `Prod` | η κεφαλίδα `Server` αναφέρει μόνο «Apache» |
| `ServerSignature` | `Off` | `Off` | καμία γραμμή έκδοσης κάτω από τις σελίδες σφαλμάτων |
| `TraceEnable` | `on` | `Off` | το TRACE απορρίπτεται με 405 |
| `Options` | `FollowSymlinks` | `-Indexes`, symlinks μόνο κατά ιδιοκτήτη | καμία λίστα φακέλων |
| `AllowOverride` | `None` | `None` | το `.htaccess` δεν αξιολογείται |
| `LimitRequestBody` | 1 GiB (από 2.4.54) | ανάλογα με το `post_max_size` | έγκαιρη απόρριψη μεγάλων αιτημάτων |

Σημαντικό στο `AllowOverride`: πολλές διανομές και οδηγίες CMS ορίζουν για το webroot `AllowOverride All`. Έτσι κάθε αρχείο `.htaccess` μπορεί να αλλάξει κανόνες rewrite, handlers και, με mod_php, ακόμη και ρυθμίσεις PHP. Ένας επιτιθέμενος με δικαιώματα εγγραφής σε φάκελο upload μπορεί να αποθέσει εκεί δικό του `.htaccess`. Με `AllowOverride None` αυτός ο δρόμος κλείνει.

## Ένα VirtualHost ως πρότυπο

Το παρακάτω VirtualHost συνδυάζει τα σημεία για έναν μεμονωμένο ιστότοπο. Προσαρμόστε διαδρομές πιστοποιητικών, socket και φακέλους. Οι `mod_ssl` και `mod_headers` πρέπει να είναι ενεργές.

```apache
<VirtualHost *:443>
    ServerName www.example.de
    DocumentRoot /var/www/seite1/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/seite1/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/seite1/privkey.pem

    <Directory /var/www/seite1/public>
        Options -Indexes +SymLinksIfOwnerMatch
        AllowOverride None
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
    </FilesMatch>

    # Αποκλεισμός διαχείρισης εκδόσεων και αρχείων περιβάλλοντος
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, ανάλογα με post_max_size = 32M
    LimitRequestBody 33554432

    Header unset X-Powered-By
    Header always unset X-Powered-By
</VirtualHost>
```

Το διπλό `Header unset` δεν είναι παράλειψη. Σύμφωνα με την τεκμηρίωση του Apache, οι κεφαλίδες από το `mod_proxy_fcgi` καταλήγουν σε άλλον εσωτερικό πίνακα από τις κεφαλίδες του ίδιου του διακομιστή· με τις δύο παραλλαγές πιάνετε και τις δύο περιπτώσεις. Περαιτέρω κεφαλίδες που προστατεύουν ενεργά τους επισκέπτες περιγράφει ο οδηγός [Κεφαλίδες ασφαλείας για ιστότοπους](https://phpsos.de/el/ratgeber/sicherheits-header/).

Οι φάκελοι upload και cache χρειάζονται επιπλέον αποκλεισμό εκτέλεσης. Πώς βρίσκετε και αποκλείετε όλους τους εγγράψιμους φακέλους, αναφέρεται στο [Απαγόρευση εκτέλεσης PHP σε φακέλους upload](https://phpsos.de/el/blog/php-in-uploads-verbieten/).

## Εκκαθάριση μονάδων και έλεγχος του αποτελέσματος

Κάθε φορτωμένη μονάδα είναι κώδικας που αντιδρά σε αιτήματα. Ελέγξτε ποιες μονάδες είναι ενεργές και απενεργοποιήστε όσες δεν χρειάζεστε. Τυπικοί υποψήφιοι είναι τα `autoindex`, `status` χωρίς περιορισμό πρόσβασης, `cgi` και `userdir`.

```bash
# Εμφάνιση ενεργών μονάδων
apachectl -M | sort
# Παράδειγμα Debian/Ubuntu: απενεργοποίηση της μονάδας λίστας φακέλων
sudo a2dismod autoindex
# Έλεγχος της διαμόρφωσης και μόνο μετά επαναφόρτωση
sudo apachectl configtest && sudo systemctl reload apache2
# Δοκιμή απ' έξω: το TRACE πρέπει να επιστρέφει 405, το .git 403
curl -s -o /dev/null -w "%{http_code}\n" -X TRACE https://www.example.de/
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD
```

Ιδιαίτερη προσοχή αξίζει το `mod_status`. Η σελίδα κατάστασης δείχνει αιτήματα που εκτελούνται, με διευθύνσεις και διαδρομές που κλήθηκαν. Αν χρειάζεται, περιορίστε την πρόσβαση με `Require ip` στα δίκτυα διαχείρισής σας. Το ίδιο ισχύει για σελίδες κατάστασης του PHP-FPM που έγιναν προσβάσιμες μέσω Apache.

> **Σημαντικό:**
> Μην αλλάζετε το `AllowOverride` χωρίς προετοιμασία. Μεταφέρετε πρώτα τους κανόνες από όλα τα αρχεία `.htaccess` στο VirtualHost και δοκιμάστε τον ιστότοπο σε αντίγραφο. Αλλιώς οι ανακατευθύνσεις και τα φιλικά URL δεν θα λειτουργούν μετά την επαναφόρτωση.

Ως πρόσθετο στρώμα μπροστά από την εφαρμογή μπορεί να έχει νόημα ένα δικό σας Web Application Firewall· την εισαγωγή περιγράφει το [Χρήση του ModSecurity και του OWASP Core Rule Set](https://phpsos.de/el/blog/modsecurity-owasp-crs/).

## Συμπέρασμα: η τάξη υπερτερεί του μεμονωμένου μέτρου

Μια ασφαλής διαμόρφωση Apache για PHP αποτελείται από λίγα, καλά κατανοητά δομικά στοιχεία. Η PHP εκτελείται μέσω PHP-FPM χωριστά από τον διακομιστή ιστού, το `.htaccess` δεν αξιολογείται, οι ενδείξεις έκδοσης και το TRACE είναι απενεργοποιημένα, τα όρια μεγέθους ταιριάζουν με την PHP και οι εγγράψιμοι φάκελοι δεν εκτελούν σενάρια. Κανένα από αυτά δεν είναι από μόνο του εντυπωσιακό. Μαζί φροντίζουν ώστε ένα σφάλμα σε ένα σημείο να μην οδηγεί αμέσως στην κατάληψη του διακομιστή.

Για τη διοίκηση και τους υπεύθυνους έργων μια δεύτερη ιδιότητα είναι σχεδόν σημαντικότερη: μια τακτοποιημένη διαμόρφωση είναι κατανοητή. Όταν όλοι οι κανόνες βρίσκονται στο VirtualHost αντί να είναι διάσπαρτοι σε δεκάδες αρχεία `.htaccess`, μπορεί κανείς στην επόμενη κρίσιμη ευπάθεια να ελέγξει γρήγορα ποιος ιστότοπος είναι συνδεδεμένος με ποιον τρόπο. Σε μια κατάσταση όπως του Οκτωβρίου 2026 αυτό εξοικονομεί ακριβώς τον χρόνο που μετράει.

Σχεδιάστε παρ' όλα αυτά τη μετάβαση με ηρεμία και με περιβάλλον δοκιμών. Μια βιαστική αλλαγή από mod_php σε PHP-FPM λίγο πριν από ένα Σαββατοκύριακο δημιουργεί μάλλον νέα προβλήματα από όσα λύνει.

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

- **Έλεγχος της υπάρχουσας κατάστασης:** Διαβάζουμε ολόκληρη τη διαμόρφωση του Apache, όλες τις ενεργές μονάδες και όλα τα αρχεία `.htaccess`.
- **Σχεδιασμός της μετάβασης:** Όπου εκτελείται ακόμη mod_php, προετοιμάζουμε τη μετάβαση σε PHP-FPM με δικά του pools ανά ιστότοπο.
- **Σκλήρυνση της διαμόρφωσης:** Ορίζουμε βασικές επιλογές, μεταφέρουμε κανόνες `.htaccess` στα VirtualHosts και αποκλείουμε εγγράψιμους φακέλους.
- **Δοκιμή και τεκμηρίωση:** Μετά από κάθε αλλαγή ελέγχουμε τους ιστοτόπους απ' έξω και καταγράφουμε την κατάσταση στο πλαίσιο της [σκλήρυνσης διακομιστή](https://phpsos.de/el/leistungen/server-haertung/).


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

**Πρέπει να χρησιμοποιώ ακόμη το mod_php;**  
Για νέες εγκαταστάσεις συνιστούμε PHP-FPM μέσω mod_proxy_fcgi. Η ομάδα της PHP κατατάσσει τον κίνδυνο από το PHP2Shell στο mod_php ως τον υψηλότερο. Με το PHP-FPM η PHP εκτελείται χωριστά από τον διακομιστή ιστού, με ξεχωριστούς χρήστες ανά ιστότοπο και δικά της όρια.

**Γιατί AllowOverride None, ενώ το CMS μου χρειάζεται .htaccess;**  
Ένα .htaccess μπορεί να το δημιουργήσει όποιος επιτρέπεται να γράφει στο webroot, ακόμη και κώδικας που έχει εισαχθεί. Με το AllowOverride None ο Apache δεν αξιολογεί τέτοια αρχεία. Τους κανόνες του CMS σας τους μεταφέρετε τότε μία φορά στο VirtualHost. Αυτό απαιτεί κάποια προσπάθεια, κάνει όμως τη διαμόρφωση κατανοητή και ταχύτερη.

**Μπορώ να ορίσω το ServerTokens διαφορετικά ανά ιστότοπο;**  
Όχι. Σύμφωνα με την τεκμηρίωση του Apache το ServerTokens ισχύει για ολόκληρο τον διακομιστή και δεν αλλάζει ανά VirtualHost. Ελέγχει ταυτόχρονα την ένδειξη έκδοσης κάτω από τις σελίδες σφαλμάτων, που εμφανίζει το ServerSignature.

**Ποια είναι η προεπιλεγμένη τιμή του LimitRequestBody;**  
Από τον Apache 2.4.54 η προεπιλογή είναι 1 GiB, στην έκδοση 2.4.53 και παλαιότερες ήταν απεριόριστη. Ορίστε την τιμή ανάλογα με το post_max_size της διαμόρφωσης PHP, ώστε τα υπερβολικά μεγάλα αιτήματα να απορρίπτονται ήδη στον διακομιστή ιστού.

## Πηγές

- [Apache: βασικές λειτουργίες (core)](https://httpd.apache.org/docs/2.4/mod/core.html)
- [Apache: mod_proxy_fcgi](https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html)
- [Apache: mod_headers](https://httpd.apache.org/docs/2.4/mod/mod_headers.html)
- [php.net: ανακοινώσεις ασφαλείας](https://www.php.net/)