Szilard@BalaBit

Posts Tagged ‘TLS’

Mire jó a Zorp?

szerda, február 8, 2012 @ 09:02 DE. Author: Pfeiffer Szilárd

Ha egy marketing anyag sorai közé tévedt volna a nyájas olvasó, a fent megfogalmazott költő kérdésre a válasz bizonnyal az lenne; mindenre. Így viszont némi szerénységet felmutatva szűkítjük ezt a halmazt belátva, hogy a Zorp közel sem mindennek a teteje, viszont minden funkcióban segítségünkre lehet, ami a mély protokollelemző proxy tűzfal varázsos meghatározás alapján elvérható. Lássuk mik lennének ezek.

Hozzáférés-vezérélés

A proxy szerverek ezen alapvető funkciója esetén a Zorp annyiban különleges, hogy itt is el tud szakadni az alacsonyabb ISO/OSI rétegektől. Míg más eszközöknél csak a hálózati réteg attribútumai –IP címek, illetve alhálózatok– segítségével szabályozhatjuk a szolgáltatásokhoz való hozzáférést, addig a Zorp egy saját rendező mechanizmusa alapján. Ez a zóna, ami alhálózatok szabadon csoportosítható halmazát jelenti, melyek fába szervezhetőek. A zónastruktúra szintje között a szolgáltatások elérésének szabályai öröklődnek, de kivételek is megadhatóak, így egy IP alhálózatoktól független adminisztratív hierarchia hozható lére, ami nem a hálózati eszközeink elrendezését, hanem a hozzáférés szabályait tükrözi.

A kik mellett a hozzáférés-vezérlési rendszer megalkotásakor a mit és a hogyan kérdéseire is választ kell adnunk, vagyis nem csak az határozandó meg, hogy kik számára érhetőek el az erőforrások, hanem azt is, hogy milyen feltételek mellett. Lehet szó egész egyszerűen csak arról, hogy egy szerver elérése esetén minden egyes végrehajtott műveletről bejegyzés készül a rendszernaplóba. Vagy tilthatjuk például a szerver, illetve a kliens olyan funkcióit, melyek inkompatibilitást okoznak. Szűrhetjük a protokoll némely elemeit, módosíthatjuk azok értékeit, hogy elkerüljük érzékeny adatok kiszivárgását. Ellenőrizhetjük az adattartalom vírusmentes mivoltát. Kibonthatjuk, majd visszacsomagolhatjuk a forgalmat védő titkosítást. Ebből adnak ízelítőt a következő fejezetek.

Adatszivárgás megelőzése

Számos protokoll esetén léteznek olyan –egyébiránt teljesen szabályos, következésképp a tűzfalak által alapvetően nem szűrt, vagy tiltott– protokollelemek, melyek a kliensen futó szoftverekről, esetleg annak hálózati beállításairól szivárogtatnak ki adott körülmények között érzékeny információkat. Erre példa a user-agent mező –egyebek mellett– a HTTP protokoll fejlécében, ahol is ennek értéke a használt böngésző típusa, illetve verziója, mely akaratunkon kívül jut el az általunk éppen meglátogatott webszerverhez.

Ehhez közel azonos módon szolgáltathatja ki a böngésző a proxy beállításokat, gépünk IP címét, vagy épp az előzőleg látogatott oldal (amiről az adott szerverre jutottunk) URL-jét. Ehhez hasonló megoldások azonban nem csak a HTTP protokollban szerepelnek, hanem másutt is, melyekről érdemes tudni és adott esetben érdemes őket tiltani. Erre a Zorp könnyen használható és rugalmas megoldást ad.

Interoperabilitás

A fenti példánál maradva a böngésző típusának nem csak az elrejtése lehetséges, de a ”meghamisítása” is, ami az interoperabilitás megteremtéséhez annyiban segít minket hozzá, amennyiben találkozunk azzal az –egyébiránt egyre ritkábban előforduló– esettel, amikor is egy webszerver annak ellenére is kikötést tesz a böngésző típusára, hogy erre érdemben alátámasztható oka nincs. Az ilyen helyzet könnyedén feloldható azáltal, hogy a böngésző által küldött user-agent mező értékét úgy változtatjuk meg, hogy az a webkiszolgáló számára elfogadható legyen.

Éppúgy kellemetlenségeket okozhat bizonyos –általában nem mai keletű– szoftvereknél a titkosított forgalom kezelésének hiánya, főként ha egy nem megbízható hálózaton keresztük kell átjuttatnunk az adatokat. Erre a helyzetre természetesen számos megoldás létezik, ugyanakkor ha problémát megfejeljük azzal, hogy a forgalmat egy tűzfalon is szeretnénk keresztül vezetni, akkor válik igazán hasznossá a Zorp azon szolgáltatása, mely alkalmassá teszi a kliens és a szerver irányába más titkosítási metódus (TLS, SSL) használatára. Ennek szélsőséges esete, amikor a Zorp csak az egyik –megbízhatatlannak tartott– irányba végez titkosítást, míg a másik –megbízhatónak vélt– irányba nem.

