# Apache védelme mod_php esetén

> Apache mod_php a PHP2Shell után: az üzemmód felismerése, a PHP-modul javítása, az Apache teljes újraindítása és az átállás előkészítése a PHP-FPM-re.

Forrás: https://phpsos.de/hu/server/apache-mod-php/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/php2shell/mod-php-risiko/).

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

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

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

> **Azonnal cselekedjen:**
> Ha a PHP-verziójához még nincs elérhető javítás, a BSI azt javasolja, hogy a webszervert ideiglenesen vegyék le a hálózatról. A mod_phpnál ez különösen nagy súllyal esik latba, mert a támadás az alkalmazáskód előtt is hathat.

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

```apache
# 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](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/).

## 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](https://phpsos.de/hu/server/nginx-php-fpm/); 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](https://phpsos.de/hu/leistungen/php-patch-service/) 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](https://phpsos.de/hu/leistungen/server-haertung/) 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

**Hogyan ismerem fel, hogy a szerverem mod_php-t használ?**  
Ha az Apache betöltött egy PHP-modult, az a modullistában php_module néven vagy a nevében verziószámmal jelenik meg. Emellett egy phpinfo-kimenet a Server API alatt az Apache 2.0 Handler bejegyzést mutatja. Az ilyen tesztfájlt azonnal törölje.

**Miért különösen kritikus a mod_php a PHP2Shell esetében?**  
A PHP-csapat szerint itt a legmagasabb a kockázat; egy exploitot bemutattak, mielőtt egyáltalán alkalmazáskód futna. Így a jól karbantartott alkalmazás sem véd. A gyors frissítés ezért a legmagasabb prioritású.

**Elég az Apache újratöltése a frissítés után?**  
A biztos út a szolgáltatás teljes újraindítása, mert a PHP modulként az Apache-folyamatokban van. Ezután ellenőrizze az összes Apache-folyamat indulási idejét. A frissítésnél régebbi folyamat nem maradhat.

**Munkaigényes a PHP-FPM-re váltás?**  
Többnyire jól tervezhető: telepíteni a PHP-FPM-et, poolokat létrehozni, az Apache-ot proxy_fcgi-ra átállítani, és a prefork helyett másik MPM-re váltani. Előtte teszteljen a környezet egy másolatán.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)