Apache droša konfigurēšana PHP

Īsi sakot: Lai Apache droši konfigurētu PHP, pieslēdziet PHP caur PHP-FPM un mod_proxy_fcgi, izslēdziet .htaccess ar AllowOverride None un iestatiet ServerTokens Prod, ServerSignature Off, TraceEnable Off un Options -Indexes. LimitRequestBody pielāgojiet PHP robežām, nevajadzīgos moduļus izslēdziet. Konfigurācija neaizstāj PHP atjauninājumu, bet ievērojami samazina uzbrukuma virsmu.

Apache pēc PHP2Shell: vairāk nekā pārstartēšana

Apache uzturētāji 2026. gada oktobrī atradās īpašā spiedienā. PHP komanda mod_php risku novērtē kā augstāko, jo tur exploit tika demonstrēts, vēl pirms tiek izpildīts lietojumprogrammas kods. Akūtos soļus, tātad ielāpošanu un pilnu pārstartēšanu, apraksta lapa Kāpēc mod_php nes augstāko risku.

Pēc ielāpa paliek jautājums, cik laba ir pati Apache konfigurācija. Izaugušie serveri bieži nes iestatījumus no daudziem gadiem: direktoriju sarakstus, atvērtas .htaccess tiesības, moduļus, kurus neviens vairs nevajag. Katrs no tiem var vēlāku kļūdu padarīt lielāku, nekā tai vajadzētu būt.

Šis raksts apraksta vieglu, drošu pamata konfigurāciju Apache 2.4 ar PHP-FPM. Piemēros izmantoti Debian un Ubuntu ceļi; RHEL saimē faili atrodas zem /etc/httpd/.

PHP pieslēgšana caur PHP-FPM mod_php vietā

Ar PHP-FPM PHP darbojas savos procesos, atsevišķi no tīmekļa servera. Apache pieprasījumus nodod tālāk caur mod_proxy_fcgi. Saskaņā ar Apache dokumentāciju pieslēgumam ar SetHandler ir priekšrocība salīdzinājumā ar ProxyPassMatch: Apache vispirms pats piešķir pieprasījumu failam failu sistēmā un tikai tad nodod PHP-FPM.

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

Moduļus Debian un Ubuntu aktivizējat ar a2enmod proxy_fcgi. Kas pāriet no mod_php, tas deaktivizē PHP moduli un pēc tam pāriet no Prefork uz Event MPM. Fona informāciju par veco darbības režīmu izskaidro mod_php skaidrojums: PHP Apache procesā.

PHP-FPM pusē security.limit_extensions = .php pieder katrā pūlā. Saskaņā ar PHP rokasgrāmatu FPM citādi izpilda arī .phar failus.

Apache PHP droša konfigurēšana: kodola opcijas

Daži iestatījumi attiecas uz visu serveri un pieder savā konfigurācijas failā, piemēram, /etc/apache2/conf-available/haertung.conf, aktivizētā ar a2enconf haertung.

# Saīsināt versiju norādes (iespējams tikai visā serverī)
ServerTokens Prod
ServerSignature Off

# Izslēgt TRACE metodi
TraceEnable Off

# Principā neko neatļaut, vietnēm atļaut mērķtiecīgi
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Turpmākā tabula ierindo svarīgākās opcijas. Noklusējuma vērtības un ietekme ņemtas no Apache dokumentācijas.

Svarīgi par AllowOverride: daudzi distributīvi un CMS pamācības tīmekļa saknei iestata AllowOverride All. Tad katrs .htaccess fails var mainīt Rewrite noteikumus, handleri un mod_php gadījumā pat PHP iestatījumus. Uzbrucējs ar rakstīšanas tiesībām augšupielāžu mapē tur var novietot savu .htaccess. Ar AllowOverride None šis ceļš ir slēgts.

VirtualHost kā veidne

Turpmākais VirtualHost savieno punktus vienai vietnei. Sertifikātu ceļus, socket un direktorijas pielāgojiet. mod_ssl un mod_headers jābūt aktīviem.

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

    # Bloķēt versiju pārvaldību un vides failus
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, atbilstoši post_max_size = 32M
    LimitRequestBody 33554432

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

Dubultais Header unset nav nejaušība. Saskaņā ar Apache dokumentāciju galvenes no mod_proxy_fcgi nonāk citā iekšējā tabulā nekā paša servera galvenes; ar abiem variantiem jūs pārtverat abus gadījumus. Citas galvenes, kas aktīvi aizsargā apmeklētājus, apraksta ceļvedis Vietņu drošības galvenes.

Augšupielāžu un kešatmiņas mapēm papildus vajadzīga izpildes bloķēšana. Kā atrast un nobloķēt visas rakstāmās mapes, rakstīts sadaļā PHP izpildes aizliegšana augšupielāžu mapēs.

Moduļu sakārtošana un rezultāta pārbaude

Katrs ielādēts modulis ir kods, kas reaģē uz pieprasījumiem. Pārbaudiet, kuri moduļi ir aktīvi, un izslēdziet to, ko nevajag. Tipiski kandidāti ir autoindex, status bez piekļuves ierobežojuma, cgi un userdir.

# Parādīt aktīvos moduļus
apachectl -M | sort
# Piemērs Debian/Ubuntu: izslēgt direktoriju sarakstu moduli
sudo a2dismod autoindex
# Pārbaudīt konfigurāciju un tikai tad pārlādēt
sudo apachectl configtest && sudo systemctl reload apache2
# Tests no ārpuses: TRACE jāatgriež 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

Īpašu uzmanību pelna mod_status. Statusa lapa rāda darbojošos pieprasījumus ar adresēm un izsauktajiem ceļiem. Ja tā vajadzīga, piekļuvi ierobežojiet ar Require ip uz saviem pārvaldības tīkliem. Tas pats attiecas uz PHP-FPM statusa lapām, kas padarītas sasniedzamas caur Apache.

Kā papildu slānis pirms lietojumprogrammas var būt noderīga sava Web Application Firewall; ievadu apraksta ModSecurity un OWASP Core Rule Set lietošana.

Secinājums: kārtība pārspēj atsevišķu pasākumu

Droša Apache konfigurācija PHP sastāv no dažiem, labi saprastiem elementiem. PHP darbojas caur PHP-FPM atsevišķi no tīmekļa servera, .htaccess netiek izvērtēts, versiju norādes un TRACE ir izslēgti, izmēra robežas atbilst PHP, un rakstāmās mapes neizpilda skriptus. Neviens no šiem punktiem pats par sevi nav iespaidīgs. Kopā tie nodrošina, ka kļūda vienā vietā nenoved uzreiz pie servera pārņemšanas.

Vadībai un projektu vadītājiem gandrīz svarīgāka ir otra īpašība: sakārtota konfigurācija ir izsekojama. Ja visi noteikumi atrodas VirtualHost, nevis izkaisīti desmitos .htaccess failu, nākamās kritiskās ievainojamības gadījumā var ātri pārbaudīt, kura vietne kā pieslēgta. Tādā situācijā kā 2026. gada oktobrī tas ietaupa tieši to laiku, kas ir izšķirošs.

Pāreju tomēr plānojiet mierīgi un ar testa vidi. Pārsteidzīga pāreja no mod_php uz PHP-FPM īsi pirms nedēļas nogales rada drīzāk jaunas problēmas, nekā atrisina.

Kā PHP SOS palīdz konkrēti?

• Pārbaudīt esošo stāvokli: mēs nolasām visu Apache konfigurāciju, visus aktīvos moduļus un visus .htaccess failus.
• Plānot pāreju: kur vēl darbojas mod_php, mēs sagatavojam pāreju uz PHP-FPM ar saviem pūliem katrai vietnei.
• Nostiprināt konfigurāciju: mēs iestatām kodola opcijas, pārņemam .htaccess noteikumus VirtualHost un bloķējam rakstāmās mapes.
• Testēt un dokumentēt: pēc katras izmaiņas mēs pārbaudām vietnes no ārpuses un fiksējam stāvokli serveru nostiprināšanas ietvaros.

Biežāk uzdotie jautājumi

Avoti

• Apache: kodola funkcijas (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: drošības paziņojumi