Fentiekhez nem feltétlenül elegendő csupán a titkosított csatornák kiépítésének, valamint újraépítésének képessége, lévén a protokoll részeként is kezdeményezhető titkosított kapcsolat kiépítése, ami az interoperabilitás egy újabb területére, a funkciók elrejtésére vezet át minket. Amennyiben azt szeretnénk, hogy bizonyos –mind a kliens mind a szerver által ismert– funkciók ne legyenek elérhetőek –mondjuk valamilyen inkompatibilitási probléma miatt– ezt is módunkban áll a Zorp segítségével megtenni.

A titkosítási példát tovább gördítve adott a lehetőség, hogy az SMTP protokoll feature listájából, kiemeljük a STARTTLS elemet, ami megakadályozza, hogy a kliens és a szerver ilyen módon kommunikáljanak egymással. Az SSL beállítások egyes kombinációinál –például ha a szerver irányába kötelező az SSL– azt a Zorp automatikusan megteszi.

Tartalomszűrés

Nincsen tűzfal tartalomszűrés nélkül. A szabály alól a Zorp sem kivétel, még akkor sem, ha a Zorp önmagában korlátozottan alkalmas is ezen feladat ellátására. A hangsúly az önmagában kifejezésen van, hiszen kiegészítve egyéb eszközökkel, mint vírus-, spam-, URL szűrő, a Zorp, mint suszter, maradhat a kaptafánál, vagyis nem tesz egyebet, mint értelmezi az adott protokollt, ennek segítségével kiemeli a hálózati forgalomból azt a részt (URL, letöltendő fájl, levél, …), melyet továbbadva a alkalmas szoftvernek (pl: ClamAV, SpamAssassin, …), annak visszajelzése alapján döntést hozhat, hogy visszautasítja, átengedi, karanténba helyezi, vagy csak naplózza az eseményt függően akár más beállításoktól, vagy a forgalom egyéb körülményeitől. Ehhez nem kell egyebet tennünk, mint egy illesztőprogramot helyezni tűzfalunk és az általunk választott tartalomszűrést biztosító eszköz közé, mely tudatja előbbivel az utóbbi által megállapítottak alapján hozott döntést.

Audit

Egy hálózat adminisztrációja során az erőforrások elérését szabályozó rendszer felállítása csupán az első lépés, ennek a rendszernek a felügyelete adja a munka nagyobb részét, melyből a szabályok fejlesztése, átalakítása következik majd. Mindenekelőtt azt kell megtudnunk, mi az ami a hálózatunkban aktuálisan zajlik. Egyrészről mik azok az események, amik a megalkotott szabályrendszer áthágására irányultak. Másrészről az engedélyezett akciók közül melyek következtek be és milyen formában. A Zorp mindkét típushoz tartozó eseményekről bejegyzéseket ír a rendszernaplóba.

Az utóbbi eset az, ahol az applikációs szintű protokollelemzésnek hasznát láthatjuk, hiszen az egyes protokollok parancsainak szintjén van módunk rálátást szerezni a hálózatban zajló eseményekre, illetve rögzíteni azokat a rendszernaplóba. Ennek mind belső, mind külső audit során komoly hasznát vehetjük, hiszen –a naplózás megfelelő beállításai mellett– igazolható, hogy mely események történtek meg és melyek nem egy adott időszakban. Emellett természetesen forgalmi-, illetve eseménystatisztikák alapjául szolgálhatnak ezek a naplóbejegyzések.

Flexibilitás

Az eddig leírtak kész, vagy legalábbis félkész megoldásként a Zorp részét képezik, ugyanakkor a Zorp erejét épp az adja, hogy szabadon és rugalmasan bővíthető saját céljaink szerint. Ehhez a Zorp azon sajátosságát használhatjuk ki, hogy a már meglévő eszközöket (proxyk) könnyen újrahasznosíthatjuk, vagyis a az egyes protokollelemzőket nem kell újra megírnunk, elegendő azok Python nyelvű változatait újra felhasználva csak a szükséges kiegészítéseket megtenni. Még abban az esetben is igaz ez, ha teljes egészében magunk kívánjuk a hálózati forgalmat feldolgozni –amit egyébiránt megtehetünk úgy is, hogy hozzá megírjuk a alkalmas C nyelvű proxyt–, mivel létezik egy erre a célra szolgáló Python osztály (AnyPy). Minden, ami az OSI modell alsóbb rétegeiben zajlik, implementált a proxyban, nekünk csak az ezen felüli –leginkább az alkalmazási– réteg részleteire kell koncentrálnunk.

A Zorp kipróbálásához, teszteléséhez “kulcsrakész” virtuális gépek itt érhetőek el.

A hivatalos Zorp GPL oldal itt található.

A blog bejegyzés, illetve a kapcsolódó videó a Creative Commons “Nevezd meg! – Így add tovább!” licenc feltételei mellett terjeszthető.

Mi az a Zorp?

kedd, január 24, 2012 @ 02:01 DU. Author: Pfeiffer Szilárd

