# Apache PHP jaoks turvaliselt seadistamine

> Apache PHP turvaline seadistus: PHP-FPM mod_proxy_fcgi kaudu, AllowOverride None, ServerTokens, TraceEnable ja LimitRequestBody õigesti seada ja kontrollida.

Allikas: https://phpsos.de/et/blog/apache-fuer-php-absichern/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** Apache'i turvaliseks seadistamiseks PHP jaoks ühendate PHP PHP-FPM-i ja `mod_proxy_fcgi` kaudu, lülitate `.htaccess`-i sättega `AllowOverride None` välja ning seate `ServerTokens Prod`, `ServerSignature Off`, `TraceEnable Off` ja `Options -Indexes`. `LimitRequestBody` kohandate PHP piiridele, mittevajalikud moodulid lülitate välja. Konfiguratsioon ei asenda PHP uuendust, kuid vähendab ründepinda märgatavalt.

## Apache pärast PHP2Shelli: rohkem kui taaskäivitus

Apache'i haldajad olid 2026. aasta oktoobris erilise surve all. PHP meeskond hindab mod_php riski kõige suuremaks, sest seal näidati ekspluateerimist enne, kui rakenduse kood üldse käivitub. Akuutsed sammud, see tähendab paikamine ja täielik taaskäivitus, kirjeldab leht [Miks mod_php kannab suurimat riski](https://phpsos.de/et/php2shell/mod-php-risiko/).

Pärast paika jääb küsimus, kui hea on Apache'i konfiguratsioon ise. Kasvanud serverid kannavad sageli sätteid paljudest aastatest: katalooginimekirjad, avatud `.htaccess`-õigused, moodulid, mida keegi enam ei vaja. Iga neist võib hilisema vea teha suuremaks, kui see peaks olema.

See artikkel kirjeldab Apache 2.4 jaoks kerget, turvalist põhikonfiguratsiooni PHP-FPM-iga. Näited kasutavad Debiani ja Ubuntu teid; RHEL-i perekonnas asuvad failid kaustas `/etc/httpd/`.

## PHP ühendamine PHP-FPM-i kaudu mod_php asemel

PHP-FPM-iga töötab PHP oma protsessides, veebiserverist eraldi. Apache annab päringud edasi `mod_proxy_fcgi` kaudu. Apache'i dokumentatsiooni järgi on `SetHandler`-iga ühendamisel eelis `ProxyPassMatch`-i ees: Apache seostab päringu esmalt ise failisüsteemis oleva failiga ja annab alles seejärel PHP-FPM-ile edasi.

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

