# Cloudflare védelmi szabályok a PHP2Shell ellen: mit tudnak és mit nem

> A Cloudflare október 21. óta WAF-szabályokkal véd a PHP2Shell ellen. Mit fednek le a szabályok, hol kerülhetők meg, és mit érdemes most ellenőriznie.

Forrás: https://phpsos.de/hu/blog/cloudflare-waf-php2shell/  
Á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 Cloudflare saját közlése szerint 2026. október 21-e, 03:02 UTC óta aktív védelmi szabályokkal rendelkezik a PHP2Shell ellen, az ingyenes csomagban lévő ügyfeleknek is. A szabályok csökkentik a Cloudflare-en keresztül haladó forgalom kockázatát. Nem hatnak, ha az eredeti szerver közvetlenül elérhető, és nem helyettesítik a PHP-frissítést. Aki Cloudflare-t használ, ellenőrizze a szabálymódot, az eredeti szerver védelmét és a javítási állapotot.

## A kiindulópont: védelem már a javítás előtt

A Cloudflare szokatlanul korán lépett a PHP2Shell esetében. A Cloudflare-blog szerint a védelmi szabályok már több órával a PHP-frissítések 14:00 UTC-kor esedékes hivatalos közzététele előtt futottak. A Cloudflare azt is közölte, hogy támadási kísérleteket figyelt meg ügyfelei ellen, és hogy a támadók módosították a mintáikat a szabályok megkerülésére.