Tömören fogalmazva a Zorp egy nyílt forrású mély protokollelemző proxy tűzfal, ami roppant tudományosan hangzik. Vegyük sorra a mágikus kifejezés kulcsszavait és próbáljuk meg értelmezni őket!

Protokoll elemzés

Funkciójukból fakadóan a tűzfal alkalmazás mindegyike képes a hálózati forgalom bizonyos mérvű elemzésére, lévén ennek hiányában nem tudnánk a forgalom szabályozására vonatkozó feltételeket megadni. Ez a Zorp esetén sincs másképp. A különbség az egyes szoftverek között az elemzés mélységében mutatkozik meg. Míg például az Netfilter esetén az oly sokat emlegetett ISO/OSI modell negyedik – azaz szállítási – rétegén túli elemeket nemigen használhatjuk fel a hálózati forgalom szabályozásánál, addig a Zorp esetén akár a legfelső – azaz az alkalmazási – réteget górcső alá véve is hozhatunk döntéseket. A döntés vonatkozhat a szolgáltatás egészére, vagyis tilthatjuk, vagy engedélyezhetjük például egy FTP szerver teljes elérését a felhasználó egy csoportja számára, de lehet szó arról is, hogy letölteni engedünk, feltölteni viszont már nem és a előbbit is csak akkor, hogy ha a letöltendők vírusmentesnek bizonyultak.

Proxy tűzfal

Csaknem minden ami ezen kifejezésről eszünkbe juthat, igaz a Zorp kapcsán is. Elsőként mindenképpen a proxy szerverek azon sajátossága, hogy beékelődnek a kliens és a szerver közé elszeparálva ezáltal a hálózati kommunikáció két szereplőjét egymástól és minden egyes kérést, illetve választ újrafogalmaznak a két szereplő között. A Zorp ebben a tekintetben annyival több versenytársainál, hogy mindezt applikáció szinten tudja megtenni, a felhasználás különböző módjai (forward proxy, reverse proxy) mellett. Ehhez szükségesek a C nyelven implementált, viszont Python nyelven konfigurálható, bővíthető protokollelemző osztályok (a Zorp terminológiájában proxy), melyekből a nyílt forrású változat esetén kilenc, míg a kereskedelmi verzióban huszonöt áll rendelkezésre.

Modularitás szerkezet

A Zorp kétség kívül legnagyobb előnye a testreszabhatóság, ami a szoftver szerkezetének moduláris felépítése nélkül nem volna lehetséges. A mindennapi használat során ez annyit jelent, hogy ha nincs szükségünk egy adott proxy kapcsán speciális működésre, akkor gyakorlatilag szinte semmit nem kell tennünk azért, hogy élvezhessük a hálózati protokoll applikációs szintig történő elemzését. Ha viszont ennél többre van igényünk, kontrollálni kívánjuk az adott forgalmat, akkor is csak arra kell összpontosítanunk, amit konkrétan elérni szeretnénk (pl: egy HTTP header módosítása), minden egyebet készen kapunk. Ezeken túl viszont arra is van lehetőség, hogy a Zorp csak a hálózati kapcsolatot kezelje és a protokoll teljes elemzését magunk végezzük függetlenül a gyárilag meglévő proxyktól.

A szállítási rétegben megvalósított biztonsági protokollok (SSL/TLS) implementációja egy önálló alrendszert, ha úgy tetszik modult képez, így az ezekhez kapcsolódó beállítások a konkrét applikációs protokolltól függetlenül tehetőek meg, ami lehetőséget biztosít arra is, hogy egy általunk implementált protokollértelmező SSL kapcsolaton belül és kívül egyaránt működhessen. A Zorp alkalmas külső eszközökhöz, modulokhoz való integrációra is, melynek lévén viszonylag könnyen valósíthatóak meg spam-, illetve vírusszűrő megoldások.

Nyílt forrás

A Zorp egy alapvetően nyílt forrású termék, ám néhány kérdést mégis érdemes tisztázni, ha más nem, a licenchuszárok kedvéért. Egyrészről, hogy a szerzői jogi védelem pontosan milyen formájáról van szó, másrészről, hogy kizárólagos-e ez a licencelés. Az első kérdésre kettős válasz adható, lévén a Zorp is két összetevőre oszlik, magára a tűzfal applikációra, illetve egy hozzá kapcsolódó függvénykönyvtárra. Mindkettő az FSF által kiadott licenc – ez előbbi (Zorp) GPL, míg az utóbbi (libzorpll) LGPL – hatálya alatt érhető el. A második kérdésre adott válasz egy kifejezésben foglalható össze; dual-license, vagyis létezik egy nyílt forrású (Zorp/Zorp GPL), illetve egy kereskedelmi (Zorp Professional) változat, a megfelelő licencelési, illetve számos technikai különbséggel, melyekről később még esik szó.

A Zorp kipróbálásához, teszteléséhez “kulcsrakész” virtuális gépek itt érhetőek el.

A hivatalos Zorp GPL oldal itt található.

A blog bejegyzés, illetve a kapcsolódó videó a Creative Commons “Nevezd meg! – Így add tovább!” licenc feltételei mellett terjeszthető.