Apache védelme mod_php esetén

Röviden: Apache mod_php esetén a PHP közvetlenül a webszerverben fut. A PHP-csapat a PHP2Shell kockázatát éppen ebben az üzemmódban értékeli a legmagasabbra, mert egy exploitot bemutattak, mielőtt egyáltalán alkalmazáskód futna. Javítson azonnal, indítsa újra teljesen az Apache-ot, majd tervezze meg az átállást a PHP-FPM-re.

Mi a mod_php, és miért számít most

A mod_phpnál az Apache a PHP-t modulként tölti be minden saját munkafolyamatába. Minden PHP-fájlra irányuló kérést közvetlenül ebben a folyamatban hajt végre. Ez sokáig a szabvány volt, és egyszerűen beállítható. Ugyanakkor azt is jelenti: a szerver összes weboldala ugyanazzal a felhasználóval fut, és a PHP osztozik a folyamaton a webszerverrel.

A PHP2Shell a CVE-2026-109618 és a CVE-2026-109619 rést foglalja magában, mindkettő CVSS v4.0 9,2 értékű. A másodiknál egy kérés belső állapota a memória felszabadítása után is megmaradhat, és ugyanabban a folyamatban egy későbbi kérés felhasználhatja. A mod_php esetében a PHP-csapat a legmagasabb kockázatot állapította meg. A hátteret és a besorolást a következő oldal tartalmazza: Miért a mod_php viseli a legmagasabb kockázatot.

Az Apache mod_php felismerése és a verzió ellenőrzése

Először ellenőrizze, hogy az Apache egyáltalán mod_php-t használ-e. A következő parancsok csak olvasnak. A parancs- és csomagnevek disztribúciónként eltérnek, és példák.

# Debian/Ubuntu: betöltött modulok
apache2ctl -M 2>/dev/null | grep -i php

# RHEL-család
httpd -M 2>/dev/null | grep -i php

# Melyik MPM aktív? A mod_php a prefork-ot feltételezi
apache2ctl -V 2>/dev/null | grep -i mpm

# A modul csomagállapota (példák)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'

Ha egy php_module típusú modul megjelenik, a mod_php fut. A megjelenített PHP-verzió önmagában nem bizonyítja a javítást, mert a disztribúciók a javításokat gyakran backportként telepítik. A PHP-projekt javított verziói a 8.5.12, 8.4.27, 8.3.36 és 8.2.35. Disztribúciós csomagoknál a CVE-számokat tartalmazó változásnapló számít.

Javítás és az Apache teljes újraindítása

Telepítse a frissítést a csomagkezelőn keresztül. Mivel a PHP az Apache-folyamatban van, utána az egész szolgáltatást újra kell indítani. A konfiguráció újratöltése itt nem a biztos út.

# Debian/Ubuntu
systemctl restart apache2

# RHEL-család
systemctl restart httpd

# Ellenőrzés: az összes Apache-folyamat indulási ideje
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

Az összes Apache-folyamatnak a frissítés utáni indulási időt kell mutatnia. Ha ugyanazon a szerveren emellett PHP-FPM vagy php-cgi is fut, indítsa újra ezeket a szolgáltatásokat is.

Átmeneti intézkedések az Apache-konfigurációban

A php.net átmeneti intézkedéseket nevez meg, amelyek csökkentik a kockázatot, de nem nyújtanak teljes védelmet. A mod_phpnál az értékeket php_admin_value, illetve php_admin_flag segítségével adja meg az Apache-konfigurációban, hogy a .htaccess és az alkalmazások ne írhassák felül őket.

# Példa: a VirtualHost- vagy a szerverszintű konfigurációban
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>

Feltöltési funkcióval a php.net post_max_size = 32M értéket nevezi meg, az upload_max_filesize ennél kisebb. A PHP 8.5-nél ehhez jön a fatal_error_backtraces=0. A memory_limit=-1 megjegyzést csak akkor valósítsa meg, ha mellette cgroupokon keresztül memóriakorlátot állít a szolgáltatásra, például a MemoryMax segítségével egy systemd-kiegészítésben, nem a RLIMIT_AS vagy a RLIMIT_DATA útján. Utána teljesen indítsa újra az Apache-ot. Az összes intézkedés áttekintése: Azonnali intézkedések javítás nélkül.

Az út a mod_php-tól el

Az akut javítás után megéri az átállás a PHP-FPM-re. Ilyenkor a PHP saját folyamatokban fut, a webszervertől elválasztva. Minden weboldal kaphat saját poolt saját felhasználóval, a korlátok poolonként beállíthatók, az újraindítások pedig csak a PHP-t érintik. Az Apache a mod_proxy_fcgi segítségével köti be a PHP-FPM-et, és a prefork helyett korszerűbb MPM-et, például eventet használhat.

Az átállást tesztkörnyezetben tervezze meg: weboldalanként poolokat létrehozni, a fájljogosultságokat az új felhasználókhoz igazítani, a php_value bejegyzéseket tartalmazó .htaccess-sorokat a pool beállításaiba átvinni, terheléses teszteket futtatni. Hogyan néz ki egy rendezett felépítés, azt mutatja a Nginx védelme PHP-FPM-mel; az alapelvek az Apache-ra PHP-FPM-mel ugyanúgy érvényesek.

Az üzemmódtól függetlenül: a javítás nem távolítja el a már bejuttatott kártevőt. Őrizze meg a naplókat 2026. október 20-tól, és ellenőrizze a szervert nyomokra.

A mod_php-s szervereken a nyomkeresésnél érdemes megnézni a közös felhasználót. Mivel az összes weboldal az Apache felhasználója alatt fut, például www-data vagy apache, az a támadó, aki átvett egy weboldalt, általában a többi fájljait is olvashatja és módosíthatja. Ezért ne csak azt a weboldalt vizsgálja, amelyet gyanúsnak talál, hanem a szerver összes Document Rootját. Különösen figyeljen a friss módosítási dátumú PHP-fájlokra a feltöltési és gyorsítótár-könyvtárakban, az Apache felhasználójához tartozó programkódra, valamint az ennek a felhasználónak a crontabjában lévő ismeretlen bejegyzésekre. Ha talál valamit, először mentse az állapotot, és ne töröljön elhamarkodottan, hogy az ok később is követhető maradjon.

Hogyan segít konkrétan a PHP SOS?

• Ellenőrizzük az üzemmódot, az MPM-et és a csomagállapotot, és értékeljük, hogy a szervere valóban javítva van-e.
• A PHP-javítási szolgáltatáson keresztül telepítjük a frissítést, teljesen újraindítjuk az Apache-ot, és dokumentáljuk az igazolást.
• A javításig az átmeneti intézkedéseket felülírhatatlanul állítjuk be, és szolgáltatásszinten korlátozzuk a memóriát.
• A szerver-megerősítés keretében megtervezzük és letesztelve elvégezzük az átállást a PHP-FPM-re, elkülönített poolokkal.

Gyakori kérdések

Források

• php.net: biztonsági közlemények
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets