Configurarea sigură a Apache pentru PHP

Pe scurt: Pentru a configura sigur Apache pentru PHP, conectați PHP prin PHP-FPM și mod_proxy_fcgi, dezactivați .htaccess cu AllowOverride None și stabiliți ServerTokens Prod, ServerSignature Off, TraceEnable Off și Options -Indexes. LimitRequestBody îl adaptați la limitele PHP, iar modulele de care nu aveți nevoie le dezactivați. Configurația nu înlocuiește o actualizare PHP, dar reduce considerabil suprafața de atac.

Apache după PHP2Shell: mai mult decât o repornire

Operatorii Apache au fost în octombrie 2026 sub o presiune deosebită. Echipa PHP consideră riscul cel mai ridicat la mod_php, pentru că acolo a fost demonstrat un exploit înainte ca vreun cod al aplicației să ruleze. Pașii acuți, adică patchul și repornirea completă, îi descrie pagina De ce poartă mod_php cel mai mare risc.

După patch rămâne întrebarea cât de bună este configurația Apache însăși. Serverele crescute în timp poartă adesea setări acumulate de-a lungul multor ani: liste de directoare, drepturi .htaccess deschise, module de care nu mai are nevoie nimeni. Fiecare dintre ele poate face o eroare ulterioară mai mare decât ar trebui să fie.

Acest articol descrie o configurație de bază suplă și sigură pentru Apache 2.4 cu PHP-FPM. Exemplele folosesc căi Debian și Ubuntu; în familia RHEL, fișierele se află în /etc/httpd/.

Conectarea PHP prin PHP-FPM în loc de mod_php

Cu PHP-FPM, PHP rulează în procese proprii, separate de serverul web. Apache transmite cererile mai departe prin mod_proxy_fcgi. Potrivit documentației Apache, conectarea prin SetHandler are un avantaj față de ProxyPassMatch: Apache asociază mai întâi singur cererea unui fișier din sistemul de fișiere și abia apoi o transmite către PHP-FPM.

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

Modulele le activați sub Debian și Ubuntu cu a2enmod proxy_fcgi. Cine trece de la mod_php dezactivează modulul PHP și trece apoi de la MPM-ul Prefork la cel Event. Contextul vechiului mod de operare îl explică mod_php explicat: PHP în procesul Apache.

Pe partea PHP-FPM, security.limit_extensions = .php aparține fiecărui pool. Potrivit manualului PHP, FPM execută altfel și fișiere .phar.

Configurarea sigură Apache PHP: opțiunile de bază

Unele setări se aplică întregului server și aparțin unui fișier de configurare propriu, de exemplu /etc/apache2/conf-available/haertung.conf, activat cu a2enconf haertung.

# Scurtarea indicațiilor de versiune (posibilă doar la nivel de server)
ServerTokens Prod
ServerSignature Off

# Dezactivarea metodei TRACE
TraceEnable Off

# Mai întâi nu se permite nimic, site-urile permit țintit
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Tabelul următor încadrează cele mai importante opțiuni. Valorile implicite și efectul provin din documentația Apache.

Important la AllowOverride: multe distribuții și ghiduri CMS stabilesc pentru webroot AllowOverride All. Astfel, orice fișier .htaccess poate modifica reguli Rewrite, handlere și, la mod_php, chiar setări PHP. Un atacator cu drepturi de scriere într-un dosar de upload poate depune acolo un .htaccess propriu. Cu AllowOverride None, această cale este închisă.

Un VirtualHost ca șablon

VirtualHost-ul următor reunește punctele pentru un singur site. Căile certificatelor, socketul și directoarele le adaptați. mod_ssl și mod_headers trebuie să fie active.

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

    # Blocarea controlului versiunilor și a fișierelor de mediu
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, potrivit cu post_max_size = 32M
    LimitRequestBody 33554432

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

Dublul Header unset nu este o greșeală. Potrivit documentației Apache, antetele din mod_proxy_fcgi ajung într-un tabel intern diferit de antetele serverului însuși; cu ambele variante prindeți ambele cazuri. Alte antete care protejează activ vizitatorii descrie ghidul Antete de securitate pentru site-uri.

Dosarele de upload și de cache au nevoie suplimentar de o blocare a execuției. Cum găsiți și blocați toate dosarele scriibile se află la Interzicerea execuției PHP în dosarele de upload.

Curățarea modulelor și verificarea rezultatului

Fiecare modul încărcat este cod care reacționează la cereri. Verificați ce module sunt active și dezactivați ce nu folosiți. Candidați tipici sunt autoindex, status fără restricție de acces, cgi și userdir.

# Afișarea modulelor active
apachectl -M | sort
# Exemplu Debian/Ubuntu: dezactivarea modulului pentru liste de directoare
sudo a2dismod autoindex
# Verificați configurația și abia apoi reîncărcați
sudo apachectl configtest && sudo systemctl reload apache2
# Test din exterior: TRACE trebuie să returneze 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

mod_status merită atenție specială. Pagina de stare arată cererile în curs, cu adrese și căi apelate. Dacă este necesară, restrângeți accesul cu Require ip la rețelele dumneavoastră de administrare. Același lucru este valabil pentru paginile de stare ale PHP-FPM, făcute accesibile prin Apache.

Ca strat suplimentar în fața aplicației poate fi util un Web Application Firewall propriu; introducerea o descrie Utilizarea ModSecurity și OWASP Core Rule Set.

Concluzie: ordinea învinge măsura izolată

O configurație Apache sigură pentru PHP constă din puține elemente de bază, bine înțelese. PHP rulează prin PHP-FPM, separat de serverul web, .htaccess nu este evaluat, indicațiile de versiune și TRACE sunt dezactivate, limitele de dimensiune se potrivesc cu PHP, iar dosarele scriibile nu execută scripturi. Niciunul dintre aceste puncte nu este spectaculos în sine. Împreună fac ca o eroare dintr-un loc să nu ducă imediat la preluarea serverului.

Pentru conducere și responsabilii de proiect, o a doua caracteristică este aproape mai importantă: o configurație ordonată este verificabilă. Dacă toate regulile se află în VirtualHost, în loc să fie împrăștiate în zeci de fișiere .htaccess, la următoarea vulnerabilitate critică se poate verifica repede ce site este conectat cum. Într-o situație ca cea din octombrie 2026, aceasta economisește exact timpul care contează.

Planificați totuși trecerea cu calm și cu un mediu de test. O trecere grăbită de la mod_php la PHP-FPM, chiar înaintea unui weekend, creează mai degrabă probleme noi decât rezolvă.

Cum ajută PHP SOS concret?

• Verificarea stării existente: Citim întreaga configurație Apache, toate modulele active și toate fișierele .htaccess.
• Planificarea trecerii: Unde mai rulează mod_php, pregătim trecerea la PHP-FPM, cu pool-uri proprii pentru fiecare site.
• Securizarea configurației: Stabilim opțiunile de bază, preluăm regulile .htaccess în VirtualHost-uri și blocăm dosarele scriibile.
• Testare și documentare: După fiecare modificare verificăm site-urile din exterior și consemnăm starea în cadrul securizării serverului.

Întrebări frecvente

Surse

• Apache: funcții de bază (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: anunțuri de securitate