Mi a WAF, és miért nem gondoltam, hogy 2026-ban erről kell írnom?

Nem gondoltam volna, hogy 2026. október 21-én azt fogom leírni, mi az a WAF, és miért fontos. Húsz éve ez nálam alapfelszereltség. Olyan, mint egy autóban a fék: nem azért van, mert rosszul vezetünk, hanem mert az úton mások is járnak.

Aztán jött a PHP2Shell. Két kritikus, CVSS 9.2-es sérülékenység magában a PHP motorban, belépés nélkül kihasználható, és a javítás megjelenése előtt már támadási kísérleteket is láttak. Azóta gyakorlatilag forródrótként működöm. Két nap alatt több tucat kolléga, ügyfél és ismerős kérdezte meg ugyanazt: mit csináljunk most?

Ebből a sok beszélgetésből született ez az oldal. Nem szakkönyvnek szánom, hanem tapasztalatmegosztásnak – ahogy az oldalon minden más is az.

A kérdés, amivel minden kezdődött: miért nem frissítünk azonnal?

Az egyik kollégám nagyon egyenesen tette fel a kérdést: „Miért ne frissítsünk? A PHP már kiadta az új verziót, és mindig az a lényeg, hogy a legújabb legyen fent.”

Igaza van – félig. Frissíteni természetesen kell, ezen nincs vita. A kérdés az, hogy mikor és hogyan.

Éles környezetben, főleg az egészségügyben vagy a pénzügyi szektorban, egy PHP-frissítés nem úgy megy, hogy kijön az új verzió, és másnap már fent van. Le kell tesztelni a kompatibilitást és a függőségeket. Át kell mennie a change managementen. Meg kell tervezni a visszaállást arra az esetre, ha valami mégsem működik. Ez jó esetben napok, egy nagyobb, sok alkalmazást futtató környezetben akár hetek.

Addig a rendszert valaminek védenie kell. Ez a valami a WAF – a tűzfallal és a hálózati szegmentálással együtt.

Mi az a WAF – egyszerűen

A klasszikus tűzfal azt nézi, ki és hová akar kapcsolódni: melyik IP-cím, melyik port, melyik protokoll. Ha a 443-as port nyitva van a weboldal felé, a tűzfal átengedi a forgalmat. Hogy azon a nyitott porton mi érkezik, azt már nem vizsgálja.

A WAF – Web Application Firewall, magyarul webalkalmazás-tűzfal – pontosan ott kezdi a munkát, ahol a hálózati tűzfal abbahagyja. Belenéz minden egyes HTTP-kérésbe, és azt vizsgálja, mit akar a kérés: milyen paramétereket küld, mekkora a törzse, hány fájlt tölt fel, szabályos-e a formátuma, és hasonlít-e egy ismert támadási mintára.

A WAF két üzemmódban futhat:

• Detekciós mód: csak naplóz, nem tilt. Új szabálynál mindig ezzel kezdek, hogy lássam, mit fogna meg élesben.
• Blokkoló mód: a szabálynak megfelelő kérést visszadobja, jellemzően 403-as hibával. A szabály itt már ténylegesen véd.

És van egy harmadik dolog, amit sokan elfelejtenek: a szabályok karbantartása. Egy WAF, amit egyszer beállítottak, aztán öt évig senki nem nézett rá, papíron létezik, a valóságban alig véd.

Az én utam: 2005 óta, WAF nélkül soha

2005 óta üzemeltetek IT-infrastruktúrát egészségügyi szolgáltatóknak Magyarországon. Ebben a szektorban betegadatokkal dolgozunk, és itt egy adatszivárgás nem „kellemetlenség”, hanem emberek legérzékenyebb adatainak kiszivárgása.

Soha nem építettem olyan hálózatot, ahol ne lett volna tűzfal és WAF. Egyetlen rendszert, alkalmazást vagy weboldalt sem tettem ki az internetre úgy, hogy előtte ne állt volna egy jól beállított, kidolgozott szabályokkal működő WAF.

Mit tapasztaltunk az elmúlt két napban?

Ez a sérülékenység nem az első, és nem is az utolsó. Ahogy az OpenSSL-nél, úgy itt is rendszeresen jönnek majd hasonlók. Egy rendesen felépített környezetben viszont a kockázatuk jelentősen csökkenthető tűzfallal, WAF-fal és szegmentálással.

Több helyen leteszteltük: ahol az általam üzemeltetett WAF a javasolt beállításokkal fut, ott ez a sérülékenység nem volt kihasználható. A szabályokat azóta is folyamatosan finomhangoljuk mindenhol, mert minden alkalmazás egy kicsit másképp működik – ami az egyik helyen ártalmatlan kérés, az a másikon gyanús.

Szabályok a saját tudásbázisomból

