Fehér Könyv (technikai)
www.balabit.hu
Tűzfalak evolúciója Kivonat:
Készítette: Verzió: Dátum:
A tanulmány részletesen bemutatja a hálózati határvédelmi eszközök történetét a kezdetektől egészen a napjainkban elterjedőben lévő fejlett megoldásokig. Illés Márton, Bánfi Tamás 1.0 2005-08-19
© 2005 BalaBit IT Security
Tűzfalak evolúciója
Tűzfalak evolúciója Mi is a tűzfal? A határvédelmi termékek iránt megnövekedett igény következtében számos termék - régi és új - található a piacon. Ezek célközönsége igen változatos, a személyes tűzfaltól (personal firewall), a több ezer alkalmazottal dolgozó cégek védelmére szánt szoftverekig. Az egyes termékek technikai működése legtöbbször homályos, még tapasztalt szakembereknek is gondot okozhat értékelésük, ha nem kifejezetten IT biztonságtechnikával foglalkoznak. A különböző tűzfal termékek gyakran egymástól teljesen eltérő technológiát használnak, legalább ennyire eltérő jellemzőkkel és képességekkel. Annak érdekében, hogy az eszköz kiválasztása megalapozott legyen, szükséges a cél megfogalmazása és az alkalmazott technológiák ismerete. Az informatikai biztonsághoz meg kell teremteni az adminisztratív szabályzást, meg kell valósítani az informatikai eszközök fizikai védelmét, majd a megfelelő határvédelmi eszközökkel be kell tartatnunk az Informatikai Biztonsági Szabályzat (IBSZ) határpontra vonatkozó rendelkezéseit. Az IBSZ ezen fejezetei szabályozzák a határpontokon keresztül elérhető távoli erőforrások használatát, az ehhez kapcsolódó felhasználói jogosultságok rendszerét, az egyes hálózati protokollokra vonatkozó előírásokat valamint bizonyos logikai szabályokat. A védelem megvalósításának első lépése a védendő hálózat Internettől való szeparálása, és az átjárás szabályainak megvalósítása. Ezt az elvet kiterjeszthetjük, és alkalmazhatjuk belső hálózatunkon is, tűzfallal választva le belső rendszereinket egymástól. Ezt indokolhatja a CSI felmérés is, mely szerint a betörések 60%-80%-a belső segítséggel történik.
A tűzfalak fejlődése A hálózatra kötött számítógépek számos visszaélésre adnak lehetőséget, a számítógépeken futó alkalmazásokból, az alkalmazások által használt protokollokból és az emberi gondatlanságból kifolyólag. A kockázat mértéke pedig az ugyanazon hálózatra csatlakozó felhasználók számával arányosan nő. Ennek csökkentésére tett kísérleteket (ideértve a szoftveres és adminisztratív megoldásokat is) többnyire az aktuális problémák elhárítása motiválja, amiből két dolog következik: •
IT biztonságtechnikában a kockázatot csak minimalizálni lehet, teljesen kiküszöbölni általában nem.
• az IT security folyamatosan fejlődik. A biztonság nem állapot, hanem folyamat. A biztonság fenntartásához állandó felügyeletre, rendszerfrissítésekre van szükség.
www.balabit.com
2/13
Tűzfalak evolúciója A továbbiakban bemutatásra kerülő egyes technológiák esetében éppen ezért fontos mérlegelni, hogy azok mely kihívásoknak próbálnak megfelelni, technológiailag hogyan illeszthetőek a mai kor követelményeihez.
Védelem nélkül Az Internet alapvető szabványait azzal a feltételezéssel tervezték, hogy a hálózatba kizárólag jóindulatú, intézményi felhasználók kapcsolódnak. Ami nem biztonságos, azt egyszerűen nem szabad. Az adminisztratív szabályok betartásáról a hálózatba kapcsolódó intézmények maguk gondoskodnak. Az Internet szabaddá tételével a helyzet alapvetően megváltozott. Gyakorlatilag bárki kapcsolódhatott a hálózathoz, akár más országokból is. A felhasználók érdekazonosságában többé nem lehetett bízni, hiszen konkurens vállalatok és kormányok, valamint ellenőrizetlen magánfelhasználók is a rendszer felhasználói lehettek.
Csomagszűrő routerek Az egyik kezdeti probléma az volt az Internettel, hogy a forgalmazott csomagok címzettjei védtelenek a kéretlen küldemények ellen. Az Internetre kapcsolt szerverek minden nekik címzett csomagot megkapnak és feldolgoznak. A szakemberek a routerekben látták a megoldást, mivel ezek azok a hálózati eszközök, melyeken egyébként is keresztül haladt a teljes forgalom. A routerek a hálózatok bejáratánál állnak, így ezen az egy ponton a teljes átmenő forgalom ellenőrizhető. A routerek - amik addig csak a csomagok célba juttatásáért voltak felelősek - új feladatot kaptak tehát: adott szabályok alapján egyes csomagokat engedjenek át, míg másokat dobjanak el. A döntéseket az úgynevezett csomagszűrő routerek - vagy csomagszűrő tűzfalak - a továbbítani kívánt csomag fejlécében található adatok és a beprogramozott szabályok összehasonlítása alapján hozzák meg.
A csomagszűrő routerek jelentették a legelső lépést a tűzfalak kialakulásában, melyekkel párhuzamosan jelent meg a bastion host, megteremtve ezzel a később kialakult csomagszűrő - alkalmazás szintű tűzfal kettősségét. Az igény az Internet szűrésmentes világának biztonságosabbá tétele volt. A routerek jó megoldási alternatívát jelentettek, mivel a hálózati forgalom mindenképpen rajtuk keresztül haladt. Új feladatot kaptak tehát a routerek, amik eddig csak a csomagok célba juttatásáért voltak felelősek: adott szabályok alapján egyes csomagokat engedjenek át, míg másokat dobjanak el. A döntéseket ezek az úgynevezett csomagszűrő routerek - vagy csomagszűrő tűzfalak - a továbbítani kívánt csomag fejlécében található adatok, valamint az előre beprogramozott szabályok alapján hozzák.
A csomag vizsgálatánál csak a csomagok fejlécét vizsgálják meg, a magasabb rétegeket (alkalmazási réteg) adatnak tekintik, és nem foglalkoznak vele. A csomagszűrők a fejlécet azonban különböző szinten vizsgálják. Az IP szint minden esetben kiértékelésre kerül, azaz a döntést befolyásolja a csomag forrás és cél címe, esetleges fragmentálási adatai, illetve ritka esetben még az IP opciók értékei is. A legtöbb implementáció esetében kiértékelésre kerül a következő (adatkapcsolati) réteg is (TCP/UDP). Ezek plusz információt jelentenek a döntési szabályok megfogalmazásakor, lehetőség nyílik a forrás, illetve cél portra való szűrésre, illetve TCP esetén a TCP flagek figyelembe vételére is.
www.balabit.com
3/13
Tűzfalak evolúciója
A csomagszűrő tűzfalak döntési mechanizmusa szabálylistákon alapszik. A döntési szabályok (rule-ok) mintákat tartalmaznak, valamint egy döntést. A szabályok egymás után kerülnek kiértékelésre és amennyiben a csomag fejlécéből nyert információk illeszkednek a szabályban megfogalmazott mintákra (forrás cím ill. port, cél cím ill. port), akkor a csomag a szabályban meghatározott döntés értelmében eldobásra, vagy átengedésre kerül. Bizonyos csomagszűrők implementációtól függően lehetőséget biztosítanak a csomag visszautasítására, naplózására, illetve címfordításra (NAT). Az ilyen jellegű feladatok megoldását a csomagszűrők minden esetben modulok segítségével oldják meg, melyek biztosítják számára az adott feladat megvalósításához szükséges állapottartó képességet. (Az állapotkövetés a fent említett NAT - Network Address Translation funkciók ellátásához szükséges.) A csomagszűrők felépítésükből, és működésükből következően nem alkalmasak bonyolult igények implementálására, az átmenő forgalom összetett szűrésére, kapcsolatok követésére. A szabálylisták segítségével leírt policy, azaz szabályrendszer összetett esetekben nagyon nagyra, és ami még rosszabb, átláthatatlanra dagadhat. A csomagok, mint egymástól különálló adatok kerülnek kezelésére, melynek eredményeként nincs lehetőség a TCP kapcsolatok állapotának megbízható nyomon követésére, ami újabb támadási felületet biztosít, illetve megnehezíti a tűzfal adminisztrátorának munkáját az IBSZ-ben definiált szabályok implementálására. Szintén az adminisztrátor lehetőségeit korlátozza a csomagszűrő tűzfalak azon tulajdonsága, hogy kizárólag a csomag fejlécével foglalkoznak, azaz nagyjából a teljes csomag mintegy 35%-átveszik figyelembe döntéseik meghozatalánál. Az állapottartás hiánya miatt problémát okoz a csomagszűrő tűzfalak esetén a több porton folyó kommunikáció átengedése, tűzfalazása. Ilyen tipikus - gyakran használt - protokoll például a fájlok átvitelét megvalósító FTP (fájl Transfer Protocol), de számtalan más protokoll is. (SQLNet, H.323, stb) A probléma megoldásához mind a csomagszűrő, mind az állapottartó csomagszűrők kénytelenek több portos kommunikáció esetén beletekinteni az első csatorna adatrészébe is, hogy kinyerjék belőle a második csatorna port számára vonatkozó információt. Bár ez egy lépés az alkalmazás szintű elemzés irányába, tulajdonképpen elemzés az adatrészben nem történik, csupán az adott szolgáltatás kiszolgálásához szükséges információk kinyeréséről beszélhetünk. Csomagszűrő tűzfalaknál ebben az esetben is a feladatra speciálisan előkészített modulok nyújtják a megoldást hasonlóan a NAT funkcióknál leírtakhoz. A csomagszűrő tűzfalak lehetőségei korlátoltak, napjainkban egyre ritkábban találunk tisztán csak csomagszűrő technológiát alkalmazó megoldásokat. Az állapottartás kikerülhetetlen voltát mutatja, hogy bizonyos korábban részletezett feladatok egyáltalán nem oldhatóak meg tisztán csomagszűrő technológiával.
www.balabit.com
4/13
Tűzfalak evolúciója
Állapottartó csomagszűrő A csomagszűrő routereket gyakorlatilag csupán arra lehetett használni, hogy csomagokat kizárólag a megbízható címtartományokból engedjenek be a saját hálózatukba. Ezzel visszaállt az Internet nagyközönség előtti megnyitását megelőző biztonsági szint, hiszen a kommunikációt újra a megbízható intézményekre korlátozhattuk. Azonban, például a kibontakozóban lévő elektronikus kereskedelem igényeire ez nem jelentett megoldást. Az üzletnek olyan eszközre volt szüksége, ami az ismeretlen szerverekkel történő kommunikációt is képes volt biztonságosabbá tenni. Ehhez első lépésként arra volt szükség, hogy a tűzfal azonosítani tudja a kapcsolat kezdetét és végét, valamint a kettő között zajló adatforgalmat. Ha erre képes, akkor ki tudja szűrni a kapcsolatba nem illő csomagokat, amik potenciálisan veszélyesek.
A feladat kizárólag állapottartással oldható meg. Azaz a beérkező csomagokat átmenetileg tárolni kell, amíg a döntéshez elegendő információt össze nem gyűjtötte a tűzfal. A csomagszűrő és az állapottartó csomagszűrők között a vizsgálat mélységében nincs különbség, csupán az abból nyert információ feldolgozásában. Míg az előző egyetlen csomag fejléce alapján hozza meg a döntést, addig az utóbbi magát a kapcsolatot képes vizsgálni ugyancsak a fejlécekre hagyatkozva.
A csomagszűrő tűzfalak bizonyos, a technológia leírásuknál taglalt hibák kiküszöbölése okán születettek meg az állapottartó-csomagszűrő tűzfalak. Csomagszűrő testvérükhöz hasonlóan az állapottartók is szabályláncokkal dolgoznak, de jelentős különbségként, már nem csak az adott csomagból nyert információkat használják fel döntéseik meghozatalához, hanem a csomagok közti kapcsolatokat is figyelembe veszik. Ez a plusz kiegészítés alapvetően a kapcsolatorientált protokollok esetén nyújt plusz lehetőségeket, nagyobb biztonságot. Ilyen protokollra tipikus és a leggyakoribb példa a TCP. A TCP protokoll tűzfalazása esetén az állapottartó tűzfalak képesek a TCP kapcsolatok állapotának követésére, azaz képesek megkülönböztetni a kapcsolat kiépülését végző csomagokat (3-way handshake), a kapcsolat kiépülése után adatot közvetítő csomagokat, valamint a kapcsolat megszakítását, lezárását végző csomagokat. A csomagok megkülönböztetése mellet a tűzfal figyelembe veszi, hogy adott csomag csak adott helyen jelenhet meg a kommunikációban. Például adatot tartalmazó csomag nem előzheti meg a kapcsolat kiépülését, és nem érkezhet a kapcsolat lezárását követően sem. A több csatornás, vagy több porton kommunikáló kapcsolatok, protokollok átviteléhez az állapottartó csomagszűrők ugyanazt az elvet alkalmazzák, amit a csomagszűrő tűzfalak is és adatértelmező képességükre is ugyanazon limitációk vonatkoznak. Az állapottartó-csomagszűrők segítségével könnyebbé válik az átmenő forgalom nyomon követése és szűrése. Már nem csak atomi szinten kerülnek ellenőrzésre a csomagok, hanem a kapcsolatok egésze, az azok közti összefüggések alapján van lehetősége a tűzfalnak az ellenőrzésre. Például TCP válaszcsomagok esetén nem csak az ACK flag megléte, vagy hiánya szolgáltat alapot a döntéshez, hanem a teljes TCP kapcsolat nyomon követése (seq-num, ack-num, window size, stb...) adja meg a segítséget a tűzfalnak. Ugyanígy az új kapcsolat kezdeményezése sem csak a SYN flag meglétén múlik. Az állapottartó csomagszűrő tűzfalak tehát jelentős továbblépést jelentenek a klasszikus csomagszűrőkhöz képest. Mindazonáltal megválaszolatlanul maradnak további problémák, melyeket a technológia ez irányú továbbfejlesztésével már nem lehet orvosolni. A csomagszűrés esetén csak a csomag fejlécéből nyert adatok kerülnek vizsgálatra, a csomag további, megközelítőleg 95-97%-át kitevő adatrész értelmezés nélkül jut át a tűzfalon. Ezen a tényen számottevően a kiegészítő modulok léte sem változtat, hiszen ezek feladata nem az applikációs szintű elemzés megvalósítása egy csomagszűrő esetében, hanem egy bizonyos funkcionalitás biztosítása. A probléma megoldására a tűzfalfejlődés másik ágát képviselő úgynevezett applikációs, avagy proxy tűzfalak jelentik a megoldást, melyek fejlődése a csomagszűrő tűzfalakkal egy
www.balabit.com
5/13
Tűzfalak evolúciója időben a bastion host-okkal kezdődött.
Bastion Host A tűzfalak fejlődésének korai szakaszában jelentek meg mint a csomagszűrő routerek alternatívái. Igazából nem nevezhetőek - a klasszikus értelemben nevezett - tűzfalnak, mivel nem végeznek szűrést, de ennek ellenére, mint hálózati határvédelmi eszközök funkcionálnak. A bastion hosztok szerver gépek, melyek több felhasználó párhuzamos, távoli munkáját támogatják. A gép mind a védendő hálózat (intranet), mind a publikus hálózat (Internet) felé rendelkezik direkt kapcsolattal. Így abban az esetben, ha a védett hálózatból egy kliens valamilyen erőforrást akar elérni az Interneten, akkor először be kell jelentkeznie a bastion host-ra, majd ott, a kívánt erőforrás elérését biztosító programot elindítania. Bastion host alkalmazása esetén a szűrési lehetőségek kimerülnek a felhasználók hitelesítéséből adódó lehetőségekkel, valamint nehezen érhetőek el kívülről védett zónában lévő erőforrások. Használat szempontjából alapvetően bonyolultabb a bastion host-ok a felhasználók és az adminisztrátorok számára is, biztonsági szempontból pedig problémát jelent, hogy sok felhasználó használja egyszerre ugyanazt az erőforrást. Így az adminisztrátornak nagyon változékony körülmények között kell biztosítania a rendszer működését és az emberi tényező, mint leggyengébb láncszem fokozottan veszélyforrást jelent. Sok hibájuk ellenére a bastion host-ok egy új - a csomagszűrők elvétől merőben eltérő - megközelítést jelentenek a hálózati határvédelem területén.
A csomagszűrő és állapottartó csomagszűrő tűzfalak esetében a kliens közvetlenül kapcsolódik a szerverhez, azaz a kliens által küldött csomag változatlan formában jut el a szerverhez. (Természetesen előfordulnak kivételek, mikor a csomag tartalma - jellemzően a fejléce - megváltozik a tűzfalon történő áthaladás folyamán. Ilyen eset például a címfordítás (NAT), ahol a forrás, vagy a cél cím változik meg). Ezzel szemben a bastion host használata esetén már nem egy kapcsolatról beszélünk, a kommunikáció két fázisra oszlik. Az egyik kapcsolat a kliens és a bastion hoszt között, míg a másik a bastion hoszt és a szerver között épül ki. Ez a megoldás - működéséből adódóan – lehetetlenné teszi a csomagszintű támadásokat. A közvetlen csomagkapcsolat megszüntetése egy további előnnyel is jár. Az alapvetően kapcsolatorientált protokollok használatánál (mint amilyen a TCP, amit ma az Interneten leginkább használunk), új megközelítés kerülhet előtérbe. Már nem a csomag jelenti az atomi elemet, hanem a kapcsolatra koncentrálva tervezzük, és valósítjuk meg hálózati határvédelmünket. A kapcsolatorientált protokollok esetében a kapcsolat kerüljön előtérbe. Így lehetőség nyílik a csomagszűrők másik nagy hiányosságának - az adat rész ellenőrzés hiányának pótlására. Ez további eszköz az adminisztrátor kezében az IBSZ betartatására, a biztonság növelésére. Az alkalmazási szint ellenőrzésével lehetőség nyílik az applikációk elleni támadások sikeresebb kivédésére, valamint a több információnak köszönhetően az összetettebb - és az implementációtól függően flexibilisebb döntések meghozatalára. A fenti, "új megközelítés" előnyeit, a bastion hostok esetében még nincs módunk kihasználni, de utat mutatnak a további fejlődés, fejlesztés felé vezető úton. A bastion hostok másik nagy hátránya, a nehéz kezelhetőségre válaszul született meg a fejlettebb proxy, valamint socks tűzfalak elképzelése, melyek kényelmesebb alternatívát jelentenek.
www.balabit.com
6/13
Tűzfalak evolúciója
Socks tűzfalak A Socks tűzfalak talán a tűzfal fejlődés egyik legérdekesebb, de igencsak rövid életű irányát képviselik. Valahol félúton helyezkednek el a csomagszűrő és a proxy megoldások között. Működésük és jellemzőik a "kicsit ilyen is, kicsit nem is" elvet képviselik, azaz kicsit proxyk, de kicsit kevesebbek is, kicsit csomagszűrők, de kicsit többek is, kicsit transzparensek, de kicsit nem is azok.
Hogyan működnek a Socks Proxyk? A Socks proxyk működési elve egyszerű: A kliens gépre telepítésre kerül egy program modul, ami minden hálózati kapcsolat kezelését átveszi az eredeti operációs rendszertől. Amikor egy program kapcsolódni akar egy szerverhez, akkor a kapcsolódási kérését a modul kezeli, és a program helyett kapcsolódik az előre beállított SOCKS proxyhoz, majd megadja a proxynak, hogy milyen címre szeretne kapcsolódni. Ezek után a proxy kapcsolódik a kliens program által kijelölt szerverhez. A kapcsolat kiépülése után az adatforgalmat a kliens program a modul segítségével a SOCKS proxyn keresztül a végzi. Ez a megoldás hálózati szempontból nem tekinthető transzparensnek, de a program szempontjából igen, mivel a programon nem kell külön beállításokat elvégezni. (Bizonyos programok natívan támogatják SOCKS proxyk használatát, ilyenkor természetesen a megoldás nem tekinthető transzparensnek.) A SOCKS működési elvéből következik, hogy klasszikus értelemben csomagszűrőnek nem nevezhető, mivel csomagok a kliens és a szerver között nem közlekednek. Azonban nem tekinthetőek a SOCKS tűzfalalak alkalmazásszintű tűzfalnak sem, mivel a forgalom nem alkalmazási szinten kerül szűrésre, hanem csak hálózati szinten. A SOCKS megoldások nagy előnye, hogy nem transzparens mivoltuk ellenére nem igényelnek különlegesen megírt programokat, mivel a legtöbb esetben lehetőség van az operációs rendszerbe beépülő modul alkalmazására. Nagy előnye a SOCKS megoldásoknak, hogy segítségével, az átengedett protokolltól függetlenül lehetőség nyílik az átmenő forgalom tetszőleges authentikálására. Elmondható, hogy a SOCKS tűzfalak bizonyos tekintetben a csomagszűrők fölött, de az alkalmazásszintű tűzfalak alatt helyezkednek el. Nem teljesen transzparens mivoltuk, és limitált magas szintű szűrési képességeik azonban meggátolták széleskörű elterjedését.
Alkalmazásszintű, avagy Proxy tűzfalak A proxy tűzfalak jelentik az első jelentős lépcsőfokot a nem csomagszűrő típusú tűzfalak fejlődésében. A proxy-k a bastion host megoldások után jelentek meg azzal a céllal, hogy kiküszöböljék a felhasználók szerverre való bejelentkezésből adódó kényelmetlenségeket, illetve az ebből fakadó veszélyeket. A proxy tűzfalak működési elve nagyon egyszerű. A kliensek és a kiszolgálók között nem épül fel közvetlen kapcsolat, hanem mindketten a tűzfalon futó proxy alkalmazással kommunikálnak. A proxy egyik hálózati csatolójával az ismeretlen hálózat kiszolgálóihoz kapcsolódik, a másikkal pedig a belső hálózatban található kliensekhez. A kapcsolat kettősségéből kifolyólag a proxy tűzfalak minden különösebb beállítás nélkül képesek kivédeni a csomagszintű támadásokat. Bár a proxy-k kifejlesztésében elsősorban használhatósági szempontok jelentették a fő motívumot, a kialakult új architektúra képessé tette a tűzfalakat arra is, hogy alkalmazásszinten ellenőrizzék a rajtuk áthaladó információáramot. A proxy alkalmazások már nem csupán a csomagok fejlécét vizsgálták, hanem azok adatrészébe is belenéztek, és akár módosításokat is végrehajtottak. Már most le kell azonban szögezni, hogy a cél alapvetően nem a mély protokollelemzés volt, így bár architektúrálisan megoldható lett volna, a proxy tűzfalak első generációja nem értelmezte a protokollok összes utasítását, csupán azok elenyésző részét.
www.balabit.com
7/13
Tűzfalak evolúciója Sokszor a proxykat mint web oldalak gyorstárazás (cache) funkciójával ellátott programot említik. Ezeknek a cacheing proxyknak nem céljuk a biztonság növelése, sokkal inkább a web elérések gyorsítása, ami merőben különböző feladat. Ezeket a programokat inkább webcache névvel célszerűbb említeni a fogalomzavar elkerülése érdekében. A hasonló elnevezés egyébként nem véletlen, a két eszköz működése sok hasonlóságot mutat, de a céljuk az, amiben alapvetően eltérnek. Mind a webcache, mind a tűzfalaknál alkalmazott proxy-k kliensek kiszolgálását teszik lehetővé transzparensen, azaz a bastion host technológiánál leírt két kapcsolat felépítésén alapuló kommunikáció egy közös jellemző. A határfelületet tovább mossa, hogy bizonyos webcache megoldások értelmeznek egy-két parancsot adott protokollból. Például webcache megoldások képesek URL filtering-re a HTTP protokollban, vagy értelmezve a “get” parancs után kapott paramétert (illik-e valamilyen tiltott mintára), vagy egyszerűen mintaillesztéssel megoldva a feladatot. Utóbb csak egy standard weblekérés mintaillesztése történik véletlenszerűen az adatfolyamban. A csomagszűrő és állapottartó csomagszűrő tűzfalak ugyanezen elvek valamelyike alapján oldják meg ezt a feladatot. Alkalmazás szintű proxy-k azonban protokoll értelmezési képességük miatt mindig parancskereséssel kezdik az URL szűrés műveletét. A proxy tűzfalak megjelenése elsődlegesen a bastion hostok kényelmetlen mivoltára vezethető vissza, ezért is logikus, hogy egyik funkciójuk e kényelmetlenség megszüntetésére irányul. Proxy használata esetén is adott tehát egy gép, ami mind a védett, mind a külső hálózathoz dedikált interfészen csatlakozik. A gépen speciális proxy alkalmazások futnak, ezekhez az alkalmazásokhoz kapcsolódnak a kliens gépén futó programok. A kliens program megadja a proxynak (megbízottnak), hogy a külső hálózaton milyen erőforrást akar elérni, a proxy kapcsolódik az erőforráshoz, majd az eredményt továbbítja a kliens számára. Itt már a kapcsolat van a középpontban és így a kommunikációk szűrése magasabb szinten is lehetséges. Mivel minden protokollhoz, külön proxy-ra van szükség, ezért ennek a módszernek a használata esetén rendelkezni kell az összes használni kívánt protokollhoz megfelelő proxyval. Ez nagyszámú protokoll esetén komoly költséget jelenthet. Az előnye a protokollonkénti proxyk alkalmazásának, hogy adott proxyn csak adott protokoll specifikációjának megfelelő kommunikáció folyhat. Sőt implementációtól függően lehetőség van a kommunikáció protokoll szintű szűrésére. Proxyk esetében a teljes kommunikációra rálátása, ellenőrzési és szűrési lehetősége van a tűzfalnak, ezáltal az adminisztrátornak. A proxy tűzfalak esetén nem okoz problémát a több, portot használó protokollok tűzfalazása, mivel az architektúrának köszönhetően a proxy az alkalmazásszintből minden információval rendelkezik az újabb kapcsolatok megnyitásához. A másodlagos csatornán történő kommunikációt a proxy - implementációtól függően - szintén ellenőrzi. Több csatornás kapcsolatok (FTP, SQLNet, stb.) cél, illetve forrás címeinek NATolása sem igényel kiegészítő megoldások alkalmazását. A proxy tűzfalak egyik hátránya, hogy a használni kívánt protokollnak támogatnia kell a proxy-s működést. A ma használt protokollok esetében sajnos ez nem minden esetben megoldott. Éppen ezért az egy csatornás protokollok esetén rendelkezésre áll egy, úgynevezett general, vagy plug proxy, aminek a feladata csak a kapcsolat megfelelő továbbítása. Ezek a plug proxyk nem ellenőrzik az átmenő forgalom adatrészét, feladatuk csak a két szeparált hálózat közötti kommunikáció biztosítása. Biztonság szempontjából annyival nyújtanak többet a csomagszűrőknél, hogy plug proxy használatakor is két kapcsolat épül ki, kizárva ezzel a csomagszintű támadásokat.
Transzparens Proxy Tűzfal: A proxy tűzfalak konfigurációs igényeiből fakadó kényelmetlenségnél nagyobb problémát jelent az ennek következtében jelentkező emberi hibaforrás hangsúlyosabb jelenléte. (A túl sok és gyorsan változó konfiguráció, mely beállítása a felhasználók alkalmazásait is érinti vagy
www.balabit.com
8/13
Tűzfalak evolúciója követhetetlenné válik sok felhasználós hálózatokban, vagy egyre lazább, minden körülmények között működő, de túlságosan "nyitott" szabályrendszereket eredményez.) A változásokat tovább sürgette, hogy egyre több olyan protokoll jelent meg, melyek nem voltak felkészítve a proxy-s működésre. A cél tehát a transzparens működés megvalósítása, és a proxy funkciókat nem támogató protokollok kezelése lett. A megoldás adott volt. A tűzfalon - elhelyezkedéséből adódóan - minden forgalom áthalad (a tűzfal, mint a szervezet hálózatának internetes, alapértelmezett átjárójaként szerepel). Ebből adódóan lehetőség van a tűzfalon a csomagszűrőkhöz hasonló funkciókat ellátni. A klienseken semmilyen proxy beállítást nem kell megtenni, azaz a kliensek közvetlenül próbálnak kapcsolódni a szerverhez. A csomagszűrökkel szemben azonban a csomagok nem jutnak át a tűzfalon, hanem a tűzfal a csomagokat, kapcsolatokat - beépített csomagszűrőjének segítségével - "elkapja", és magára irányítja. Az átirányított kapcsolatokat pedig a proxy program fogadja, a nem-transzaparens proxyk működéshez hasonlóan. Természetesen a transzparens proxy használatával is lehetőség van nem tarnszparens működésre. A tarnszparens proxyk tehát transzparenciájuk megvalósítása céljából kiemelten támaszkodnak az alacsonyabb szintű csomagszűrőre. A csomagszűrő és a proxyk megfelelő együttműködése eredményezi a sima proxyknál kényelmesebb használati módot. A transzparens proxyk használatával a felhasználók számára a hálózati erőforrások tűzfalon keresztüli elérése kényelmesebbé válik, adminisztrációja áttekinthetőbb. A proxy tűzfalak megoldást nyújtanak a kliensek kényelmes és biztonságos kiszolgálására, látszólag megoldva a tűzfalak által keltett problémákat. Azonban az újabb protokollok fejlődésének, összetettebbé válásának eredményeként napjainkban egy újabb problémával kellett a tűzfalaknak, és az őket felhasználó szakembereknek szembenézniük. Ez a merőben új probléma, az összetett protokollok kezelésének kérdése. Napról napra több alkalmazás támaszkodik összetett protokollokra, amelyek megfelelő, biztonságos kezelésére, a már meglévő technológiák nem nyújtanak kielégítő megoldást. Ilyen összetett protokollhasználatra jó példa a napjainkban az ebuisness keretében elengedhetetlen HTTPS protokoll, ami egy SSL (titkosítást és authentikációt megvalósító) protokoll és egy HTTP protokoll kombinációjából született meg. A megoldás egy új tűzfaltechnológia megjelenését eredményezte.
Moduláris proxy tűzfalak A moduláris proxy tűzfalak megszületése, más tűzfalaktól eltérően, kizárólag a nagyobb biztonság elérése céljából történt meg. A tűzfalak ezen ága nem kényelmi okokból fejlődött ki, a tervezési szempont a megfelelően biztonságos működés elérése volt. A moduláris proxy tűzfalak rendelkeznek a transzparens tűzfalak minden jó tulajdonságával, azaz képesek az átmenő adatfolyam alkalmazásszintű szűrésére, csomagszűrő kiegészítőt tartalmaznak, valamint transzparensek a kliens számára. Az alapvető különbség a hagyományos transzparens tűzfalak és a moduláris tűzfalak között, hogy míg a transzparens tűzfalak minden protokoll értelmezésére, elemzésére különálló tűzfal komponenssel rendelkeznek, amelyek nem képesek együttműködésre, valamint sok esetben bizonyos funkciókat mindegyik komponens megvalósít (kapcsolat fogadása, kapcsolódás a szerverhez, stb.), addig a moduláris proxy részei, moduljai képesek együtt működni, valamint a különböző feladatok ellátását más-más modul végzi, csökkentve ezzel a felesleges redundanciát.
Mit is jelent ez konkrétan? A modularitás több szinten valósul, valósulhat meg egy moduláris tűzfalon. A leggyakoribb és általában a legtöbb helyen szereplő példa az egyes proxy modulok együttműködésén alapszik. Ahogy az előzőekben már megemlítésre került, napjainkban egyre több az összetett alkalmazásszintű protokollt használó program, erre a legjobb példa a már említett HTTPS. A HTTPS különlegessége, hogy nem csak összetett protokoll, hanem
www.balabit.com
9/13
Tűzfalak evolúciója az egyik része titkosított, úgynevezett kripto protokoll, amelynek a szűrése, visszafejtése még bonyolultabb. A moduláris proxy esetében egy SSL proxy és egy HTTP proxy kerül kombinálásra. Az SSL proxy kapja meg az átmenő forgalmat, azt dekódolja - azaz a kliens felé mint a szerver jelenik meg, végrehajtva ezzel egy Man-In-The-Middle támadást -, majd a dekódolt forgalmat átadja a HTTP proxynak. A HTTP proxy már a sima HTTP kérést kapja meg, mintha azt egy sima klienstől kapná. A kérés feldolgozása után a HTTP proxy a kérést továbbküldi, mintha a szervernek küldené, de a kérés az SSL proxyhoz kerül, amely a kérést újra titkosítja és elküldi a szervernek. Ezzel a módszerrel lehetőség nyílik a HTTPS forgalom transzparens HTTP szintű szűrésére, amely fontos részét képezheti a trójai programok, valamint más nem kívánt programok elleni védekezésnek. A moduláris tűzfal bizonyos proxy moduljai fel vannak készítve arra, hogy a rajtuk átmenő forgalom egy részét képesek legyenek egy másik proxynak további elemzésre átadni, azaz más elemző proxy modult a bevonni, beágyazni a forgalom elemzésébe. Természetesen, ha egy proxy modul esetén lehetőség van beágyazásra, akkor az bármelyik másik proxy modult képes beágyazni. (Persze elképzelhetőek olyan kombinációk amelyek esetében nincs értelme a beágyazásnak.) Lehetőség van továbbá több szintű beágyazásra is, például SSL proxyba ágyazott HTTP proxyban tartalomszűrésre, ahol a tartalomszűrést egy tartalomszurok modul valósítja meg, vagy SSL proxyba ágyazott POP3 proxyban a letöltendő levelekben víruskeresésre. Látható, hogy a beágyazás segítségével az egyre több kombinált protokoll széles palettájának elemzésére, szűrésére van lehetőség, valamint lehetőség van nem protokoll specifikus modul alkalmazására is. A moduláris tűzfalak másik oldala, amely általában kevésbé kerül előtérbe, ám szintén nagyon fontos, teremt lehetőséget a különleges igények kielégítésére, valamint ez veszi át az egyes proxy moduloktól a közös feladatok ellátását. Ilyen modul például a kapcsolatok fogadásáért, vagy kiépítéséért felelős modul. A proxy moduloknak nem feladata többé a kapcsolatok kezelése, csak azok forgalmának elemzése, szűrése, a kapcsolatok kezelésére külön modulok állnak rendelkezésre. Azaz egy speciális modul feladata a kapcsolatok fogadása, majd kapcsolódás esetén, a megfelelő ellenőrzések után, a kiépült kapcsolatot átadja a proxy modulnak, amely csak a forgalommal foglalkozik. Ugyanígy, ha szükség van a kapcsolat szerver oldali részére, az szükséges új kapcsolat kiépítése, akkor azt szintén nem a proxy végzi, hanem az ezért felelős modul. Az architektúra következtében így lehetőség van bizonyos esetekben például az alapértelmezettől eltérő új kapcsolat létrehozását végző modul használatára, amely a szerverhez való sikertelen kapcsolódás esetén megpróbál egy másik szerverhez kapcsolódni. Egy moduláris tűzfal segítségével lehetőség nyílik az eddigi tűzfal által megoldhatatlan problémák biztonságosabb, flexibilisebb és gyorsabb megoldására, növelve ezzel a védendő rendszer biztonságát. A modularitás révén a tűzfal képessé válik az átmenő forgalom még részletesebb értelmezésére, ezzel segítve az adminisztrátor munkáját a IBSZ hálózati határvédelemre vonatkozó szabályainak még pontosabb betartatását illetően.
Mély-protokollelemzés és content vectoring Már említettük, hogy a proxy tűzfalak alkalmazásszintű jelenlétükből kifolyólag elvileg képesek lehetnek a teljes átmenő adatforgalom elemzésére és befolyásolására. Ehhez két dolgot kell a proxy-nak teljesítenie: egyrészt ismernie kell a protokoll összes szabványos utasítását és metódusát, másrészt képesnek kell lennie a protokollban átvitt adat elemzésére. Az előbbit hívjuk mély protokollelemzésnek, míg az utóbbi a content vectoring megvalósítását jelenti.
Mély-protokollelemzés Sokak számára meglepő lehet, de hiába léteznek protokollok, azok betartását alap esetben egy hálózati eszköz sem ellenőrzi. Ez nagy teret ad a rosszindulatú támadóknak, hiszen sok hálózati eszközben és alkalmazásban vannak olyan biztonsági rések, amiket, a protokollt sértő metódusokkal ki lehet játszani.
www.balabit.com
10/13
Tűzfalak evolúciója Amennyiben a proxy alkalmazás a teljes szabványt megvalósítja, tehát ismeri az összes utasítást és attribútumot, egyfajta hálózati rendészként minden szabványt sértő kommunikációs próbálkozást megtagadhat. További előnye a mély protokollelemzésnek, hogy segítségével a tűzfal „élesebben lát”. A hálózati kommunikációban jóval részletesebben tud eseményeket megkülönböztetni egymástól, aminek következtében a reakciója is kifinomultabb lehet.
Content vectoring A tartalomelemzés tipikusan a moduláris tűzfalak sajátja. Önálló modulként épülnek be az architektúrába, így képesek valamennyi proxy-val együttműködni. A megoldandó feladat általában vírus szűrés a tartalomban. Ritkább esetben kulcsszavak alapján történő szűrés is előfordulhat.
A Zorp technológia A Zorp tűzfal egy alkalmazás szintű, moduláris proxy tűzfal, mélyprotokollelemzési képességgel. Tehát, a legújabb technológiát képviseli. A Zorp a biztonság érdekében alkalmazás szintű proxykat és csomagszűrést egyaránt alkalmaz. Proxy-jaink fejlesztésekor cél volt az átmenő forgalom minél mélyebb elemzése és ellenőrzése, valamint a lehető legjobb konfigurálhatóság. A Zorp beépített programozási nyelvvel rendelkezik, melynek segítségével az adminisztrátor megadhatja a tűzfal beállításait, illetve testre szabhatja annak működését. A szoftver magas rendelkezésre-állást biztosító High Availability (HA) illetve titkosított virtuális magánhálózat (VPN) kialakítására alkalmas modulokkal is rendelkezik.
Alkalmazás szintű átjáró A Zorp Professional a technológia jelenlegi legfejlettebb szintjét alkotó alkalmazás szintű tűzfalak családjába tartozik, így a rajta keresztülmenő forgalmat az átvitt protokollt megvalósító úgynevezett proxyk (megbízottak) ellenőrzik és továbbítják. Az alkalmazás szintű tűzfalak biztonsága azzal mérhető, hogy proxyjai milyen mélységben ellenőrzik a megvalósított protokollt. A Zorp Professional jelenleg az alábbi protokollok teljes formai elemzésére képes: FTP, HTTP, SSL, POP3, FINGER, WHOIS, NNTP, IMAP, TELNET, PRINTER, RADIUS, TFTP, LDAP, PGSQL, ORACLE NET8. Plug proxy-val bármely egy porton kommunikáló kliens szerver kapcsolat felügyelhető. (SSH, MYSQL, VNC, Microsoft Terminal Service, GOPHER, SMB/CIFS, TALK, SYSLOG, IPP, RSYNC)
Modularitás és alprotokoll elemzés Az alkalmazás szintű protokollok gyakran tartalmaznak újabb alprotokollokat. Ilyen például az e-business rendszerekben érzékeny adatok átvitele esetén gyakran használt HTTPS. A HTTPS nem más, mint egy egyszerű HTTP protokoll (melyet a World Wide Web elérésére használunk) beágyazva a titkosítást végző SSL protokollba. A konkurens tűzfal termékek nem képesek az egymásba ágyazott protokollok kontrollált átvitelére, így mindössze két lehetőségünk marad: teljes mértékben tiltjuk, vagy ellenőrzés nélkül átengedjük az adott forgalmat. A Zorp szoftver modularitása lehetővé teszi, hogy ezeket az egymásba ágyazásokat is ellenőrizzük, lévén minden proxy egy olyan modul, mely képes csatlakozni bármely más modul által kiajánlott alprotokollhoz
www.balabit.com
11/13
Tűzfalak evolúciója
Összefoglaló A fenti, igencsak rövidnek tekinthető áttekintés célja az alaptechnológiák megismertetése és a fejlődési irányvonalak felvázolása. A gyakorlatban azonban nehéz “vegytiszta” fogalmak alapján tájékozódni. A technológiák sokszor összemosódnak és helyes döntés meghozását tovább nehezíti, hogy egyfajta szándékos ködösítés veszi körbe marketing oldalról az egyes termékek technológiai hovatartozását. Így fordulhat elő, hogy dús fantázianevekkel megáldott grafikus interfésszel kibővített Linux csomagszűrőkbe ütközünk lépten-nyomon és idejét múlt koncepciókra támaszkodó megoldások láthatnak napfényt napjainkban is. A helyes döntés meghozásához vezető út saját igényeink alapos felmérésén keresztül található meg. Mérlegelnünk kell azt is, hogy az IT biztonságtechnikában a vírusvédelem, a behatolás védelem és a hálózati határvédelem külön fogalmakat jelentenek és általában külön eszközök segítségével valósítják meg feladataikat. Bármely informatikai rendszer biztonságát illetően rendkívül fontos a termék támogatása, supportja vagy távmenedzsmentje. A biztonság nem állapot, hanem folyamat. A legjobb megoldás sem képes hozzáértő kezelés nélkül valós biztonságot nyújtani. Lehetetlen felhívni minden buktatóra a figyelmet, hiszen nap-mint-nap találkozhatunk új fogalmakkal, mégis egy életből lopott példa kapcsán talán érzékelhetővé válik ezek jellege. Adott alkalmazás szintű termék rengeteg protokollt támogat a gyártó szerint, majd érdeklődésünkre megnyugtatnak minket, hogy egyébként is három kattintás egy új protokoll felvétele (ez úgy is elhangzott már, hogy pár kattintás segítségével kész az új proxy!). Ha azonban nem hívja fel a figyelmünket arra, hogy az így létrehozott proxy egy plug proxy és nem egy protokoll specifikus értelmező, merüljön fel bennünk a jogos gyanú, hogy a hosszú felsorolás is tartalmazhat nevesítve egyszerű plug proxy-kat. Jelentős különbség, hogy amennyiben egy gyártó nevesít egy proxy-t, mint egy adott protokoll proxy-ját a vevő feltevése szerint az egy, az adott protokollt értelmezni képes implementáció. Minél magasabb az értelmezés mélysége annál jobb biztonságtechnikai szempontból a proxy. A plug tehát a másik véglet, mivel ott alkalmazás szintű értelmezés nem történik és nem is történhet annak általános volta miatt. (A Plug proxy gyakran használt másik neve general proxy.) A gyártó részéről az elvárható etikus eljárás a plug proxy-val megvalósítható (általában véve bármely egycsatornás) protokollok és a specifikált protokollok szétválasztása. Tegyük fel tehát mindig a kérdést, amikor protokollelemzőkkel van dolgunk, hogy azok valójában milyen mélyen is értelmezik az adott protokollt. Végül pár pontba gyűjtve a legfontosabb felmerülő kérdések tűzfal technológiákat illetően: 1. A tűzfal csomagszűrő, vagy alkalmazás szintű?* 2. Amennyiben csomagszűrő technológia alapján dolgozik állapottartó-e, vagy sem? 3. Ha alkalmazás szintű, akkor mely proxy-k azok, melyek képesek a protokoll értelmezésére és melyek az úgynevezett általános, vagy “plug” proxy-k? 4. A protokollelemzők milyen mélyen elemzik az adott protokollt? 5. Képes-e a tűzfal biztonságosan kezelni a beágyazott protokollokat? (HTTPS) 6. A megoldás magában foglalja-e az operációs rendszer integrációját?** 7. A termék üzemeltetése során annak biztonsági frissítései magukban foglalják-e a megoldásban felhasználásra kerülő összes szoftver hibajavításait?** 8. Vannak-e valamilyen jellegű korlátozások hardver támogatásra, vagy kiépítésére vonatkozóan? 9. Mi a megoldás hardver igénye?***
www.balabit.com
12/13
Tűzfalak evolúciója * Hardver alapú tűzfal sem lehet más, mint valamelyik a kettő közül. A TCP protokoll szűrésére ezen kívül nincs más módszer, általában az, hogy egy megoldás “hardveres”, azt jelenti, hogy valamilyen speciális konfigurációra optimalizálnak egy megoldást, ezzel növelve a teljesítményt és rendelkezésre állást. Ugyanakkor pont a kötött hardver kiépítés flexibilitási problémákhoz vezet a legtöbb esetben. Bármilyen változtatás, mely a fizikai felépítését érinti ezeknek az eszközöknek többnyire költséges és erősen limitált. (Például egy új fizikai szegmens létrehozásához szükséges hálózati csatolófelület biztosítása, vagy a teljesítmény növelésének az igénye sorolható ide.)
** Minden tűzfalmegoldás valamilyen operációs rendszeren fut. Fontos, hogy ne csak a tűzfal szoftver maga, de az őt kiszolgáló operációs rendszer és minden egyéb kiszolgáló alkalmazás napra készen frissítve legyen. Bár a legritkább eset, amikor magát a tűzfalat támadják – feltehetően a védett alkalmazások kevésbe a biztonságot szem előtt tartva lettek megvalósítva, így könnyebb prédát jelentenek – a fejlesztők sok esetben a tűzfal operációs rendszerét erősen átalakítják és lecsupaszítják, hogy véletlen se lehessen rajta.“fogást találni”. Ugyanis bármennyire nehéz feladat egy tűzfal feltörése, ha az mégis sikerülne, minden akadály elhárulna a betörő elől.
*** Lényegében a hardver igény alapján a tűzfal “teljesítményére” lehet következtetni. A legszerencsésebb helyzet, ha találunk összehasonlító teszteket, melyek ugyanazon platformon és konfiguráción azonos körülmények között tesztelik különböző megvalósítások pl.: áteresztőképességét. Minél jobban teljesít adott szoftver annál jobban optimalizálva van a kódja, ami biztonság szempontjából sem mellékes. Sajnos ilyen tesztek nagyon nehezen találhatóak, többnyire nem publikusak és hozzá nem értő kezekben félreértésekre adhatnak okot. Nem következik a jobb kód optimalizáció abból, hogy egy csomagszűrő adott esetben gyorsabb egy alkalmazás szintű megoldásnál. Mindig mérlegelni kell azt is, hogy mennyi munkát végez egy program működése közben. (Egy applikációs szintű megvalósítás nagyságrenddel több adatot dolgoz fel, mint csomagszűrő társa.) Nyílván a kérdés másképp hangzik hardver alapú megoldásoknál. Ott a válasz abban merülhet ki, hogy adott célhardveren milyen teljesítményre képes tűzfal.
Kérdéseivel, észrevételeivel keresse meg cégünket az alábbi címen: BalaBit IT Security, 1116 Budapest Csurgói út 20/B Telefon: 06 1 371 0540 Fax: 06 1 208 0875 E-mail:
[email protected] Web: http://www.balabit.hu © 2005 BalaBit IT Security. Minden jog fenntartva. A dokumentumra vonatkozó jogi kitételeket a következő weboldal tartalmazza: http://www.balabit.com/products/zorp/docs/legal_notice.bbq
www.balabit.com
13/13