Sok üzemeltető ebből azt a következtetést vonta le: „A Cloudflare mögött vagyunk, tehát védettek vagyunk.” Ez csak részben igaz. Ez az írás elmagyarázza, mit fednek le valójában a szabályok. A tűzfal és a frissítés közötti általános mérlegelést a [WAF vagy frissítés?](https://phpsos.de/hu/blog/waf-oder-update/) írás nyújtja.

## Mit vezetett be a Cloudflare a PHP2Shell ellen

A Cloudflare-blog adatai szerint három építőelem van:

| Csomag | Védelem a Cloudflare szerint | Mit érdemes tennie |
|---|---|---|
| Free | új szabályok a Managed Free Rulesetben, automatikusan aktívak | ellenőrizze, hogy a domain a Cloudflare-en keresztül fut |
| Pro, Business, Enterprise | megfelelő szabályok a Managed Rulesetben | gondoskodjon arról, hogy a Ruleset „Block” módban legyen |
| minden csomag | alapértelmezett szabály az új válaszvédelmi tűzfalban | ne kapcsoljon ki semmit, figyelje az eseményeket |

A harmadik építőelem új. A Cloudflare „full transaction detection”-nek nevezi: a WAF nem csak a kérést, hanem a szerver válaszát is vizsgálja. Az ok a Cloudflare szerint: a kérés önmagában nem mindig elég ahhoz, hogy egy támadást biztonságosan meg lehessen különböztetni a normál forgalomtól. A PHP2Shell ennek a funkciónak az első bevetése a kezelt szabályokban.

## A Cloudflare-szabályok korlátai

Bármennyire hasznosak a szabályok, egyértelmű korlátaik vannak, amelyeket részben maga a Cloudflare nevez meg:

- **Csak a Cloudflare-en keresztüli forgalom:** A szabályok azt vizsgálják, ami a Cloudflare-en átáramlik. Ha az eredeti szerver az IP-címén közvetlenül elérhető, a támadó megkerülheti a védelmet.
- **Nincs visszavonás:** A Cloudflare szerint egy válaszoldali szabály visszatarthatja a választ, de nem teheti meg nem történtté azt, ami a szerveren már megtörtént.
- **Változó támadási minták:** A Cloudflare folyamatosan igazítja a szabályokat, mert a támadók módosítják a kéréseiket. Egy új változat és az új szabály között rés lehet.
- **Nem helyettesíti a frissítést:** A Cloudflare kifejezetten azt javasolja, hogy a WAF ellenére frissítse a PHP-t. Az alkalmazáskód vagy a bővítmények frissítése sem szünteti meg a réseket.
- **A CVE-2026-115560 különleges esete:** A Cloudflare október 23-i kiegészítése szerint a szabály nem érvényesül, ha a session-feltöltési folyamat nevét módosították a konfigurációban. Erről a közleményről többet a [CVE-2026-115560](https://phpsos.de/hu/php2shell/cve-2026-115560/) oldalon talál.

### Mit mondanak a blokkolt kérések, és mit nem

Sok ügyfél a közlemény után megnézi a biztonsági eseményeit, és blokkolt kéréseket talál. Ez először csak azt mutatja, hogy a domainjét vizsgálták, és a szabály működött. Betörést ez nem bizonyít. Fordítva, az üres eseménylista nem jelent riasztás-lefújást: ha egy támadás közvetlenül az eredeti szerver ellen, vagy október 21. előtt zajlott, a Cloudflare-nél egyáltalán nem jelenik meg.

Megbízhatóbb az összevetés magának a webszervernek a naplóival. Azok a kérések, amelyek ott megérkeznek, de nem Cloudflare-címekről származnak, közvetlen hozzáférésre utalnak. Mentse ezeket a naplókat október 20-tól, ahogyan a szaksajtó javasolja. A Cloudflare emellett arra is rámutat, hogy a feltöltésekre vonatkozó korlátozások csökkenthetik a kockázatot, a PHP-frissítést azonban nem helyettesítik.

> **Fontos:**
> A Cloudflare mögött a leggyakoribb gyenge pont nem a szabály, hanem az az út, amely mellette elvezet: egy eredeti szerver, amely az IP-címén vagy egy nem védett aldomainen keresztül közvetlenül válaszol.

## Ellenőrzőlista Cloudflare-ügyfeleknek

Ezeket a lépéseket Ön vagy a szolgáltatója rövid időn belül elvégezheti:

1. **A csomag és a szabálymód ellenőrzése:** Fizetős csomagoknál a vezérlőpulton ellenőrizze, hogy a Managed Ruleset „Block” módban aktív.
2. **A biztonsági események megtekintése:** A Security Events alatt nézze meg, megjelennek-e blokkolt kérések. Ez megmutatja, hogy a domainjei már célpontok voltak-e.
3. **A DNS-bejegyzések átnézése:** Minden bejegyzés, amely a webszerverre mutat, de nem a Cloudflare-en keresztül fut, lehetséges kerülőút. Tipikusak a staging, FTP vagy levelezés aldomainjei ugyanazon a szerveren.
4. **Az eredeti szerver elszigetelése:** Úgy konfigurálja a webszervert, hogy a HTTP-t és a HTTPS-t csak a Cloudflare-től fogadja el, például tűzfallal a Cloudflare által közzétett címtartományokkal, vagy egy alagúton keresztül. Hogy ez általában hogyan megy, azt a [Tűzfal webszerverhez](https://phpsos.de/hu/blog/firewall-fuer-webserver/) írás írja le.
5. **A közvetlen hozzáférés tesztelése:** Kívülről ellenőrizze, hogy az eredeti szerver válaszol-e a Cloudflare nélkül.
6. **A PHP frissítése és újraindítása:** A szabályok a második védelmi vonal. Az első a PHP javított állapotban, [az összes PHP-folyamat újraindításával](https://phpsos.de/hu/php2shell/php-fpm-neustart/).

Az 5. lépéshez elegendő egy ártalmatlan teszt, amely csak a fejléceket kérdezi le. Az IP-cím helyőrző az Ön eredeti szerverének:

```bash
# Közvetlenül válaszol az eredeti szerver, a Cloudflare-t megkerülve?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
```

Ha itt a weboldala szabályos válasza érkezik, az eredeti szerver közvetlenül elérhető, és a Cloudflare-védelem megkerülhető.

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

- **Konfigurációellenőrzés:** Ellenőrizzük a szabálymódot, a DNS-bejegyzéseket és az eredeti szerverhez való közvetlen hozzáférést.
- **Az eredeti szerver biztosítása:** A webszervert a Cloudflare-en keresztüli forgalomra korlátozzuk, a weboldala megszakítása nélkül.
- **Javítás és igazolás:** Frissítjük a PHP-t, újraindítunk minden folyamatot, és dokumentáljuk az állapotot.
- **Események kiértékelése:** Átnézzük a blokkolt kéréseket, és összevetjük őket a szerver naplóival.

Hogyan kombináljuk a WAF-szabályokat és az átmeneti intézkedéseket, azt a [WAF és virtuális javítás](https://phpsos.de/hu/leistungen/waf-virtuelles-patching/) írja le.

## Összegzés

A Cloudflare PHP2Shell elleni szabályai valódi nyereséget jelentenek, különösen azért, mert korán és az ingyenes csomagban is megérkeztek. De ez egy védőpajzs az ajtó előtt, nem zár az ajtón. Aki a Cloudflare mögött ül, három dolgot biztosítson: szabályok Block módban, nincs út a proxy mellett, és a PHP javított állapotban.


## Gyakori kérdések

**Védett vagyok a PHP2Shell ellen az ingyenes Cloudflare-csomaggal?**  
A Cloudflare szerint az ingyenes ügyfelek is automatikusan megkapják a védelmi szabályokat. Ezek azonban csak a Cloudflare-en keresztül haladó forgalomra hatnak, és nem helyettesítik a szerveren a PHP-frissítést. Ha az eredeti szerver közvetlenül elérhető, a védelem nem érvényesül.

**Mit kell beállítanom a fizetős Cloudflare-csomagoknál?**  
A Cloudflare azt javasolja a Pro, Business és Enterprise csomagos ügyfeleknek, hogy ellenőrizzék, a Managed Ruleset Block módban fut-e. Ha csak naplóz, a támadásokat ugyan rögzíti, de nem állítja meg.

**Mi az a full transaction detection?**  
A Cloudflare WAF egy új funkciója, amely nem csak a kérést, hanem a szerver válaszát is vizsgálja. Így felismerhető, hogy egy támadási kísérlet hatásos-e, és a válasz visszatartható. Ami a szerveren már lefutott, azt a Cloudflare szerint nem teszi meg nem történtté.

**Lefedi a Cloudflare a CVE-2026-115560-at is?**  
A Cloudflare október 23-án kiegészítette a közleményét a CVE-2026-115560-nal. A Cloudflare szerint a hozzá tartozó szabály nem érvényesül, ha a session-feltöltési folyamat nevét módosították a PHP-konfigurációban. Ettől függetlenül a php.net azt javasolja, hogy állítsa be a session.upload_progress.enabled=0 értéket.

## Források

- [Cloudflare-blog: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)
- [Cloudflare-blog: Introducing full transaction detection for Cloudflare WAF](https://blog.cloudflare.com/full-transaction-waf/)
- [php.net: biztonsági közlemények](https://www.php.net/)