Összeszedtem néhány mintát és szabályt a saját tudásbázisomból, amelyet több mint 20 év alatt építettem fel. Ezek nem „varázsszabályok”, hanem a támadási útvonalakat szűkítik: a multipart feldolgozást, a session upload-progress funkciót, valamint a túlméretes vagy mélyen egymásba ágyazott bemeneteket.

1. ModSecurity (Apache / Nginx)

# 1. szabály – A session upload-progress mező tiltása (CVE-2026-109619 útvonal)
# Ezt a mezőt szinte egyetlen alkalmazás sem használja legitim módon.
SecRule ARGS_NAMES "@rx (?i)^PHP_SESSION_UPLOAD_PROGRESS$" \
  "id:1026001,phase:2,deny,status:403,log,\
   msg:'PHP2Shell: session upload-progress field'"

# 2. szabály – Multipart csak a feltöltési végpontokon (CVE-2026-109618 útvonal)
SecRule REQUEST_HEADERS:Content-Type "@rx (?i)^multipart/form-data" \
  "id:1026002,phase:1,deny,status:403,log,chain,\
   msg:'PHP2Shell: multipart to non-upload endpoint'"
  SecRule REQUEST_FILENAME "!@rx ^/(upload|admin/media)/"

# Mezők, fájlok és beágyazási mélység korlátozása
SecRule &ARGS_POST "@gt 200" "id:1026003,phase:2,deny,status:403,log,msg:'PHP2Shell: too many POST fields'"
SecRule &FILES     "@gt 10"  "id:1026004,phase:2,deny,status:403,log,msg:'PHP2Shell: too many files'"
SecRule ARGS_NAMES "@rx (\[[^\]]*\]){8,}" \
  "id:1026005,phase:2,deny,status:403,log,msg:'PHP2Shell: deeply nested parameter'"

# A hibás multipart kéréseket továbbra is tiltjuk
SecRule MULTIPART_STRICT_ERROR "!@eq 0" "id:1026006,phase:2,deny,status:400,log,msg:'Malformed multipart'"
SecRequestBodyLimit 10485760

2. IIS (web.config, URL Rewrite modullal)

<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="10485760" maxQueryString="2048">
        <headerLimits>
          <add header="Content-Type" sizeLimit="256" />
          <add header="Cookie" sizeLimit="4096" />
        </headerLimits>
      </requestLimits>
    </requestFiltering>
  </security>
  <rewrite>
    <rules>
      <rule name="PHP2Shell - block multipart outside upload paths" stopProcessing="true">
        <match url=".*" />
        <conditions>
          <add input="{HTTP_CONTENT_TYPE}" pattern="^multipart/form-data" />
          <add input="{URL}" pattern="^/(upload|admin/media)/" negate="true" />
        </conditions>
        <action type="CustomResponse" statusCode="403" statusReason="Forbidden" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

IIS-en a kérés törzsében nem lehet rákeresni az upload-progress mezőre, ezért ott a php.ini-ben kell kikapcsolni a funkciót.

3. PHP-konfiguráció megerősítése (php.ini)

; Upload-progress funkció kikapcsolása (CVE-2026-109619 útvonal)
session.upload_progress.enabled = 0

; Alacsony POST-méret – az alkalmazás tényleges igényéhez igazítva
post_max_size = 10M

; Csak PHP 8.5 esetén
fatal_error_backtraces = 0

A szabályok mögötti logika

• Multipart csak ott, ahol tényleg van feltöltés. Egy kapcsolati űrlapnak vagy egy API-végpontnak, amely JSON-t fogad, nincs szüksége multipart kérésre.
• Méretkorlátok mindenhol. Kérés törzse, POST-mezők száma, fájlok száma, paraméterek beágyazási mélysége – mind az alkalmazás valós igényéhez szabva.
• Ismert támadási útvonal lezárása. A session upload-progress mező az egyik bizonyított útvonal, és szinte senki nem használja.
• Hibás formátum: azonnali elutasítás. Egy szabálytalan multipart kérésnek nincs keresnivalója az alkalmazásban.

Ideiglenesen szigorúbb WAF – és vállalom, hogy valami eltörik

A tapasztalatom kritikus, aktívan kihasznált sérülékenységeknél egyértelmű: egy korlátozott időre a tudatosan szigorúbb WAF-szabályzat a helyes döntés.

Igen, a szigorúbb szabályok miatt elromolhat egy ritkán használt feltöltő űrlap vagy egy szokatlanul működő bővítmény. Ez elfogadható, átmeneti kompromisszum. Egy hibás funkciót néhány óra alatt ki lehet javítani. Egy ellopott ügyféladatbázist viszont nem lehet visszaszerezni, és a reputációs és szabályozói következmények évekig elkísérnek.

Amikor minden rendszer frissítve van és ellenőriztük, a szabályzatot kontrolláltan vissza lehet lazítani a megszokott alapszintre.

Penteszt és MNB: ahol a WAF alapelvárás

