# WAF és virtuális javítás PHP-hez

> Virtuális javítás PHP-hez: WAF-szabályokat kombinálunk a php.net szerinti átmeneti intézkedésekkel a frissítésig, és megtervezzük a valódi javítást.

Forrás: https://phpsos.de/hu/leistungen/waf-virtuelles-patching/  
Á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:** A PHP-hez való virtuális javítás áthidalja az időt a valódi frissítés telepítéséig. Ehhez egy webalkalmazás-tűzfal szabályait kombináljuk azokkal az átmeneti intézkedésekkel, amelyeket a php.net a PHP2Shell kapcsán közzétett, és rögtön megállapítjuk a rendes javításhoz vezető utat. Teljes védelmet ez nem nyújt, de az átmeneti időben csökkenti a kockázatot.

## Mikor van értelme a virtuális javításnak PHP-hez

A BSI (a német Szövetségi Információbiztonsági Hivatal) PHP2Shell esetében azonnali frissítést ajánl, és ha az nem megy, a webszerverek átmeneti levételét a hálózatról. Sok vállalkozásnak egyik sem megy azonnal: egy webshopnak elérhetőnek kell maradnia, egy saját fejlesztés a frissítés előtt tesztet igényel, vagy a szerver PHP 8.1-gyel és régebbivel fut, amelyhez nincs már hivatalos frissítés.

Ezekben az esetekben a virtuális javítás egy híd. Nem helyettesíti annak eldöntését, hogy nem lenne-e helyénvalóbb az offline üzem. Ezt a mérlegelést Ön végzi, mi a műszaki értékelést adjuk.

## Miért nem elég egy WAF önmagában

A Cloudflare támadási kísérleteket észlelt, és védelmi szabályokat vezetett be, de figyelmeztet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők. Ennek oka a rések természetében rejlik. A CVE-2026-109618 esetében egy Out-of-Memory állapot megszakíthatja a PHP-t, miközben a kérésadatok csak részben vannak inicializálva. A CVE-2026-109619 esetében a belső állapot a memória felszabadítása után megmaradhat, és egy későbbi kérés ugyanabban a workerben felhasználhatja. Az ilyen hibák a szerver állapotától függnek, nem csak egyetlen kérés tartalmától.

Ezért több rétegre építünk: a szerver előtti WAF-szabályokra, magában a PHP-ban lévő átmeneti intézkedésekre és a szerver fokozott megfigyelésére. Minden réteg elfog egy részt, egyik sem elég egyedül. Együtt időt nyernek Önnek a frissítés rendezett telepítéséhez.

## A php.net szerinti átmeneti intézkedések

A php.net több olyan beállítást nevez meg, amely csökkenti a kockázatot, kifejezetten teljes védelem nélkül. Fontos, hogy az alkalmazások ne írhassák felül ezeket az értékeket. Példa egy feltöltéseket is kezelő PHP-FPM-poolra:

```ini
; PHP2Shell átmeneti intézkedések (nem teljes védelem), utána az összes workert újra kell indítani
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; csak PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
```

