Az Apache biztonságos konfigurálása PHP-hez

Röviden: Az Apache PHP-hez való biztonságos konfigurálásához kapcsolja be a PHP-t a PHP-FPM-en és a mod_proxy_fcgi-n át, kapcsolja ki a .htaccess-t az AllowOverride None-nal, és állítsa be a ServerTokens Prod, ServerSignature Off, TraceEnable Off és Options -Indexes értékeket. A LimitRequestBody értékét igazítsa a PHP határaihoz, a nem szükséges modulokat kapcsolja ki. A konfiguráció nem pótolja a PHP-frissítést, de jelentősen csökkenti a támadási felületet.

Az Apache a PHP2Shell után: több, mint egy újraindítás

Az Apache-üzemeltetők 2026 októberében különös nyomás alatt álltak. A PHP-csapat a mod_php kockázatát értékeli a legmagasabbra, mert ott már azelőtt bemutattak egy exploitot, hogy egyáltalán alkalmazáskód futna. Az akut lépéseket, vagyis a javítást és a teljes újraindítást, a Miért a mod_php viseli a legnagyobb kockázatot oldal írja le.

A javítás után az marad a kérdés, mennyire jó maga az Apache-konfiguráció. A hosszú idő alatt kialakult szerverek gyakran sok év beállításait hordozzák: könyvtárlistákat, nyitott .htaccess jogokat, olyan modulokat, amelyekre már senkinek sincs szüksége. Mindegyik nagyobbá teheti egy későbbi hibát, mint amekkorának lennie kellene.

Ez a cikk egy karcsú, biztonságos alapkonfigurációt ír le az Apache 2.4-hez PHP-FPM-mel. A példák Debian- és Ubuntu-útvonalakat használnak; az RHEL-családban a fájlok a /etc/httpd/ alatt vannak.

A PHP bekapcsolása PHP-FPM-mel a mod_php helyett

A PHP-FPM-mel a PHP saját folyamatokban fut, a webszervertől elkülönítve. Az Apache a kéréseket a mod_proxy_fcgi-n keresztül továbbítja. Az Apache dokumentációja szerint a SetHandler-rel való bekapcsolásnak előnye van a ProxyPassMatch-csel szemben: az Apache a kérést előbb maga rendeli hozzá egy fájlhoz a fájlrendszerben, és csak utána adja tovább a PHP-FPM-nek.

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

A modulokat Debianon és Ubuntun az a2enmod proxy_fcgi paranccsal aktiválja. Aki a mod_php-ról áll át, kikapcsolja a PHP-modult, majd a Prefork MPM-ről az Event MPM-re vált. A régi üzemmód hátterét a A mod_php magyarázata: a PHP az Apache-folyamatban magyarázza.

A PHP-FPM oldalán a security.limit_extensions = .php minden poolba beletartozik. A PHP kézikönyve szerint az FPM különben a .phar fájlokat is végrehajtja.

Az Apache biztonságos konfigurálása PHP-hez: az alapopciók

Egyes beállítások az egész szerverre érvényesek, és egy saját konfigurációs fájlba valók, például a /etc/apache2/conf-available/haertung.conf-ba, amelyet az a2enconf haertung aktivál.

# Verziómegjelölések rövidítése (csak szerverszinten lehetséges)
ServerTokens Prod
ServerSignature Off

# A TRACE metódus kikapcsolása
TraceEnable Off

# Alapvetően semmit sem engedélyezni, a weboldalak célzottan engedélyeznek
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

A következő táblázat besorolja a legfontosabb opciókat. Az alapértékek és a hatás az Apache dokumentációjából származnak.

Fontos az AllowOverride-nál: sok disztribúció és CMS-útmutató a webrootra AllowOverride All értéket állít be. Ezzel minden .htaccess fájl módosíthat átírási szabályokat, kezelőket, és mod_php esetén még PHP-beállításokat is. Egy támadó, aki írási joggal rendelkezik egy feltöltési mappában, ott saját .htaccess fájlt helyezhet el. Az AllowOverride None ezt az utat lezárja.

Egy VirtualHost mint sablon