Mooduleid aktiveerite Debianis ja Ubuntus käsuga `a2enmod proxy_fcgi`. Kes mod_php-lt üle läheb, deaktiveerib PHP mooduli ja vahetab seejärel Prefork-MPM-i Event-MPM-i vastu. Vana töörežiimi tausta selgitab [mod_php selgitus: PHP Apache'i protsessis](https://phpsos.de/et/php/mod-php-erklaert/).

PHP-FPM-i poolel kuulub igasse pooli `security.limit_extensions = .php`. PHP käsiraamatu järgi käivitab FPM muidu ka `.phar`-faile.

## Apache PHP turvaline seadistus: põhisuvandid

Mõned sätted kehtivad kogu serverile ja kuuluvad oma konfiguratsioonifaili, näiteks `/etc/apache2/conf-available/haertung.conf`, aktiveeritud käsuga `a2enconf haertung`.

```apache
# Lühendage versiooniandmeid (võimalik ainult serveriülesena)
ServerTokens Prod
ServerSignature Off

# Lülitage TRACE-meetod välja
TraceEnable Off

# Põhimõtteliselt ei vabastata midagi, veebisaidid lubavad sihipäraselt
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>
```

Järgmine tabel paigutab olulisemad suvandid. Vaikeväärtused ja mõju pärinevad Apache'i dokumentatsioonist.

| Direktiiv | Vaikeväärtus | Soovitus | Miks |
|---|---|---|---|
| `ServerTokens` | `Full` | `Prod` | `Server`-päis nimetab ainult „Apache“ |
| `ServerSignature` | `Off` | `Off` | versioonirida vealehtede all puudub |
| `TraceEnable` | `on` | `Off` | TRACE lükatakse tagasi koodiga 405 |
| `Options` | `FollowSymlinks` | `-Indexes`, sümbolilingid ainult omaniku järgi | katalooginimekirju ei ole |
| `AllowOverride` | `None` | `None` | `.htaccess`-i ei hinnata |
| `LimitRequestBody` | 1 GiB (alates 2.4.54) | vastavalt `post_max_size`-ile | suured päringud varakult tagasi lükata |

Oluline `AllowOverride` puhul: paljud distributsioonid ja CMS-juhendid seavad veebijuurkataloogile `AllowOverride All`. Siis võib iga `.htaccess`-fail muuta Rewrite-reegleid, käitlejaid ja mod_php puhul isegi PHP sätteid. Ründaja, kellel on kirjutusõigused üleslaadimiskaustas, saab sinna paigutada oma `.htaccess`-i. Sättega `AllowOverride None` on see tee suletud.

## VirtualHost mallina

Järgmine VirtualHost ühendab punktid ühe veebisaidi jaoks. Sertifikaatide teed, sokli ja kataloogid kohandate ise. `mod_ssl` ja `mod_headers` peavad olema aktiivsed.

```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>

    # Blokeerige versioonihaldus ja keskkonnafailid
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, vastavalt post_max_size = 32M
    LimitRequestBody 33554432

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

Kahekordne `Header unset` ei ole eksitus. Apache'i dokumentatsiooni järgi satuvad `mod_proxy_fcgi` päised teise sisemisse tabelisse kui serveri enda päised; mõlema variandiga saate kätte mõlemad juhtumid. Muud päised, mis külastajaid aktiivselt kaitsevad, kirjeldab juhend [Veebisaitide turvapäised](https://phpsos.de/et/ratgeber/sicherheits-header/).

Üleslaadimis- ja vahemälukaustad vajavad lisaks käivitamisblokeeringut. Kuidas leida ja blokeerida kõik kirjutatavad kaustad, on kirjas artiklis [PHP käivitamise keelamine üleslaadimiskaustades](https://phpsos.de/et/blog/php-in-uploads-verbieten/).

## Moodulite väljakoristamine ja tulemuse kontroll

Iga laaditud moodul on kood, mis päringutele reageerib. Kontrollige, millised moodulid on aktiivsed, ja lülitage välja, mida te ei vaja. Tüüpilised kandidaadid on `autoindex`, `status` ilma ligipääsupiiranguta, `cgi` ja `userdir`.

```bash
# Kuvage aktiivsed moodulid
apachectl -M | sort
# Näide Debian/Ubuntu: lülitage katalooginimekirja moodul välja
sudo a2dismod autoindex
# Kontrollige konfiguratsiooni ja laadige alles siis uuesti
sudo apachectl configtest && sudo systemctl reload apache2
# Test väljastpoolt: TRACE peab andma 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
```

Erilist tähelepanu väärib `mod_status`. Olekuleht näitab töötavaid päringuid aadresside ja avatud teedega. Kui seda vajatakse, piirake ligipääs käsuga `Require ip` oma haldusvõrkudega. Sama kehtib PHP-FPM-i olekulehtede kohta, mis on Apache'i kaudu kättesaadavaks tehtud.

> **Oluline:**
> Ärge lülitage `AllowOverride`-i ümber ettevalmistuseta. Võtke esmalt kõigi `.htaccess`-failide reeglid üle VirtualHosti ja testige veebisaiti koopial. Muidu ei tööta ümbersuunamised ja ilusad URL-id pärast uuesti laadimist enam.

Täiendava kihina rakenduse ees võib olla mõistlik oma Web Application Firewall; sissejuhatust pakub [ModSecurity ja OWASP Core Rule Set'i kasutamine](https://phpsos.de/et/blog/modsecurity-owasp-crs/).

## Kokkuvõte: kord lööb üksikmeetme

Turvaline Apache'i konfiguratsioon PHP jaoks koosneb mõnest hästi mõistetud ehituskivist. PHP töötab PHP-FPM-i kaudu veebiserverist eraldi, `.htaccess`-i ei hinnata, versiooniandmed ja TRACE on välja lülitatud, suuruspiirid sobivad PHP-ga ja kirjutatavad kaustad skripte ei käivita. Ükski neist punktidest pole iseenesest põnev. Koos tagavad need, et viga ühes kohas ei vii kohe serveri ülevõtmiseni.

Juhtkonna ja projektijuhtide jaoks on peaaegu olulisem teine omadus: korrastatud konfiguratsioon on arusaadav. Kui kõik reeglid asuvad VirtualHostis, mitte ei ole laiali kümnetes `.htaccess`-failides, saab järgmise kriitilise augu korral kiiresti kontrollida, milline veebisait on kuidas ühendatud. 2026. aasta oktoobri-sarnases olukorras säästab see just seda aega, millest sõltub.

Planeerige ümberlülitus sellegipoolest rahulikult ja testkeskkonnaga. Kiirustades tehtud üleminek mod_php-lt PHP-FPM-ile vahetult enne nädalavahetust tekitab pigem uusi probleeme, kui lahendab.

## Kuidas PHP SOS konkreetselt aitab?

- **Seisu kontrollida:** loeme välja kogu Apache'i konfiguratsiooni, kõik aktiivsed moodulid ja kõik `.htaccess`-failid.
- **Üleminekut planeerida:** kus mod_php veel töötab, valmistame ette üleminekut PHP-FPM-ile oma poolidega veebisaitide kaupa.
- **Konfiguratsiooni karastada:** seame põhisuvandid, võtame `.htaccess`-reeglid üle VirtualHostidesse ja blokeerime kirjutatavad kaustad.
- **Testida ja dokumenteerida:** kontrollime pärast iga muudatust veebisaite väljastpoolt ja fikseerime seisu [serveri karastamise](https://phpsos.de/et/leistungen/server-haertung/) raames.


## Korduma kippuvad küsimused

**Kas peaksin mod_php-d veel kasutama?**  
Uute paigalduste jaoks soovitame PHP-FPM-i mod_proxy_fcgi kaudu. PHP meeskond hindab PHP2Shelli riski mod_php puhul kõige suuremaks. PHP-FPM-iga töötab PHP veebiserverist eraldi, veebisaitide kaupa oma kasutajate ja oma piiridega.

**Miks AllowOverride None, kui minu CMS vajab .htaccess'i?**  
Faili .htaccess saab luua igaüks, kes tohib veebijuurkataloogis kirjutada, ka sissetoodud kood. Sättega AllowOverride None ei hinda Apache selliseid faile. Oma CMS-i reeglid võtate siis ühekordselt üle VirtualHosti. See on veidi vaeva, kuid teeb konfiguratsiooni arusaadavaks ja kiiremaks.

**Kas saan ServerTokens'it veebisaitide kaupa erinevalt seada?**  
Ei. Apache'i dokumentatsiooni järgi kehtib ServerTokens kogu serverile ja seda ei saa VirtualHosti kaupa muuta. See juhib samas ka vealehtede all olevat versiooniandmet, mille ServerSignature sisse lülitab.

**Milline on LimitRequestBody vaikeväärtus?**  
Alates Apache 2.4.54-st on vaikeväärtus 1 GiB, versioonis 2.4.53 ja vanemates oli see piiramatu. Seadke väärtus oma PHP konfiguratsiooni post_max_size järgi, et liiga suured päringud lükataks tagasi juba veebiserveris.

## Allikad

- [Apache: põhifunktsioonid (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: turvateated](https://www.php.net/)