Saugi Apache konfigūracija PHP

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ą.

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.

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

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.

# 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.

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.

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

Į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.

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.

# 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.

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.

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 rėmuose.

Dažni klausimai

Šaltiniai

• Apache: pagrindinės funkcijos (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: saugumo pranešimai