A következő VirtualHost egyetlen weboldalra köti össze a pontokat. A tanúsítványútvonalakat, a sockete és a könyvtárakat igazítsa. A mod_ssl és a mod_headers legyen aktív.

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

    # Verziókezelés és környezeti fájlok zárolása
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, a post_max_size = 32M értékhez illően
    LimitRequestBody 33554432

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

A kettős Header unset nem véletlen. Az Apache dokumentációja szerint a mod_proxy_fcgi fejlécei más belső táblázatba kerülnek, mint a szerver saját fejlécei; mindkét változattal mindkét esetet elkapja. További fejléceket, amelyek aktívan védik a látogatókat, a Biztonsági fejlécek weboldalakhoz útmutató ír le.

A feltöltési és gyorsítótár-mappáknak ezenfelül végrehajtási zárolásra van szükségük. Hogyan találja meg és zárolja az összes írható mappát, azt a PHP-végrehajtás tiltása a feltöltési mappákban cikk írja le.

A modulok kigyomlálása és az eredmény ellenőrzése

Minden betöltött modul olyan kód, amely kérésekre reagál. Ellenőrizze, mely modulok aktívak, és kapcsolja ki, amire nincs szüksége. Tipikus jelöltek az autoindex, a hozzáférés-korlátozás nélküli status, a cgi és a userdir.

# Az aktív modulok megjelenítése
apachectl -M | sort
# Példa Debian/Ubuntu: a könyvtárlista-modul kikapcsolása
sudo a2dismod autoindex
# A konfiguráció ellenőrzése, és csak utána újratöltés
sudo apachectl configtest && sudo systemctl reload apache2
# Teszt kívülről: a TRACE 405-öt adjon, a .git 403-at
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

Különös figyelmet érdemel a mod_status. A státuszoldal a futó kéréseket címekkel és meghívott útvonalakkal mutatja. Ha szükség van rá, korlátozza a hozzáférést a Require ip-vel a kezelői hálózataira. Ugyanez érvényes a PHP-FPM azon státuszoldalaira, amelyeket az Apache-on keresztül tettek elérhetővé.

További rétegként az alkalmazás előtt értelmes lehet egy saját Web Application Firewall; a bevezetést a ModSecurity és az OWASP Core Rule Set alkalmazása írja le.

Összegzés: a rend többet ér az egyedi intézkedésnél

A PHP-hez készült biztonságos Apache-konfiguráció néhány jól megértett építőelemből áll. A PHP a PHP-FPM-en át, a webszervertől elkülönítve fut, a .htaccess nincs kiértékelve, a verziómegjelölések és a TRACE ki vannak kapcsolva, a méretkorlátok illenek a PHP-hoz, és az írható mappák nem futtatnak szkripteket. E pontok egyike sem látványos önmagában. Együtt gondoskodnak arról, hogy egy helyen elkövetett hiba ne vezessen azonnal a szerver átvételéhez.

A vezetés és a projektfelelősök számára majdnem fontosabb egy második tulajdonság: egy rendezett konfiguráció követhető. Ha az összes szabály a VirtualHostban áll, és nem tucatnyi .htaccess fájlban szétszórva, a következő kritikus résnél gyorsan ellenőrizhető, melyik weboldal hogyan van bekapcsolva. Egy olyan helyzetben, mint 2026 októbere, ez éppen azt az időt takarítja meg, amelyre szükség van.

Az átállást mégis nyugodtan és tesztkörnyezettel tervezze meg. A mod_php-ról PHP-FPM-re való elhamarkodott váltás egy hétvége előtt inkább új problémákat okoz, mint megold.

Hogyan segít konkrétan a PHP SOS?

• Az állapot ellenőrzése: Kiolvassuk a teljes Apache-konfigurációt, az összes aktív modult és az összes .htaccess fájlt.
• Az átállás tervezése: Ahol még mod_php fut, előkészítjük a PHP-FPM-re való váltást weboldalankénti saját poolokkal.
• A konfiguráció keményítése: Beállítjuk az alapopciókat, a .htaccess szabályokat átvesszük a VirtualHostokba, és zároljuk az írható mappákat.
• Tesztelés és dokumentálás: Minden módosítás után kívülről ellenőrizzük a weboldalakat, és az állapotot a szerverkeményítés keretében rögzítjük.

Gyakori kérdések

Források

• Apache: alapfunkciók (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: biztonsági közlemények