Korábbi felhő témájú anyagunkban mi , hogyan védhetjük meg az informatikai erőforrásokat a nyilvános felhőben, és miért nem teljesen alkalmasak a hagyományos vírusirtók ezekre a célokra. Ebben a bejegyzésben folytatjuk a felhőbiztonság témáját, és beszélünk a WAF fejlődéséről, és arról, hogy mit érdemes választani: hardvert, szoftvert vagy felhőt.
Mi az a WAF
A hackertámadások több mint 75%-a webalkalmazások és webhelyek sebezhetőségére irányul: az ilyen támadások általában láthatatlanok az információbiztonsági infrastruktúra és az információbiztonsági szolgáltatások számára. A webalkalmazások biztonsági rései viszont a felhasználói fiókok, valamint a személyes adatok, jelszavak és hitelkártyaszámok kompromittálásának és csalásnak a kockázatát hordozzák magukban. Ezenkívül a webhelyek sebezhetőségei belépési pontként szolgálnak a támadók számára a vállalati hálózatba.
A webalkalmazások tűzfala (WAF) egy védőképernyő, amely blokkolja a webalkalmazások elleni támadásokat: SQL-befecskendezés, helyek közötti szkriptelés, távoli kódfuttatás, nyers erő és engedélyezési megkerülés. Ideértve a nulladik napi sebezhetőséget kihasználó támadásokat is. Az alkalmazástűzfalak védelmet nyújtanak a weboldal tartalmának, beleértve a HTML-t, a DHTML-t és a CSS-t, figyelésével, valamint a potenciálisan rosszindulatú HTTP/HTTPS-kérések kiszűrésével.
Mik voltak az első döntések?
Az első kísérletek webalkalmazási tűzfal létrehozására a 90-es évek elején történtek. Ismeretes, hogy legalább három mérnök dolgozott ezen a területen. Az első a számítástechnika professzora, Gene Spafford a Purdue Egyetemről. Leírta a proxyalkalmazások tűzfalának architektúráját, és 1991-ben publikálta a könyvben .
A második és a harmadik a Bell Labs információbiztonsági szakértője, William Cheswick és Marcus Ranum. Kifejlesztették az egyik első alkalmazási tűzfal prototípust. A DEC forgalmazója – a termék SEAL (Secure External Access Link) néven jelent meg.
A SEAL azonban nem volt teljes értékű WAF-megoldás. Klasszikus hálózati tűzfal volt fejlett funkciókkal – az FTP és RSH elleni támadások blokkolására. Emiatt az első WAF-megoldást ma a Perfecto Technologies (később Sanctum) termékének tekintik. 1999-ben ő AppShield rendszer. A Perfecto Technologies akkoriban az e-kereskedelem információbiztonsági megoldásait fejlesztette, új termékük célközönségévé pedig az online áruházak váltak. Az AppShield dinamikus információbiztonsági házirendek alapján képes volt elemezni a HTTP-kéréseket és a blokkolt támadásokat.
Az AppShielddel nagyjából egy időben (2002-ben) jelent meg az első nyílt forráskódú WAF. Lett . A WAF-technológiák népszerűsítésének céljával hozták létre, és továbbra is támogatja az informatikai közösség (itt van ). A ModSecurity blokkolja az alkalmazások elleni támadásokat szabványos reguláris kifejezések (aláírások) alapján - eszközök a kérések minták alapján történő ellenőrzéséhez - .
Ennek eredményeként a fejlesztőknek sikerült elérniük céljukat - új WAF-megoldások kezdtek megjelenni a piacon, köztük a ModSecurity alapúak is.
Három generáció már történelem
A WAF rendszerek három generációját szokás megkülönböztetni, amelyek a technológia fejlődésével fejlődtek.
Első generáció. Reguláris kifejezésekkel (vagy nyelvtanokkal) működik. Ide tartozik a ModSecurity. A rendszerszolgáltató megvizsgálja az alkalmazások elleni támadások típusait, és mintákat generál, amelyek leírják a jogos és potenciálisan rosszindulatú kéréseket. A WAF ellenőrzi ezeket a listákat, és eldönti, mit kell tenni egy adott helyzetben – blokkolja-e a forgalmat vagy sem.
Példa a reguláris kifejezéseken alapuló észlelésre a már említett projekt nyílt forráskód. Egy másik példa - , amely szintén nyílt forráskódú. A reguláris kifejezésekkel rendelkező rendszereknek számos hátránya van, különösen, ha új biztonsági rést fedeznek fel, a rendszergazdának további szabályokat kell manuálisan létrehoznia. Egy nagyméretű informatikai infrastruktúra esetében több ezer szabály is lehet. Ennyi reguláris kifejezés kezelése meglehetősen nehéz, nem beszélve arról, hogy ezek ellenőrzése csökkentheti a hálózati teljesítményt.
A reguláris kifejezések téves pozitív aránya is meglehetősen magas. A híres nyelvész, Noam Chomsky javasolta a nyelvtanok osztályozását, amelyben négy feltételes összetettségi szintre osztotta őket. E besorolás szerint a reguláris kifejezések csak olyan tűzfalszabályokat írhatnak le, amelyek nem tartalmaznak eltérést a mintától. Ez azt jelenti, hogy a támadók könnyen „becsaphatják” az első generációs WAF-ot. Ennek egyik módja az, hogy speciális karaktereket adnak az alkalmazáskérésekhez, amelyek nem befolyásolják a rosszindulatú adatok logikáját, de sértik az aláírási szabályt.
Második generáció. A WAF-ok teljesítményével és pontosságával kapcsolatos problémák megkerülésére második generációs alkalmazási tűzfalakat fejlesztettek ki. Mostantól olyan elemzőkkel rendelkeznek, amelyek felelősek a szigorúan meghatározott támadástípusok azonosításáért (HTML, JS stb.). Ezek az elemzők speciális tokenekkel működnek, amelyek lekérdezéseket írnak le (például változó, karakterlánc, ismeretlen, szám). A potenciálisan rosszindulatú tokenszekvenciák egy külön listába kerülnek, amelyet a WAF rendszer rendszeresen ellenőrzi. Ezt a megközelítést először a Black Hat 2012 konferencián mutatták be C/C++ formájában , amely lehetővé teszi az SQL injekciók észlelését.
Az első generációs WAF-okhoz képest a speciális elemzők gyorsabbak lehetnek. Nem oldották meg azonban a rendszer manuális konfigurálásával kapcsolatos nehézségeket, amikor új rosszindulatú támadások jelennek meg.
Harmadik generáció. A harmadik generációs észlelési logika fejlődése olyan gépi tanulási módszerek alkalmazásából áll, amelyek lehetővé teszik, hogy az észlelési nyelvtan a lehető legközelebb kerüljön a védett rendszerek valódi SQL/HTML/JS nyelvtanához. Ez a detektálási logika képes arra, hogy a Turing-gépet rekurzívan felsorolható nyelvtanok lefedésére alkalmazza. Sőt, korábban az adaptálható Turing-gép létrehozásának feladata megoldhatatlan volt, amíg meg nem jelentek az első neurális Turing-gépekkel kapcsolatos tanulmányok.
A gépi tanulás egyedülálló lehetőséget biztosít bármilyen nyelvtan adaptálására bármilyen típusú támadás lefedésére anélkül, hogy manuálisan hozna létre aláírási listákat az első generációs észlelésnek megfelelően, és anélkül, hogy új tokenizátorokat/elemzőket fejlesztettek volna ki új támadástípusokhoz, például Memcached, Redis, Cassandra, SSRF injekciókhoz. , ahogy azt a második generációs módszertan megköveteli.
A detektálási logika mindhárom generációjának kombinálásával egy új diagramot rajzolhatunk, amelyen a detektálás harmadik generációját a piros körvonal ábrázolja (3. ábra). Ez a generáció tartalmazza az egyik megoldást, amelyet az Onsekkel, a webalkalmazások adaptív védelmét szolgáló platform és a Wallarm API fejlesztőjével közösen a felhőben valósítunk meg.
Az észlelési logika most az alkalmazástól érkező visszajelzéseket használja önhangolására. A gépi tanulásban ezt a visszacsatolási hurkot „megerősítésnek” nevezik. Általában egy vagy több típusú ilyen megerősítés létezik:
- Az alkalmazás válasz viselkedésének elemzése (passzív)
- Szkennelés/fuzzer (aktív)
- Fájlok/elfogó eljárások/csapdák bejelentése (utólag)
- Kézikönyv (a felügyelő határozza meg)
Ennek eredményeként a harmadik generációs észlelési logika a pontosság fontos kérdésével is foglalkozik. Mostantól nemcsak a hamis pozitív és hamis negatívok elkerülése lehetséges, hanem az érvényes igaz negatívumok észlelése is, például az SQL parancselemek használatának észlelése a Vezérlőpulton, a weboldalsablonok betöltése, a JavaScript-hibákhoz kapcsolódó AJAX kérések és egyebek.
Ezután megvizsgáljuk a különböző WAF-megvalósítási lehetőségek technológiai lehetőségeit.
Hardver, szoftver vagy felhő – mit válasszunk?
Az alkalmazástűzfalak megvalósításának egyik lehetősége a hardveres megoldás. Az ilyen rendszerek speciális számítástechnikai eszközök, amelyeket a vállalat helyben telepít az adatközpontjába. De ebben az esetben meg kell vásárolnia saját berendezését, és pénzt kell fizetnie az integrátoroknak a beállításáért és a hibakeresésért (ha a cégnek nincs saját informatikai részlege). Ezzel egyidejűleg minden berendezés elavulttá és használhatatlanná válik, így a vásárlók kénytelenek a hardverfrissítésekre költségvetést számolni.
A WAF telepítésének másik lehetősége a szoftveres megvalósítás. A megoldás egyes szoftverekhez kiegészítőként van telepítve (például a ModSecurity az Apache tetején van konfigurálva), és ugyanazon a szerveren fut vele. Az ilyen megoldások általában fizikai szerveren és felhőben is telepíthetők. Hátrányuk a korlátozott méretezhetőség és a gyártói támogatás.
A harmadik lehetőség a WAF beállítása a felhőből. Az ilyen megoldásokat a felhőszolgáltatók előfizetéses szolgáltatásként biztosítják. A cégnek nem kell speciális hardvert vásárolnia és konfigurálnia, ezek a feladatok a szolgáltató vállára hárulnak. Fontos szempont, hogy a modern felhőalapú WAF nem jelenti az erőforrások áttelepítését a szolgáltató platformjára. A webhely bárhol telepíthető, akár a helyszínen is.
További magyarázatot adunk, hogy az emberek miért keresik egyre inkább a felhőalapú WAF-ot.
Mire képes a WAF a felhőben
Ami a technológiai lehetőségeket illeti:
- A frissítésekért a szolgáltató felelős. A WAF előfizetéssel biztosított, így a szolgáltató figyelemmel kíséri a frissítések és licencek relevanciáját. A frissítések nem csak szoftverre, hanem hardverre is vonatkoznak. A szolgáltató frissíti és karbantartja a szerverparkot. Felelős a terheléselosztásért és a redundanciáért is. Ha a WAF-szerver meghibásodik, a forgalom azonnal átirányul egy másik gépre. A forgalom racionális elosztása lehetővé teszi, hogy elkerülje azokat a helyzeteket, amikor a tűzfal hibaüzemmódba lép - nem tud megbirkózni a terheléssel, és leállítja a kérések szűrését.
- Virtuális foltozás. A virtuális javítások addig korlátozzák a hozzáférést az alkalmazás feltört részeihez, amíg a fejlesztő be nem zárja a biztonsági rést. Ennek eredményeként a felhőszolgáltató ügyfele lehetőséget kap arra, hogy nyugodtan megvárja, amíg az adott szoftver szállítója közzéteszi a hivatalos „javításokat”. Ennek a lehető leggyorsabb megtétele a szoftverszállító prioritása. Például a Wallarm platformon egy külön szoftvermodul felel a virtuális foltozásért. A rendszergazda egyéni reguláris kifejezéseket adhat hozzá a rosszindulatú kérések blokkolásához. A rendszer lehetővé teszi egyes kérések „Bizalmas adatok” jelzővel való megjelölését. Ezután a paramétereik el vannak takarva, és semmilyen körülmények között nem kerülnek továbbításra a tűzfal munkaterületén kívülre.
- Beépített kerület- és sebezhetőség-szkenner. Ez lehetővé teszi az IT-infrastruktúra hálózati határainak önálló meghatározását DNS-lekérdezésekből és a WHOIS protokollból származó adatok segítségével. Ezt követően a WAF automatikusan elemzi a kerületen belül futó szolgáltatásokat (portszkennelést végez). A tűzfal képes felismerni az összes gyakori sebezhetőséget - SQLi, XSS, XXE stb. -, és azonosítani a szoftverkonfiguráció hibáit, például a Git és BitBucket tárolókhoz való jogosulatlan hozzáférést, valamint az Elasticsearch, Redis, MongoDB névtelen hívásait.
- A támadásokat felhő-erőforrások figyelik. A felhőszolgáltatók általában nagy számítási teljesítménnyel rendelkeznek. Ez lehetővé teszi a fenyegetések nagy pontosságú és gyors elemzését. A felhőben egy szűrőcsomópont-fürt van telepítve, amelyen az összes forgalom áthalad. Ezek a csomópontok blokkolják a webalkalmazások elleni támadásokat, és statisztikákat küldenek az Analytics központnak. Gépi tanulási algoritmusokat használ az összes védett alkalmazás blokkolási szabályainak frissítésére. Egy ilyen séma megvalósítása az ábrán látható. 4. Az ilyen személyre szabott biztonsági szabályok minimalizálják a hamis tűzfalriasztások számát.
Most egy kicsit a felhőalapú WAF-ok jellemzőiről a szervezeti kérdések és menedzsment szempontjából:
- Átállás az OpEx-re. A felhőalapú WAF-ok esetében a megvalósítás költsége nulla lesz, mivel az összes hardvert és licencet már kifizette a szolgáltató, a szolgáltatás fizetése előfizetéssel történik.
- Különböző tarifacsomagok. A felhőszolgáltatás felhasználója gyorsan engedélyezheti vagy letilthatja a további opciókat. A funkciók egyetlen vezérlőpultról kezelhetők, amely szintén biztonságos. HTTPS-en keresztül érhető el, emellett van egy kéttényezős hitelesítési mechanizmus, amely a TOTP (Time-based One-Time Password Algorithm) protokollon alapul.
- Csatlakozás DNS-en keresztül. A DNS-t saját maga módosíthatja, és beállíthatja a hálózati útválasztást. E problémák megoldásához nincs szükség egyéni szakemberek toborzására és képzésére. Általában a szolgáltató műszaki támogatása segíthet a beállításban.
A WAF-technológiák az ökölszabályokkal rendelkező egyszerű tűzfalaktól a gépi tanulási algoritmusokkal rendelkező összetett védelmi rendszerekig fejlődtek. Az alkalmazások tűzfalai ma már olyan funkciók széles skáláját kínálják, amelyeket a 90-es években nehéz volt megvalósítani. Sok szempontból új funkciók megjelenése vált lehetővé a felhőtechnológiáknak köszönhetően. A WAF megoldások és alkatrészeik folyamatosan fejlődnek. Csakúgy, mint az információbiztonság más területein.
A szöveget Alexander Karpuzikov, a #CloudMTS felhőszolgáltató információbiztonsági termékfejlesztési menedzsere készítette.
Forrás: will.com