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? í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 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.
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:
- 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.
- 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.
- 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.
- 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 írás írja le.
- 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.
- 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.
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:
# 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 í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.