Apache PHP jaoks turvaliselt seadistamine

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.

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.

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

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.

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

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.

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

Üleslaadimis- ja vahemälukaustad vajavad lisaks käivitamisblokeeringut. Kuidas leida ja blokeerida kõik kirjutatavad kaustad, on kirjas artiklis PHP käivitamise keelamine üleslaadimiskaustades.

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.

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

Täiendava kihina rakenduse ees võib olla mõistlik oma Web Application Firewall; sissejuhatust pakub ModSecurity ja OWASP Core Rule Set'i kasutamine.

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

Korduma kippuvad küsimused

Allikad

• Apache: põhifunktsioonid (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: turvateated