A tűzfal szót szinte mindenki hallotta már. Sokan úgy képzelik el, mint egy vastag digitális falat, amely a számítógép vagy a vállalati hálózat körül áll, és nem engedi be a támadókat. Ez a hasonlat nem teljesen rossz, de túlságosan leegyszerűsíti a valóságot.
A modern informatikai rendszerekben többféle tűzfal működhet, és ezek nem ugyanazt figyelik. Egy hagyományos hálózati tűzfal elsősorban azt vizsgálja, hogy melyik címről, melyik címre, milyen protokollon és melyik porton érkezik a forgalom. Egy alkalmazásszintű tűzfal ennél mélyebbre néz: megpróbálja megérteni, hogy mit akar tenni az adott kérés az alkalmazással.
Képzeljünk el egy irodaházat. A hagyományos tűzfal olyan, mint a parkoló sorompója. Ellenőrzi, honnan jött az autó, van-e engedélye behajtani, és melyik kaput használja. Az alkalmazásszintű tűzfal inkább a recepción dolgozó biztonsági munkatársra hasonlít. Nemcsak azt nézi meg, hogy valaki beléphet-e az épületbe, hanem azt is, hogy mit visz magával, melyik irodába tart, és életszerű-e az indoka.
A legfontosabb különbség: a hálózati tűzfal a kapcsolatot, az alkalmazásszintű tűzfal pedig a kapcsolat tartalmát és szándékát is vizsgálhatja.
Ez azért lényeges, mert a támadók gyakran teljesen szabályosnak látszó csatornán érkeznek. Egy weboldalnak például fogadnia kell a HTTPS-forgalmat a 443-as porton. Ha ezt a portot lezárnánk, maga a weboldal is elérhetetlenné válna. A támadó ezért nem feltétlenül próbál tiltott portot használni. Inkább egy engedélyezett webes kérésbe rejt olyan adatot, amely hibás működésre próbálja rávenni az alkalmazást.
Az alkalmazásszintű védelem feladata éppen az ilyen helyzetek felismerése.
Mit jelent pontosan az „alkalmazásszint”?
A hálózati kommunikációt gyakran rétegekre bontva magyarázzák. Az egyik legismertebb modell az OSI-modell, amely hét réteget különböztet meg. A legfelső, hetedik réteg az alkalmazási réteg. Itt találhatók azok a protokollok és adatformátumok, amelyekkel a felhasználókhoz közel álló szolgáltatások kommunikálnak.
Ilyen lehet például:
- a HTTP és a HTTPS;
- a DNS;
- az SMTP és más levelezési protokollok;
- az FTP;
- bizonyos adatbázis-protokollok;
- a webes API-k által használt REST-, GraphQL- vagy SOAP-kommunikáció;
- egyedi üzleti alkalmazások saját protokolljai.
Az „alkalmazásszintű tűzfal” tehát gyűjtőfogalom. Olyan biztonsági megoldást jelent, amely nem áll meg az IP-címek és portok ellenőrzésénél, hanem értelmezi vagy legalább részletesen elemzi az alkalmazási forgalmat.
Ez a gyakorlatban többféle terméket és technológiát takarhat. Ide sorolható egy webalkalmazás-tűzfal, egy alkalmazástudatos proxy, egy végponton futó programvezérlő tűzfal, illetve egy következő generációs hálózati tűzfal bizonyos funkciója is.
A fogalmak emiatt könnyen összekeverednek. Amikor valaki alkalmazásszintű tűzfalról beszél, érdemes tisztázni, hogy:
- webalkalmazásokat védő WAF-ra gondol;
- egy adott számítógépen futó programok hálózati hozzáférését szabályozza;
- proxyalapú alkalmazási átjárót használ;
- vagy egy NGFW alkalmazásfelismerő képességét nevezi így.
A közös pont minden esetben az, hogy a döntéshez az alkalmazásról vagy az alkalmazási adatokról is rendelkezésre áll információ.
Hogyan dolgozik a digitális kapuőr?
Egy alkalmazásszintű tűzfal jellemzően a kliens és a védett szolgáltatás közé kerül. A kliens lehet böngésző, mobilalkalmazás, másik szerver vagy automatizált program. A védett szolgáltatás pedig lehet webáruház, ügyfélportál, API, levelezőrendszer vagy belső üzleti alkalmazás.
A folyamat leegyszerűsítve így néz ki:
- A kliens elküld egy kérést.
- A kérés először a tűzfalhoz érkezik.
- A tűzfal feldolgozza a protokollt és megvizsgálja a tartalmat.
- A beállított szabályok, viselkedési modellek és fenyegetési információk alapján kockázati döntést hoz.
- A biztonságosnak ítélt kérést továbbítja az alkalmazásnak.
- A gyanús kérést naplózza, korlátozza, módosítja vagy blokkolja.
- Bizonyos rendszerek a válaszokat is ellenőrzik, mielőtt azok eljutnak a klienshez.
Egy webes kérésnél a tűzfal többek között megvizsgálhatja:
- a kért URL-t és útvonalat;
- a HTTP-metódust, például a GET, POST, PUT vagy DELETE műveletet;
- a fejlécmezőket;
- a sütiket;
- a lekérdezési paramétereket;
- az űrlapadatokat;
- a feltöltött fájl típusát és méretét;
- a JSON- vagy XML-törzs szerkezetét;
- a kérés gyakoriságát;
- a kliens viselkedését;
- a munkamenet állapotát;
- a válasz hibakódjait és esetleges adatszivárgását.
Egy egyszerű hálózati szabály azt mondhatja: „A 443-as porton érkező kapcsolat engedélyezett.” Egy alkalmazásszintű szabály már így szólhat: „A 443-as porton érkező HTTPS-kérés engedélyezett, de a /profil végponton csak GET és POST használható, a bemeneti mező legfeljebb 100 karakteres lehet, és nem tartalmazhat ismert támadási mintát.”
Ez sokkal pontosabb ellenőrzést tesz lehetővé.
Mit lát meg, amit egy egyszerű tűzfal nem?
Tegyük fel, hogy egy webáruház keresőmezőjébe valaki nem terméknevet ír, hanem egy adatbázis-parancsra emlékeztető karakterláncot. A kérés hálózati szempontból teljesen szabályos lehet:
- érvényes IP-címről érkezik;
- a megfelelő portot használja;
- szabályos TCP-kapcsolaton halad;
- HTTPS-protokollt alkalmaz;
- a weboldal valóban fogad keresési kéréseket.
A hagyományos tűzfal számára nincs feltétlenül látható probléma. Az alkalmazásszintű tűzfal viszont észreveheti, hogy a keresőmező tartalma egy SQL-injekciós próbálkozásra hasonlít.
Hasonló módon felismerhet vagy korlátozhat:
- cross-site scriptinget, amikor támadó szkriptet próbálnak elhelyezni egy oldalon;
- útvonal-bejárási kísérletet, amely tiltott fájlok elérésére irányul;
- parancsbefecskendezést, amely az operációs rendszernek szánt utasítást próbál átadni;
- rosszindulatú fájlfeltöltést;
- protokollszabályokat sértő kéréseket;
- automatizált jelszópróbálgatást;
- szokatlanul nagy vagy gyors kéréssorozatot;
- API-végpontokkal való visszaélést;
- ismert sérülékenységet célzó mintákat;
- érzékeny adatok kiszivárgását a válaszban.
Fontos azonban megérteni, hogy a tűzfal nem gondolatolvasó. A felismerés minősége a szabályoktól, a rendelkezésre álló kontextustól, a titkosított forgalom láthatóságától és az adott termék képességeitől függ.
Az alkalmazástűzfal nem attól hasznos, hogy minden támadást biztosan felismer, hanem attól, hogy egy újabb, az alkalmazás működéséhez közel elhelyezett védelmi réteget ad.
Két alapvető szemlélet: tiltólista és engedélyezési modell
Az alkalmazásszintű ellenőrzés két klasszikus megközelítésre épülhet.
Ismert rossz minták blokkolása
A negatív biztonsági modell azt keresi, ami veszélyesnek látszik. A rendszer támadási aláírásokat, szabályokat és ismert mintákat használ. Ha egy kérés hasonlít egy SQL-injekcióra, XSS-kísérletre vagy más ismert támadásra, a tűzfal blokkolhatja.
Ennek előnye, hogy viszonylag gyorsan bevezethető, és sok gyakori támadást képes felismerni. Hátránya, hogy az új, szokatlan vagy ügyesen álcázott módszerek átcsúszhatnak rajta.
Csak az elvárt működés engedélyezése
A pozitív biztonsági modell azt határozza meg, hogy milyen egy szabályos kérés. Például:
- mely végpontok léteznek;
- milyen metódus használható rajtuk;
- milyen mezők kötelezők;
- milyen adattípus fogadható el;
- mekkora lehet egy érték;
- milyen formátumú azonosító érvényes;
- milyen sorrendben történhetnek a műveletek.
Minden, ami eltér ettől, gyanúsnak minősülhet.
Ez szigorúbb és gyakran hatékonyabb, de több előkészítést és folyamatos karbantartást igényel. Ha az alkalmazás megváltozik, a tűzfal szabályait is hozzá kell igazítani.
A korszerű rendszerek általában kombinálják a két megközelítést, és viselkedéselemzést, gépi tanulást vagy fenyegetési hírszerzést is alkalmazhatnak. A „mesterséges intelligencia” felirat azonban önmagában nem garancia a jó védelemre. A pontos konfiguráció, a megfelelő naplózás és az emberi felügyelet továbbra is alapvető.
A WAF azonos az alkalmazásszintű tűzfallal?
A WAF, vagyis Web Application Firewall webalkalmazások és webes API-k HTTP-, illetve HTTPS-forgalmának védelmére szakosodott alkalmazásszintű tűzfal. A két fogalom tehát szorosan kapcsolódik, de nem teljesen azonos.
Minden WAF alkalmazásszintű biztonsági megoldás, de nem minden alkalmazásszintű tűzfal WAF. Egy levelezési protokollt ellenőrző alkalmazási átjáró vagy egy számítógépen futó programok kapcsolatait szabályozó tűzfal például nem feltétlenül nevezhető webalkalmazás-tűzfalnak.
A WAF tipikusan az alábbiakat védi:
- nyilvános weboldalakat;
- webáruházakat;
- internetbanki felületeket;
- ügyfélportálokat;
- tartalomkezelő rendszereket;
- mobilalkalmazások háttér-API-jait;
- REST- és GraphQL-API-kat;
- felhőben futó webszolgáltatásokat.
A WAF elhelyezhető saját infrastruktúrában, virtuális gépen, konténeres környezetben, felhőszolgáltatásként vagy tartalomszolgáltató hálózat részeként. Léteznek az alkalmazásba vagy annak közvetlen környezetébe épülő megoldások is.
Nem ugyanaz: hálózati tűzfal, NGFW, proxy és végpontvédelem
A biztonsági termékek elnevezései gyakran átfedik egymást. A tisztánlátáshoz érdemes különválasztani a legfontosabb kategóriákat.
Hagyományos hálózati tűzfal
Elsősorban IP-címek, portok, protokollok és kapcsolati állapotok alapján dönt. Kiválóan alkalmas hálózati szegmensek elválasztására és a szükségtelen szolgáltatások lezárására.
Erőssége: gyors, alapvető hálózati hozzáférés-szabályozás.
Korlátja: önmagában kevés információval rendelkezhet a webes kérés tartalmáról és üzleti jelentéséről.
Következő generációs tűzfal, vagyis NGFW
A hagyományos funkciókat alkalmazásfelismeréssel, behatolásmegelőzéssel, felhasználóazonosítással, URL-szűréssel és esetenként titkosított forgalom vizsgálatával egészíti ki.
Erőssége: széles körű hálózati kontroll és több biztonsági funkció egy rendszerben.
Korlátja: nem feltétlenül ismeri olyan részletesen egy konkrét webalkalmazás végpontjait, paramétereit és üzleti folyamatait, mint egy jól beállított WAF.
Proxy
A proxy közvetítőként működik a kliens és a célrendszer között. Lehet előre irányuló proxy, amely a felhasználók kimenő forgalmát kezeli, vagy fordított proxy, amely a szerverek előtt fogadja a bejövő kéréseket.
A proxy önmagában nem feltétlenül biztonsági tűzfal, de kiváló helyet biztosít az ellenőrzéshez. Sok WAF fordított proxyként működik.
Végponti alkalmazástűzfal
A felhasználó számítógépén vagy szerverén fut, és azt szabályozza, hogy mely programok kezdeményezhetnek vagy fogadhatnak hálózati kapcsolatot. Például engedélyezheti a böngésző internetelérését, miközben blokkol egy ismeretlen programot.
Erőssége: közvetlenül a végponton képes programonként dönteni.
Korlátja: nem helyettesíti a nyilvános webalkalmazás elé telepített WAF-ot.
Végpontészlelés és -reagálás
Az EDR a végpontokon zajló folyamatokat, fájlműveleteket, memóriatevékenységet és viselkedést figyeli. Más problémát old meg, mint egy WAF.
A jó védelem nem egyetlen „mindent tudó” termékre épül. A hálózati tűzfal, a WAF, az EDR, az erős hitelesítés és a biztonságos fejlesztés egymást kiegészítő rétegek.
Milyen támadások ellen lehet igazán hasznos?
Az alkalmazásszintű tűzfalak különösen ott értékesek, ahol a szolgáltatásnak nyilvánosan elérhetőnek kell lennie, ezért a hálózati kapcsolatot nem lehet egyszerűen letiltani.
Befecskendezéses támadások
A támadó úgy alakítja a bemenetet, hogy azt az alkalmazás vagy egy háttérrendszer parancsként értelmezze. Ide tartozhat az SQL-, operációsrendszer- vagy sablonbefecskendezés.
A tűzfal ismert minták, kódolási trükkök és rendellenes paraméterek alapján észlelheti a próbálkozást. Ez azonban nem mentesíti a fejlesztőket a paraméterezett lekérdezések és a megfelelő bemenetkezelés használata alól.
Cross-site scripting
XSS esetén rosszindulatú kliensoldali kód kerülhet egy weboldalba. A WAF felismerhet bizonyos szkriptrészleteket és veszélyes HTML-szerkezeteket.
A végleges megoldás itt is az alkalmazás javítása: megfelelő kimeneti kódolás, tartalombiztonsági szabályzat és biztonságos sablonkezelés szükséges.
Automatizált bejelentkezési támadások
A támadók kiszivárgott jelszavakat próbálhatnak ki nagy mennyiségben, vagy egyetlen fiók ellen indíthatnak jelszótalálgatást. Az alkalmazástűzfal sebességkorlátozással, botfelismeréssel, IP- és eszközértékeléssel csökkentheti a kockázatot.
A többtényezős hitelesítés ettől még nélkülözhetetlen marad.
Rosszindulatú botok
Nem minden bot káros. A keresőmotorok feltérképező programjai például hasznosak lehetnek. Más automatizmusok viszont árakat gyűjtenek, készletet foglalnak le, hamis fiókokat hoznak létre vagy túlterhelik a szolgáltatást.
A fejlettebb rendszerek a böngésző viselkedését, a kérések ritmusát, az ujjlenyomatokat és más jeleket is elemezhetnek.
Fájlfeltöltéssel való visszaélés
Egy profilképnek álcázott futtatható állomány vagy túlméretezett fájl veszélyt jelenthet. A tűzfal ellenőrizheti a kiterjesztést, a MIME-típust, a méretet és bizonyos esetekben a tartalmat is.
API-k elleni támadások
Az API-k gyakran közvetlen hozzáférést biztosítanak üzleti funkciókhoz és adatokhoz. Egy API-védelmi megoldás ellenőrizheti a sémát, a tokeneket, a metódusokat, a paramétereket és a használati sebességet.
Az üzleti jogosultsági hibákat azonban nehezebb felismerni. Ha egy hitelesített felhasználó más ügyfél adatait is lekérheti egy azonosító átírásával, a tűzfal csak akkor tud megbízhatóan közbelépni, ha elegendő kontextust kap a jogosultsági modellről.
Amit egy alkalmazástűzfal sem tud varázsütésre megoldani
A marketinganyagok néha azt sugallják, hogy egy WAF telepítésével az alkalmazás biztonságossá válik. Ez veszélyes félreértés.
Az alkalmazástűzfal nem helyettesíti:
- a biztonságos programozást;
- a rendszeres frissítést;
- a sérülékenységvizsgálatot;
- a behatolási tesztet;
- a hozzáférések megfelelő kezelését;
- a többtényezős hitelesítést;
- a titkok és kulcsok biztonságos tárolását;
- a naplók felügyeletét;
- a biztonsági mentést;
- az incidenskezelési tervet.
Különösen nehéz lehet felismernie az üzleti logikával való visszaélést. Tegyük fel, hogy egy webáruház szabályosan enged napi egy kedvezménykupont felhasználónként. Ha egy támadó több ezer hamis fiókot hoz létre, minden egyes kérés technikailag szabályosnak tűnhet. A probléma megértéséhez üzleti összefüggésekre és több rendszerből származó adatokra van szükség.
A titkosítás szintén kihívást jelent. HTTPS esetén a forgalom tartalma titkosított. A WAF általában azért tudja megvizsgálni, mert nála vagy előtte történik a TLS-kapcsolat lezárása. Ha a rendszer nem fér hozzá a visszafejtett tartalomhoz, csak korlátozott ellenőrzést végezhet.
A hamis pozitív találatok is gondot okozhatnak. Egy biztonságos kérés néha támadásnak látszik. Például egy programozási fórumon teljesen jogos lehet SQL-kódrészletet beküldeni. Egy túl szigorú szabály ezt blokkolhatja.
A másik véglet a hamis negatív eredmény: a támadás átjut, mert nem illeszkedik az ismert mintákhoz, vagy megfelelően álcázták.
A WAF biztonsági háló, nem pedig a hibás alkalmazáskód felmentése. A sérülékenységet akkor is ki kell javítani, ha egy ideiglenes szabály már blokkolja a kihasználását.
Mi történik a titkosított HTTPS-forgalommal?
A mai webforgalom jelentős része titkosított, ami adatvédelmi szempontból jó hír. Az ellenőrzéshez azonban a biztonsági rendszernek látnia kell a kérés értelmezhető tartalmát.
Fordított proxyként működő WAF esetén a böngésző titkosított kapcsolatot hoz létre a WAF-fal. A WAF visszafejti és ellenőrzi a kérést, majd rendszerint újabb titkosított kapcsolatot létesít a háttérszerverrel. Ezt gyakran TLS-lezárásnak vagy TLS-áthidalásnak nevezik.
Ez több felelősséggel jár:
- a tanúsítványokat biztonságosan kell kezelni;
- a privát kulcsokat védeni kell;
- korszerű TLS-beállításokat kell használni;
- a háttérkapcsolatot is célszerű titkosítani;
- figyelni kell a tanúsítványok lejáratára;
- a naplókba nem kerülhetnek szükségtelenül érzékeny adatok.
A visszafejtés teljesítményigényes lehet, bár a modern hardverek és felhőszolgáltatások ezt általában jól kezelik. Nagy forgalomnál azonban a kapacitástervezés elengedhetetlen.
Hol helyezhető el a védelem?
Az alkalmazásszintű tűzfal telepítési módja meghatározza a láthatóságot, a késleltetést, az üzemeltetési terhet és a meghibásodás következményeit.
Helyben telepített eszköz
A szervezet saját adatközpontjában fizikai vagy virtuális berendezésként működik. Nagy kontrollt ad, de a kapacitásról, frissítésről, rendelkezésre állásról és tartalék rendszerről a szervezetnek kell gondoskodnia.
Felhőalapú WAF-szolgáltatás
A forgalom egy szolgáltató infrastruktúráján halad át. Gyorsan skálázható, és gyakran DDoS-védelemmel, botkezeléssel vagy tartalomszolgáltatással együtt érhető el.
A szervezetnek ugyanakkor meg kell vizsgálnia az adatkezelést, a régiókat, a naplómegőrzést, a szolgáltatói függőséget és a kiesési forgatókönyveket.
Felhőplatformba épített védelem
A nagy felhőplatformok saját terheléselosztóikhoz, átjáróikhoz és tartalomszolgáltató rendszereikhez kapcsolható WAF-funkciókat kínálnak. Ezek jól illeszkedhetnek a platform többi szolgáltatásához, de a szabályok és képességek szolgáltatónként eltérnek.
Alkalmazáshoz közeli vagy beágyazott megoldás
Konténer, oldalkocsi-komponens, ügynök vagy könyvtár formájában az alkalmazás közelében működik. Több alkalmazási kontextust kaphat, viszont szorosabb integrációt és fejlesztői együttműködést igényel.
Nincs minden helyzetre tökéletes telepítési modell. A döntést a rendszer felépítése, a forgalom, a megfelelőségi követelmények, a csapat tudása és a rendelkezésre állási célok alapján kell meghozni.
Az alkalmazástűzfal legfontosabb előnyei
A megfelelően beállított megoldás több területen is értéket teremthet.
Mélyebb forgalmi ellenőrzést biztosít. Nemcsak a kapcsolat technikai adatait, hanem az alkalmazási kérések szerkezetét is elemzi.
Gyors virtuális javítást tesz lehetővé. Ha egy sérülékenységhez még nincs telepíthető programjavítás, ideiglenes szabállyal csökkenthető a kihasználás esélye. Ezt virtuális foltozásnak nevezik.
Központi védelmi pontot ad. Több alkalmazás forgalma egységes szabályokkal és naplózással kezelhető.
Javítja a láthatóságot. A naplók megmutathatják, mely végpontokat támadják, milyen módszereket használnak, és honnan érkezik szokatlan forgalom.
Segíthet a botok és túlzott használat korlátozásában. A sebességkorlátozás és viselkedéselemzés csökkentheti az automatizált visszaéléseket.
Támogathat megfelelőségi célokat. Bizonyos szabványok és iparági elvárások megkövetelhetnek vagy ösztönözhetnek alkalmazásszintű védelmi kontrollokat. A megfelelőség azonban nem azonos a tényleges biztonsággal.
Csökkentheti a háttérrendszer közvetlen kitettségét. Fordított proxyként elrejtheti az eredeti szerver címét, és csak ellenőrzött forgalmat továbbíthat.
Az árnyoldalakról is beszélni kell
A technológia előnyei mellett valós költségekkel és kockázatokkal jár.
Teljesítmény és késleltetés
Minden ellenőrzés időt vesz igénybe. Egy jól méretezett rendszer késleltetése alacsony lehet, de összetett szabályok, fájlelemzés vagy nagy forgalom mellett érezhetővé válhat.
Hibás blokkolás
A túl szigorú szabályok valódi felhasználókat akadályozhatnak. Egy webáruháznál ez közvetlen bevételkiesést okozhat.
Folyamatos hangolási igény
Az alkalmazások változnak. Új végpontok, mezők és funkciók jelennek meg. A tűzfal szabályainak követniük kell ezeket, különben vagy túl sok mindent blokkolnak, vagy túl engedékennyé válnak.
Egyetlen hibapont kialakulása
Ha minden forgalom a WAF-on halad át, annak kiesése az alkalmazást is elérhetetlenné teheti. Magas rendelkezésre állású kialakításra és tesztelt kerülő eljárásra van szükség.
Adatvédelmi kockázat
A rendszer érzékeny adatokat láthat: munkamenet-azonosítókat, személyes adatokat vagy hitelesítési információkat. A naplózást maszkolással, hozzáférés-szabályozással és megfelelő megőrzési idővel kell kialakítani.
Hamis biztonságérzet
Talán ez a legnagyobb veszély. Ha a szervezet a WAF miatt elhanyagolja a kódjavítást és a biztonsági tesztelést, hosszú távon nőhet a kockázat.
Hogyan válasszunk megfelelő megoldást?
A terméklista összeállítása előtt érdemes pontosan meghatározni a védendő környezetet. Más megoldás kell egy kis bemutatkozó oldalhoz, egy nagy webáruházhoz és egy több száz API-t működtető pénzügyi rendszerhez.
A felmérés során válaszoljuk meg a következőket:
- Hány alkalmazást és domaint kell védeni?
- Mekkora az átlagos és a csúcsforgalom?
- Weboldalról, API-ról vagy mindkettőről van szó?
- Hol futnak a rendszerek?
- Milyen érzékeny adatokat kezelnek?
- Mekkora kiesés fogadható el?
- Szükséges-e botvédelem vagy DDoS-csillapítás?
- Milyen naplókezelő és riasztási rendszer működik?
- Van-e csapat a szabályok hangolására?
- Milyen adatrezidencia- és megfelelőségi követelmények vannak?
- Hogyan automatizálható a konfiguráció?
- Milyen gyorsan lehet visszaállítani egy hibás szabályt?
A próba során ne csak azt nézzük, hány támadási aláírást ígér a gyártó. Fontosabb kérdés, hogy a rendszer mennyire átláthatóan magyarázza el a döntéseit, milyen könnyen tesztelhető, és mennyire illeszthető a fejlesztési folyamatba.
A jó alkalmazástűzfal nemcsak blokkol, hanem használható információt is ad arról, hogy mit, miért és milyen szabály alapján állított meg.
Bevezetés lépésről lépésre, felesleges kapkodás nélkül
Egy WAF-ot nem célszerű péntek délután teljes blokkoló módban bekapcsolni. A biztonságos bevezetés fokozatos.
1. Készítsünk alkalmazásleltárt
Azonosítsuk a domaineket, aldomainokat, API-kat, háttérszervereket, tanúsítványokat és tulajdonos csapatokat. Az ismeretlen vagy elfelejtett szolgáltatásokat nem lehet megfelelően védeni.
2. Rajzoljuk fel az adatáramlást
Tudni kell, honnan érkezik a forgalom, hol történik a TLS-lezárás, milyen terheléselosztók működnek, és mely rendszereknek kell látniuk az eredeti klienscímet.
3. Először megfigyelő módban induljunk
A rendszer naplózza, mit blokkolna, de még nem szakítja meg a kéréseket. Így felmérhető a hamis pozitív találatok mennyisége.
A megfigyelési időszaknak le kell fednie a normál üzleti ciklusokat. Egyetlen csendes nap nem feltétlenül mutatja meg a havi zárás, kampány vagy nagyobb forgalmi esemény sajátosságait.
4. Állítsunk fel alapvédelmet
Kapcsoljuk be a jól ismert, magas megbízhatóságú szabályokat. Korlátozzuk a szükségtelen HTTP-metódusokat, a túl nagy kéréseket és a nyilvánvaló protokollsértéseket.
5. Hangoljuk alkalmazásonként
Egy központi szabálykészlet jó kiindulópont, de az alkalmazások eltérnek. A kivételeket szűken, konkrét végpontra és paraméterre érdemes megadni.
Rossz kivétel: „Kapcsoljuk ki az SQL-injekció elleni szabályt az egész webhelyen.”
Jobb kivétel: „Ennél az egy végpontnál, ebben az egy mezőben módosítsuk a szabály érzékenységét, mert dokumentáltan kódrészleteket fogad.”
6. Fokozatosan vezessük be a blokkolást
Először a nagy bizonyosságú eseményeket blokkoljuk. Figyeljük az ügyfélszolgálati jelzéseket, az üzleti mutatókat és a hibaarányt.
7. Kössük össze a riasztási rendszerrel
A fontos események kerüljenek központi naplókezelő vagy SIEM-rendszerbe. A riasztás tartalmazzon elegendő kontextust a kivizsgáláshoz, de ne szivárogtasson érzékeny adatot.
8. Dokumentáljuk a visszaállítást
Minden szabálymódosításhoz legyen gyors visszavonási lehetőség. A konfigurációt verziókezelésben, jóváhagyási folyamattal célszerű kezelni.
9. Teszteljük a kiesési helyzeteket
Mi történik, ha a WAF nem elérhető? A rendszer biztonságosan leáll, vagy ellenőrzés nélkül továbbengedi a forgalmat? A választ tudatos kockázati döntésként kell meghozni.
A szabályok hangolása: itt dől el a valódi érték
A gyári szabálykészlet önmagában ritkán tökéletes. A túl érzékeny rendszer sok téves riasztást ad, a túl laza pedig nem nyújt elegendő védelmet.
A hangolás során minden eseménynél érdemes megvizsgálni:
- melyik alkalmazást és végpontot érintette;
- melyik szabály aktiválódott;
- mi volt a kérés releváns része;
- valódi támadás vagy szabályos használat történt-e;
- milyen üzleti hatása lenne a blokkolásnak;
- szükséges-e kivétel;
- mennyire szűken adható meg a kivétel;
- javítható-e inkább maga az alkalmazás.
A szabályokhoz legyen tulajdonos, indoklás és felülvizsgálati dátum. Az ideiglenes kivételek hajlamosak örökre a rendszerben maradni, ha senki nem felel értük.
A kivétel nem lehet kényelmi kapcsoló. Minden kivétel egy tudatosan megnyitott rés, ezért legyen szűk, dokumentált és időben korlátozott.
A változtatásokat lehetőség szerint tesztkörnyezetben kell kipróbálni. Automatizált tesztek ellenőrizhetik, hogy a szabályos felhasználói folyamatok továbbra is működnek, miközben az ismert támadási minták blokkolódnak.
Naplózás: sok adat helyett használható információ
Egy forgalmas alkalmazás tűzfala hatalmas mennyiségű naplót termelhet. Ha minden esemény ugyanolyan sürgősnek látszik, az üzemeltetők hamar érzéketlenné válnak a riasztásokra.
Egy hasznos eseményrekord tartalmazhatja:
- az időpontot;
- az alkalmazás és a végpont azonosítóját;
- a kérés egyedi azonosítóját;
- a kliens címét vagy adatvédelmi szempontból megfelelően kezelt azonosítóját;
- a HTTP-metódust;
- a válaszkódot;
- az aktiválódott szabályt;
- a kockázati besorolást;
- a végrehajtott műveletet;
- a kérés méretét és időtartamát;
- a kapcsolódó munkamenet vagy felhasználó maszkolt azonosítóját.
Jelszavakat, teljes hitelesítési tokeneket, bankkártyaadatokat és más érzékeny értékeket nem szabad indokolatlanul naplózni. A napló maga is értékes célpont, ezért titkosításra, hozzáférés-szabályozásra és megőrzési szabályokra van szükség.
A riasztásokat prioritás szerint érdemes kezelni. Egyetlen alacsony kockázatú szabálysértés nem feltétlenül sürgős. Ugyanaz a minta több ezer kérésben, több fiók ellen vagy egy kritikus adminisztrációs végponton már komoly incidens lehet.
Hogyan tesztelhető, hogy valóban működik?
A „bekapcsolt” állapot nem bizonyítja a hatékonyságot. A védelmet rendszeresen ellenőrizni kell.
Funkcionális tesztelés
Meg kell győződni arról, hogy a normál felhasználói folyamatok működnek:
- regisztráció;
- bejelentkezés;
- keresés;
- vásárlás;
- fájlfeltöltés;
- API-hívások;
- jelszó-visszaállítás;
- adminisztrációs műveletek.
Negatív biztonsági tesztelés
Ellenőrzött környezetben ismert támadási mintákkal vizsgálható, hogy a rendszer észlel-e és blokkol-e. Ezt csak engedéllyel, meghatározott hatókörben szabad végezni.
Terheléses vizsgálat
Mérni kell, hogyan változik a válaszidő és a hibaarány nagy forgalomnál. A WAF nem válhat szűk keresztmetszetté.
Hibakezelési próba
Tesztelni kell a tanúsítványhibát, a háttérszerver kiesését, a WAF-csomópont meghibásodását és a hibás konfiguráció visszaállítását.
Független biztonsági felülvizsgálat
A behatolási teszt és a kódvizsgálat olyan problémákat is feltárhat, amelyeket a tűzfal nem lát. A teszt célja nem pusztán a WAF megkerülése, hanem a teljes alkalmazási kockázat megértése.
API-védelem: ugyanaz az alapelv, más hangsúlyok
A modern alkalmazások egyre több funkciót API-kon keresztül biztosítanak. Ezeket mobilalkalmazások, partnerek, belső szolgáltatások és automatizált rendszerek használják.
Az API-k esetében különösen fontos:
- a végpontok pontos leltára;
- az OpenAPI- vagy más séma használata;
- a metódusok korlátozása;
- a JSON- és XML-struktúrák ellenőrzése;
- a hitelesítési tokenek helyes kezelése;
- a sebesség- és kvótakorlátozás;
- az objektumszintű jogosultságok ellenőrzése;
- a túl sok adatot visszaadó válaszok felismerése;
- a régi API-verziók kivezetése.
Egy sémaalapú védelem például tudhatja, hogy az age mező egész szám, a country kétbetűs kód, a userId pedig meghatározott formátumú azonosító. Az ettől eltérő kérés blokkolható még azelőtt, hogy elérné az alkalmazást.
Az API-biztonság egyik legnehezebb része mégis a jogosultság. Attól, hogy egy kérés formailag helyes és hitelesített, még nem biztos, hogy az adott felhasználó jogosult a kért objektum elérésére. Ezt elsősorban az alkalmazásnak kell helyesen ellenőriznie.
Gyakorlati példa: egy webáruház védelme
Képzeljünk el egy webáruházat, amely termékkeresőt, ügyfélfiókokat, kosarat, fizetési folyamatot és adminisztrációs felületet működtet.
A hálózati tűzfal csak a szükséges webes portokat engedi be. A WAF ezután részletesebb szabályokat alkalmazhat:
- a keresőmező hosszát korlátozza;
- ismert befecskendezési mintákat szűr;
- a bejelentkezési próbálkozások számát korlátozza;
- botgyanús viselkedésnél további ellenőrzést kér;
- a fájlfeltöltésnél csak meghatározott típusokat enged;
- az adminisztrációs útvonalat külön szabályokkal védi;
- az API-kéréseket séma alapján ellenőrzi;
- a szokatlanul nagy kosármódosítási forgalmat jelzi;
- a háttérszerver részletes hibaüzeneteit kiszűrheti a válaszból.
Ettől a webáruház még nem lesz automatikusan biztonságos. Ha a fizetési folyamatban logikai hiba van, vagy az adminisztrátor gyenge jelszót használ, más kontrollokra is szükség lesz. A WAF azonban több gyakori támadást megállíthat, és értékes láthatóságot adhat.
Gyakori bevezetési hibák, amelyek könnyen elkerülhetők
Minden szabály azonnali blokkoló módba kapcsolása
Ez váratlan szolgáltatáskiesést okozhat. Előbb megfigyelés, majd hangolás és fokozatos blokkolás szükséges.
Túl széles kivételek létrehozása
Egyetlen problémás mező miatt nem szabad egy teljes alkalmazás védelmét kikapcsolni.
A fejlesztők kihagyása
Az üzemeltető látja a forgalmat, a fejlesztő pedig érti az alkalmazás működését. A jó szabályokhoz mindkét tudás kell.
A naplók figyelmen kívül hagyása
A nem felügyelt tűzfal idővel elavult szabályok gyűjteményévé válhat. A riasztásokat és trendeket rendszeresen át kell tekinteni.
A háttérszerver nyitva hagyása
Ha a támadó közvetlenül eléri az eredeti szervert, megkerülheti a felhőalapú WAF-ot. A háttérrendszernek lehetőség szerint csak a megbízható közvetítőktől kell forgalmat fogadnia.
A WAF javításként való kezelése
A virtuális folt átmeneti kockázatcsökkentés. A sérülékeny kódot továbbra is javítani kell.
Csak az alapértelmezett szabályokra hagyatkozás
A gyári szabályok nem ismerik automatikusan az egyedi üzleti folyamatokat, végpontokat és adattípusokat.
Karbantartás: a védelem nem egyszeri projekt
Az alkalmazástűzfal életciklusa együtt mozog az alkalmazással. Minden jelentősebb kiadás előtt meg kell vizsgálni, hogy változnak-e:
- az URL-ek és API-végpontok;
- a paraméterek;
- a fájlfeltöltési funkciók;
- a hitelesítési folyamatok;
- a külső integrációk;
- a válaszformátumok;
- a forgalmi minták;
- a tanúsítványok;
- a megfelelőségi követelmények.
A szabálykészleteket és a motorokat frissíteni kell, mert új támadási módszerek és sérülékenységek jelennek meg. A frissítést azonban tesztelni kell: egy új aláírás váratlan blokkolást okozhat.
Érdemes rendszeresen felülvizsgálni:
- a régi kivételeket;
- a már nem használt domaineket;
- a lejáró tanúsítványokat;
- a riasztási küszöböket;
- a naplómegőrzést;
- a felhasználói jogosultságokat;
- a vészhelyzeti eljárásokat;
- a kapacitást és a költségeket.
A konfigurációt kódként kezelő megközelítés sokat segíthet. A szabályok verziózhatók, ellenőrizhetők, automatizáltan tesztelhetők és következetesen telepíthetők több környezetben.
Rövid ellenőrzőlista döntéshozóknak és üzemeltetőknek
Egy alkalmazásszintű tűzfal bevezetése előtt és után ellenőrizzük a következőket:
- Ismerjük a védendő alkalmazásokat és API-kat.
- Dokumentáltuk az adatáramlást és a TLS-kezelést.
- A háttérszerver nem kerülhető meg egyszerűen.
- A rendszer magas rendelkezésre állású.
- Megfigyelő módban felmértük a normál forgalmat.
- A blokkolást fokozatosan vezettük be.
- A kivételek szűkek, indokoltak és időkorlátosak.
- A naplók nem tárolnak szükségtelen érzékeny adatot.
- A fontos eseményekhez riasztás és felelős tartozik.
- A fejlesztők részt vesznek a hangolásban.
- A sérülékenységeket a forráskódban is javítjuk.
- Rendszeresen végzünk funkcionális és biztonsági teszteket.
- Van dokumentált visszaállítási és kiesési terv.
- A szabályokat minden jelentős alkalmazásváltozásnál felülvizsgáljuk.
- Mérjük a késleltetést, a hibaarányt és a hamis riasztásokat.
Milyen mérőszámok mutatják meg, hogy hasznos-e?
A blokkolt kérések nagy száma önmagában nem bizonyít sikeres védelmet. Lehet, hogy ugyanaz az egyszerű bot ismétel egy ártalmatlan próbálkozást, miközben egy fontos támadás észrevétlen marad.
Hasznosabb mutatók lehetnek:
- a megerősített támadások száma és súlyossága;
- a hamis pozitív találatok aránya;
- a szabálymódosítások utáni hibaarány;
- a kivizsgáláshoz szükséges átlagos idő;
- a kritikus riasztásokra adott reakcióidő;
- a WAF által hozzáadott késleltetés;
- a rendelkezésre állás;
- a lejárt, indokolatlan kivételek száma;
- a virtuális folt és a valódi kódjavítás között eltelt idő;
- az ismeretlen vagy nem dokumentált API-végpontok száma.
A mérőszámokat üzleti összefüggésben kell értelmezni. Egy blokkolt támadás értéke nagyobb lehet egy fizetési vagy adminisztrációs végponton, mint egy nyilvános, statikus oldalon.
Kinek van rá szüksége?
Nem minden rendszer igényel ugyanolyan összetett védelmet. Egy kizárólag statikus tartalmat megjelenítő kis oldal kockázata más, mint egy egészségügyi adatokat kezelő portálé.
Különösen indokolt lehet alkalmazásszintű tűzfal használata, ha:
- az alkalmazás nyilvánosan elérhető;
- személyes, pénzügyi vagy üzleti adatokat kezel;
- bejelentkezési felületet biztosít;
- fájlfeltöltést enged;
- API-kat tesz közzé;
- gyakori támadási célpont;
- régi, nehezen javítható rendszert kell átmenetileg védeni;
- megfelelőségi követelmények vonatkoznak rá;
- nagy forgalmi csúcsokat és bottevékenységet tapasztal;
- gyorsan változó felhős környezetben működik.
Kisebb szervezetek számára a menedzselt felhőszolgáltatás egyszerűbb lehet, mint saját eszköz üzemeltetése. Ettől még szükség van valakire, aki érti a riasztásokat, jóváhagyja a szabályokat és kapcsolatot tart a fejlesztőkkel.
A lényeg egyetlen képben
A hagyományos tűzfal azt kérdezi:
„Engedélyezett ez a hálózati kapcsolat?”
Az alkalmazásszintű tűzfal ennél tovább megy:
„Érvényes és életszerű az, amit ezen a kapcsolaton keresztül az alkalmazástól kérnek?”
Ez a mélyebb ellenőrzés teszi alkalmassá arra, hogy weboldalakat, API-kat és más alkalmazási szolgáltatásokat védjen. Nem tévedhetetlen, nem helyettesíti a biztonságos fejlesztést, és folyamatos gondozást igényel. Jól beállítva azonban értékes védelmi réteg: csökkenti a gyakori támadások kockázatát, időt adhat a javítások telepítésére, és részletesebb képet nyújt az alkalmazást érő fenyegetésekről.
A legjobb eredményt nem a legtöbb bekapcsolt szabály adja, hanem az alkalmazáshoz igazított, tesztelt, felügyelt és rendszeresen karbantartott védelem.
Gyakori kérdések és válaszok
🔥 Mi az az alkalmazásszintű tűzfal?
Az alkalmazásszintű tűzfal olyan biztonsági rendszer, amely az IP-címek és portok mellett az alkalmazási forgalom tartalmát, szerkezetét és viselkedését is elemzi. Felismerheti például, ha egy szabályos HTTPS-kérésbe támadási kódot rejtettek.
🌐 Ugyanaz a WAF és az alkalmazásszintű tűzfal?
Nem teljesen. A WAF az alkalmazásszintű tűzfalak egyik típusa, amely kifejezetten webalkalmazások és webes API-k HTTP-, illetve HTTPS-forgalmát védi. Az alkalmazásszintű tűzfal tágabb fogalom, más protokollokra és végponti programvezérlésre is vonatkozhat.
🛡️ Kiválthatja a WAF a hagyományos hálózati tűzfalat?
Nem. A két rendszer eltérő rétegeket és kockázatokat kezel. A hálózati tűzfal a kapcsolatok és hálózati szegmensek szabályozásában erős, míg a WAF a webes kérések részletes vizsgálatára szakosodott. Együtt hatékonyabbak.
🔐 Hogyan vizsgálja meg a titkosított HTTPS-forgalmat?
A WAF gyakran maga zárja le a klienssel létrehozott TLS-kapcsolatot, így hozzáfér a visszafejtett kéréshez. Az ellenőrzés után új, lehetőleg szintén titkosított kapcsolatot hoz létre a háttérszerverrel. Emiatt a tanúsítványok és privát kulcsok védelme kiemelten fontos.
🧩 Megvéd minden SQL-injekciótól és XSS-től?
Nem garantáltan. Sok ismert és tipikus támadást felismerhet, de az új, álcázott vagy alkalmazásspecifikus módszerek átjuthatnak. A sérülékenységet a programkódban is ki kell javítani, a WAF pedig kiegészítő védelmi rétegként szolgál.
⚠️ Mi az a hamis pozitív találat?
Olyan esemény, amikor a tűzfal egy szabályos kérést tévesen támadásnak minősít. Ez valódi felhasználókat akadályozhat, ezért fontos a megfigyelő mód, a fokozatos bevezetés és a szabályok rendszeres hangolása.
🩹 Mit jelent a virtuális foltozás?
A virtuális foltozás olyan ideiglenes tűzfalszabály, amely egy ismert sérülékenység kihasználását próbálja blokkolni anélkül, hogy az alkalmazás kódja már megváltozott volna. Gyors kockázatcsökkentést adhat, de nem helyettesíti a valódi javítást.
☁️ Jobb a felhőalapú vagy a saját WAF?
Ez a környezettől függ. A felhőalapú szolgáltatás gyorsan skálázható és kevesebb infrastruktúra-üzemeltetést igényelhet. A saját megoldás nagyobb közvetlen kontrollt adhat, de több szakértelmet, kapacitástervezést és karbantartást követel. A döntésnél az adatkezelést, rendelkezésre állást, költséget és integrációt együtt kell vizsgálni.
🧑💻 Egy kisebb weboldalnak is szüksége van rá?
Nem minden kis oldalhoz kell összetett vállalati WAF, de egy bejelentkezést, űrlapot, webáruházat, fájlfeltöltést vagy személyes adatokat kezelő oldalnál már komoly értéket adhat. A védelem szintjét mindig az adatok érzékenységéhez, a támadási felülethez és az üzleti kockázathoz kell igazítani.