# Saugi Apache konfigūracija PHP

> Saugi Apache PHP konfigūracija: PHP-FPM per mod_proxy_fcgi, AllowOverride None, ServerTokens, TraceEnable ir LimitRequestBody teisingas nustatymas ir patikra.

Šaltinis: https://phpsos.de/lt/blog/apache-fuer-php-absichern/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** norėdami saugiai sukonfigūruoti Apache PHP, prijunkite PHP per PHP-FPM ir `mod_proxy_fcgi`, išjunkite `.htaccess` su `AllowOverride None` ir nustatykite `ServerTokens Prod`, `ServerSignature Off`, `TraceEnable Off` ir `Options -Indexes`. `LimitRequestBody` pritaikykite prie PHP ribų, nereikalingus modulius išjunkite. Konfigūracija nepakeičia PHP atnaujinimo, bet gerokai sumažina atakos paviršių.

## Apache po PHP2Shell: daugiau nei paleidimas iš naujo

2026 m. spalį Apache operatoriai buvo ypatingo spaudimo. PHP komanda mod_php riziką vertina didžiausia, nes ten išnaudojimas buvo parodytas dar prieš pradedant vykdyti programos kodą. Skubius žingsnius, taigi pataisymą ir visišką paleidimą iš naujo, aprašo puslapis [Kodėl mod_php kelia didžiausią riziką](https://phpsos.de/lt/php2shell/mod-php-risiko/).

Po pataisos lieka klausimas, kokia gera yra pati Apache konfigūracija. Išaugę serveriai dažnai nešioja daugelio metų nustatymus: katalogų sąrašus, atviras `.htaccess` teises, modulius, kurių niekas nebenaudoja. Kiekvienas jų gali padaryti vėlesnę klaidą didesnę, nei turėtų būti.

Šis straipsnis aprašo liesą, saugią bazinę Apache 2.4 konfigūraciją su PHP-FPM. Pavyzdžiuose naudojami Debian ir Ubuntu keliai; RHEL šeimoje failai yra `/etc/httpd/`.

## PHP prijungimas per PHP-FPM vietoj mod_php

Su PHP-FPM PHP veikia savo procesuose, atskirai nuo žiniatinklio serverio. Apache užklausas perduoda per `mod_proxy_fcgi`. Pasak Apache dokumentacijos, prijungimas per `SetHandler` turi pranašumą prieš `ProxyPassMatch`: Apache pirmiausia pats priskiria užklausą failui failų sistemoje ir tik tada perduoda PHP-FPM.

```apache
<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
</FilesMatch>
```

Modulius Debian ir Ubuntu aktyvuojate su `a2enmod proxy_fcgi`. Kas pereina nuo mod_php, išjungia PHP modulį ir po to iš Prefork pereina prie Event MPM. Senojo veikimo režimo kontekstą paaiškina [mod_php paaiškinimas: PHP Apache procese](https://phpsos.de/lt/php/mod-php-erklaert/).

PHP-FPM pusėje `security.limit_extensions = .php` priklauso kiekvienam baseinui. Pasak PHP vadovo, kitaip FPM vykdo ir `.phar` failus.

## Saugi Apache PHP konfigūracija: pagrindinės parinktys

Kai kurie nustatymai galioja visam serveriui ir priklauso atskiram konfigūracijos failui, pavyzdžiui, `/etc/apache2/conf-available/haertung.conf`, aktyvuojamam su `a2enconf haertung`.

```apache
# Sutrumpinti versijos duomenis (galima tik visame serveryje)
ServerTokens Prod
ServerSignature Off

# Išjungti TRACE metodą
TraceEnable Off

# Iš principo nieko neleisti, svetainėms leisti tikslingai
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>
```

Toliau pateikta lentelė suskirsto svarbiausias parinktis. Numatytosios reikšmės ir poveikis paimti iš Apache dokumentacijos.

| Direktyva | Numatytoji | Rekomendacija | Kodėl |
|---|---|---|---|
| `ServerTokens` | `Full` | `Prod` | `Server` antraštė nurodo tik „Apache“ |
| `ServerSignature` | `Off` | `Off` | jokios versijos eilutės po klaidų puslapiais |
| `TraceEnable` | `on` | `Off` | TRACE atmetamas su 405 |
| `Options` | `FollowSymlinks` | `-Indexes`, simbolinės nuorodos tik pagal savininką | jokių katalogų sąrašų |
| `AllowOverride` | `None` | `None` | `.htaccess` nevertinamas |
| `LimitRequestBody` | 1 GiB (nuo 2.4.54) | pagal `post_max_size` | dideles užklausas atmesti anksti |

Svarbu dėl `AllowOverride`: daugelis distribucijų ir CMS instrukcijų žiniatinklio šakniniam katalogui nustato `AllowOverride All`. Tada kiekvienas `.htaccess` failas gali keisti perrašymo (rewrite) taisykles, tvarkykles (handler) ir su mod_php net PHP nustatymus. Užpuolikas su rašymo teisėmis įkėlimų aplanke gali ten padėti savo `.htaccess`. Su `AllowOverride None` šis kelias užkirstas.

## VirtualHost kaip šablonas

Toliau pateiktas VirtualHost sujungia punktus vienai svetainei. Sertifikatų kelius, lizdą ir katalogus pritaikykite. `mod_ssl` ir `mod_headers` turi būti aktyvūs.

```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>

    # Užblokuoti versijų valdymą ir aplinkos failus
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, atitinka post_max_size = 32M
    LimitRequestBody 33554432

    Header unset X-Powered-By
    Header always unset X-Powered-By
</VirtualHost>
```

Dvigubas `Header unset` nėra apsirikimas. Pasak Apache dokumentacijos, antraštės iš `mod_proxy_fcgi` patenka į kitą vidinę lentelę nei paties serverio antraštės; abiem variantais pagaunate abu atvejus. Kitas antraštes, kurios aktyviai saugo lankytojus, aprašo gidas [Saugumo antraštės svetainėms](https://phpsos.de/lt/ratgeber/sicherheits-header/).

Įkėlimų ir talpyklų aplankams papildomai reikia vykdymo draudimo. Kaip rasti ir užblokuoti visus įrašomus aplankus, aprašyta skyriuje [PHP vykdymo įkėlimų aplankuose draudimas](https://phpsos.de/lt/blog/php-in-uploads-verbieten/).

## Modulių išretinimas ir rezultato patikra

Kiekvienas įkeltas modulis yra kodas, reaguojantis į užklausas. Patikrinkite, kurie moduliai aktyvūs, ir išjunkite tai, ko nereikia. Tipiniai kandidatai yra `autoindex`, `status` be prieigos apribojimo, `cgi` ir `userdir`.

```bash
# Parodyti aktyvius modulius
apachectl -M | sort
# Pavyzdys Debian/Ubuntu: išjungti katalogų sąrašo modulį
sudo a2dismod autoindex
# Patikrinti konfigūraciją ir tik tada iš naujo įkelti
sudo apachectl configtest && sudo systemctl reload apache2
# Patikra iš išorės: TRACE turi grąžinti 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
```

Ypatingo dėmesio nusipelno `mod_status`. Būsenos puslapis rodo veikiančias užklausas su adresais ir iškviestais keliais. Jei jis reikalingas, prieigą apribokite su `Require ip` iki savo valdymo tinklų. Tas pats galioja PHP-FPM būsenos puslapiams, padarytiems pasiekiamiems per Apache.

> **Svarbu:**
> `AllowOverride` nekeiskite be pasirengimo. Pirmiausia perkelkite taisykles iš visų `.htaccess` failų į VirtualHost ir išbandykite svetainę kopijoje. Kitaip po įkėlimo iš naujo nebeveiks nukreipimai ir gražūs URL.

Kaip papildomas sluoksnis prieš programą gali būti prasminga atskira žiniatinklio programų ugniasienė (Web Application Firewall); įvadą aprašo [ModSecurity ir OWASP Core Rule Set naudojimas](https://phpsos.de/lt/blog/modsecurity-owasp-crs/).

## Išvada: tvarka nugali pavienę priemonę

Saugi Apache konfigūracija PHP sudaryta iš kelių gerai suprantamų dalių. PHP veikia per PHP-FPM atskirai nuo žiniatinklio serverio, `.htaccess` nevertinamas, versijų duomenys ir TRACE išjungti, dydžio ribos atitinka PHP, o įrašomi aplankai nevykdo scenarijų. Nė vienas iš šių punktų pats savaime nėra įspūdingas. Kartu jie užtikrina, kad klaida vienoje vietoje iš karto nesukeltų serverio perėmimo.

Vadovybei ir projektų vadovams antra savybė beveik svarbesnė: sutvarkyta konfigūracija yra aiški. Kai visos taisyklės yra VirtualHost, o ne išsibarsčiusios po dešimtis `.htaccess` failų, kitos kritinės spragos atveju galima greitai patikrinti, kuri svetainė kaip prijungta. Tokioje padėtyje kaip 2026 m. spalį tai sutaupo būtent tą laiką, kuris svarbiausias.

Vis dėlto perėjimą planuokite ramiai ir su testine aplinka. Skubotas perėjimas nuo mod_php prie PHP-FPM prieš pat savaitgalį labiau sukuria naujų problemų, nei išsprendžia.

## Kaip PHP SOS padeda konkrečiai?

- **Patikrinti esamą būklę:** nuskaitome visą Apache konfigūraciją, visus aktyvius modulius ir visus `.htaccess` failus.
- **Suplanuoti perėjimą:** kur dar veikia mod_php, ruošiame perėjimą prie PHP-FPM su atskirais baseinais kiekvienai svetainei.
- **Sutvirtinti konfigūraciją:** nustatome pagrindines parinktis, `.htaccess` taisykles perkeliame į VirtualHost ir užblokuojame įrašomus aplankus.
- **Išbandyti ir dokumentuoti:** po kiekvieno pakeitimo patikriname svetaines iš išorės ir būklę užfiksuojame [serverio sutvirtinimo](https://phpsos.de/lt/leistungen/server-haertung/) rėmuose.


## Dažni klausimai

**Ar vis dar turėčiau naudoti mod_php?**  
Naujoms įdiegtims rekomenduojame PHP-FPM per mod_proxy_fcgi. PHP komanda mod_php atveju PHP2Shell keliamą riziką vertina didžiausia. Su PHP-FPM PHP veikia atskirai nuo žiniatinklio serverio, su atskirais naudotojais kiekvienai svetainei ir savomis ribomis.

**Kodėl AllowOverride None, jei mano CMS reikia .htaccess?**  
Kiekvienas, kuris gali rašyti žiniatinklio šakniniame kataloge, taip pat ir įterptas kodas, gali sukurti .htaccess. Su AllowOverride None Apache tokių failų nevertina. Savo CMS taisykles tada vieną kartą perkeliate į VirtualHost. Tai šiek tiek darbo, bet konfigūraciją padaro aiškią ir greitesnę.

**Ar ServerTokens galiu nustatyti skirtingai kiekvienai svetainei?**  
Ne. Pasak Apache dokumentacijos, ServerTokens galioja visam serveriui ir jo negalima keisti kiekvienam VirtualHost. Jis kartu valdo versijos nurodymą po klaidų puslapiais, kurį parodo ServerSignature.

**Kokia numatytoji LimitRequestBody reikšmė?**  
Nuo Apache 2.4.54 numatytoji yra 1 GiB, 2.4.53 ir senesnėje versijoje ji buvo neribota. Reikšmę nustatykite pagal savo PHP konfigūracijos post_max_size, kad per didelės užklausos būtų atmetamos jau žiniatinklio serveryje.

## Šaltiniai

- [Apache: pagrindinės funkcijos (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: saugumo pranešimai](https://www.php.net/)