Feltöltések nélkül a php.net `post_max_size = 8M` értéket ajánl. Mivel a `memory_limit` korlátozását feloldják, hozzátartozik egy memóriahatár a konténer vagy a cgroup szintjén, nem az `RLIMIT_AS` vagy az `RLIMIT_DATA` révén. A `session.upload_progress.enabled=0` beállításnak a php.ini-be, az FPM-poolba vagy a szerverkonfigurációba kell kerülnie, nem az `ini_set()`-be vagy a `.user.ini`-be. Egyúttal ez a megoldás a [CVE-2026-115560](https://phpsos.de/hu/php2shell/cve-2026-115560/) tudnivalójára is. Az összes intézkedés áttekintése a [Azonnali intézkedések, ha még nem tud javítani](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) oldalon van.

> **Fontos:**
> Az átmeneti intézkedések csak az összes PHP-worker újraindítása után hatnak. És csak a jövőbeli támadások ellen védenek: azt, hogy korábban bejutott-e már valaki, nem válaszolják meg.

## Mikor jobb választás az offline üzem

A virtuális javítás nem minden helyzetben a helyes válasz. Egyes konstellációkban azt tanácsoljuk, hogy kövesse a BSI-t, és a webszervert vegye át ideiglenesen le a hálózatról a javításig:

- a szerver **Apache-csal és mod_php-val** fut, ahol a PHP-csapat a legmagasabbra értékeli a kockázatot, és exploitot mutattak be, még mielőtt az alkalmazáskód egyáltalán futna
- a szerveren **különösen védendő adatok** vannak, például egészségügyi, ügyfél- vagy fizetési adatok
- **nincs lehetőség** az átmeneti intézkedések rögzítésére a szerverkonfigurációban, például egyes megosztott tárhelycsomagoknál
- már vannak **jelek** arra, hogy a szervert megtámadták

Az átmeneti offline üzem nem jelenti azt, hogy a weboldalát feltörték. Egyes szolgáltatók elővigyázatosságból levették a weboldalaikat. A látogatóknak szóló rövid, tárgyilagos tájékoztató oldal ilyenkor többnyire jobb megoldás, mint egy meg nem magyarázott kiesés.

## Hogyan segít konkrétan a PHP SOS?

1. **A helyzet vizsgálata:** Felmérjük a PHP-verziókat, az üzemmódokat és a meglévő védelmi rétegeket, például a CDN-t, a WAF-ot vagy a reverse proxyt. A mod_php esetében felhívjuk a figyelmet a PHP-csapat által ott látott megnövekedett kockázatra.
2. **Rétegek kiépítése:** Aktiváljuk vagy kiegészítjük a WAF-szabályokat, az átmeneti intézkedéseket rögzítetten beállítjuk a szerverkonfigurációban, és konténeren vagy cgroupon keresztül korlátozzuk a memóriát. Nginx-beállításoknál az [Nginx és PHP-FPM biztosítása](https://phpsos.de/hu/server/nginx-php-fpm/) oldalra támaszkodunk.
3. **Újraindítás és teszt:** Az összes PHP-folyamatot újraindítjuk, majd ellenőrizzük a feltöltéseket, űrlapokat, bejelentkezést és a pénztárat.
4. **Megfigyelés:** Az átmeneti időben fokozottan figyelünk a workerek összeomlásaira, a memóriacsúcsokra és a szokatlan folyamatokra.
5. **A javítás megtervezése:** Meghatározzuk, mikor és hogyan jön a rendes frissítés, és a [PHP-javítási szolgáltatással](https://phpsos.de/hu/leistungen/php-patch-service/) valósítjuk meg.

## Mit kap, mire van szükségünk, és mit nem ígérünk

Dokumentációt kap az összes beállított szabályról és beállításról indoklással, a tesztek eredményeiről, valamint a valódi javításhoz tartozó időpont- és intézkedési tervről. Öntől szerver- vagy panel-hozzáférésre, a CDN-hez vagy WAF-hoz való hozzáférésre (ha van), egy műszaki kapcsolattartóra és az alkalmazásai feltöltési funkcióira vonatkozó adatokra van szükségünk.

Nem ígérjük, hogy a virtuális javítás megakadályoz egy támadást. Korlátozott ideig csökkenti a kockázatot. A PHP 8.1 és régebbi verzióknál nem tartós állapot; ott az [átállás egy támogatott verzióra](https://phpsos.de/hu/leistungen/php-migration-legacy/) beletartozik a tervbe.


## Gyakori kérdések

**Mi az a virtuális javítás?**  
A virtuális javítás azt jelenti, hogy egy ismert rést az alkalmazás előtt árnyékolunk le, ahelyett hogy magát a kódot módosítanánk. Ez többnyire webalkalmazás-tűzfalon (WAF) vagy konfigurációs változtatásokon keresztül történik. Áthidalás, nem a frissítés pótléka.

**Elég a CDN-szolgáltatóm WAF-ja a PHP2Shell ellen?**  
Önmagában általában nem. A Cloudflare védelmi szabályokat vezetett be, de maga is figyelmeztet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők. A WAF az átmeneti intézkedések és a javítás mellett egy további réteg.

**Meddig támaszkodhatok a virtuális javításra?**  
A lehető legrövidebb ideig. Arra való, hogy áthidalja a rendes frissítésig tartó időt, például amíg szabad lesz egy karbantartási időablak, vagy amíg egy alkalmazást letesztelnek. A PHP 8.1 és régebbi verzióknál ehhez migrációs terv is tartozik.

**Zavarhatják a weboldalamat az átmeneti intézkedések?**  
Igen, ez lehetséges. A kisebb feltöltési korlátok megakadályozhatják a nagy fájlok feltöltését, a session upload progress kikapcsolása pedig a feltöltés közbeni folyamatjelzőket érinti. A legfontosabb funkciókat minden változtatás után teszteljük.

## Források

- [php.net: biztonsági közlemények és átmeneti intézkedések](https://www.php.net/)
- [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)