A másik fontos szempont, hogy minden éles rendszert pentesztelni kell, és egy rosszul beállított WAF ott azonnal kibukik. Igaz, a mostani hibát a legtöbb penteszt eddig nem vette észre – de éppen ezért van szükség rétegzett védelemre. A penteszt egy pillanatfelvétel, a WAF minden kérést néz.

A bankszektorban információbiztonsági területen dolgoztam, és ott a WAF mindig alapelvárás volt. Az MNB rendszeresen vizsgálja a bankokat, és felügyeleti elvárásként kezeli, hogy minden internet felé nyitott szolgáltatás WAF mögött legyen.

Nap mint nap látom: tele van az internet WAF nélküli rendszerekkel

A bankok világán kívül viszont egészen más a kép. Nap mint nap látok webalkalmazásokat, weboldalakat, ügyfélportálokat és API-kat, amelyek előtt semmilyen WAF nincs. És nap mint nap találkozom IT-üzemeltető kollégákkal, akik a biztonsági részt egyszerűen kihagyják: a rendszer „működik”, tehát kész van.

Szerintem ez elsősorban nem az egyes üzemeltetők hibája, hanem a vállalatoké. Sok cég nem megfelelő szakembereket és nem megfelelő IT-üzemeltetőket bíz meg, mert olcsóbb, vagy mert „eddig sem volt baj”. És ilyenkor jogos a kérdés: hol van az IBF, hol van a CISO? Ki ellenőrzi, hogy amit kitettek az internetre, az védve van-e?

Felhő és SaaS: olcsóbb – és sokszor védtelen

Nagyon sok felhős és SaaS-szolgáltatás nincs WAF mögött, egyszerűen azért, mert úgy olcsóbb. Közben mindannyian minden nap egyre több ilyet használunk – sokszor anélkül, hogy tudnánk, mi van mögötte:

• könyvelő- és számlázóprogramok, online bérszámfejtés és HR-portálok;
• egészségügyi rendszerek: időpontfoglalók, leletportálok, magánrendelők ügyfélfelületei;
• webshopok és a mögöttük futó fizetési, rendeléskezelő és raktárrendszerek;
• foglalási rendszerek: szállodák, éttermek, edzőtermek, szépségszalonok;
• társasházkezelő és közös képviseleti portálok, ahol a lakók adatai és befizetései vannak;
• iskolai, óvodai és sportegyesületi rendszerek, gyermekek adataival;
• CRM-, ticketing- és ügyfélszolgálati rendszerek, partnerportálok és dokumentummegosztók;
• flottakezelő, telematikai és okosotthon-alkalmazások webes háttérrendszerei.

Ezek mindegyikében személyes, pénzügyi vagy egészségügyi adat van. És a legtöbb felhasználó, sőt a legtöbb cégvezető sem tudja, hogy az általa használt szolgáltatás WAF mögött fut-e, frissítik-e, és mi történik, ha egy PHP2Shellhez hasonló hiba jön.

Hogy mire figyeljen minden cégvezető és vállalat, amely SaaS- és IT-szolgáltatásokat vesz igénybe, és miért a BCDR az első kérdésem minden ilyen helyzetben, azt részletesen egy külön oldalon, a BCDR-ról és az IT-üzemeltetésről írtam le.

Gyakorlati tanácsok

• Semmit ne tegyél ki az internetre WAF nélkül. Se weboldalt, se API-t, se „csak ideiglenes” tesztrendszert.
• Kezdd detekciós módban, aztán élesíts. Egy-két nap napló sokat elárul az alkalmazás valós forgalmáról.
• Legyen gazdája a szabályoknak. Valaki, aki rendszeresen ránéz, finomhangol, és tudja, miért van ott egy-egy szabály.
• Kritikus sérülékenységnél szigoríts ideiglenesen. A kényelmetlenség átmeneti, az adatvesztés végleges.
• A WAF nem mentség a frissítés elhalasztására. Időt nyer, de a PHP-motort ettől még frissíteni kell – tesztelve és visszaállítási tervvel.

Ha szeretnéd, hogy átnézzük a saját WAF- és tűzfalbeállításaidat, vagy kockázatelemzésre, GRC-felülvizsgálatra van szükséged, keress a kapcsolati oldalon vagy a CSE Business oldalán.

Kapcsolódó oldalak

• PHP2Shell sérülékenység (CVE-2026-109618, CVE-2026-109619) – mit jelent, és hogyan csökkenthető a kockázat
• PHP2Shell kockázati kézikönyv – mit jelent a sérülékenység weboldal-típusonként
• BCDR és IT-üzemeltetés – „Csaba, mit csináljunk?” „Mutasd a BCDR-t!”
• Autosecurit / Skyguard teljes leállás – amikor hiányzik az üzletmenet-folytonossági terv
• Három tartalék, egy hibapont – mit tanít egy hajnali kiesés