Előző cikkemben már megvizsgáltam egy megfelelően felépített vállalati védelmi rendszer elemeit, azok funkcióit és szerepüket. Ennek a rendszernek az egyik emblematikus eleme a tűzfal. Itt is - mint minden egyéb védelmi eszköznél - többféle technológiával találkozhatunk. Lássuk, mit tudnak ezek!
A kezdetek
Ez egyetemi hálózatok világában (harmincnál is több évvel ezelőtt) még senki nem gondolt arra, hogy a felhasználóknak rossz szándéka is lehet. A tervezésnél az egyetlen siker kritérium az volt, hogy működjön a rendszer, ezért kizárólag az üzemeltetés során felmerülő hibákra koncentráltak (elveszett csomagok, megszakadt kapcsolatok). Idővel azonban a rendszer felhasználóinak száma túllépte a kritikus tömeget, amely méretes bázis ellenőrizhetetlenné vált. Tudjuk: az anonimitás az emberekből nem mindig a legjobbat hozza elő.
Az első, ilyen védelmi berendezések a bástyák voltak (angolul bastion host vagy dual-homed-hostnak hívták, ma inkább a jumphost használatos). Ezek a gépek több hálózati csatolóval rendelkeztek, és ha egy felhasználó egy másik hálózaton szeretett tevékenykedni, egyszerűen csak belépett ide, hogy innen futtatva a kliens alkalmazást a másik kiszolgáló szolgáltatását vegye igénybe. Ez a megoldás többé-kevésbé működött, bár kényelmetlen volt a használata és a karbantartása is.
A routerek feladata a csomagok továbbítása volt hálózatok között. Így felmerült a kérdés: mi lenne, ha ezek az eszközök döntéseket is hozhatnának, hogy mit továbbítanak. Az ilyen routerek lettek a csomagszűrő tűzfalak. Az eszközt egy olyan postáshoz lehetne hasonlítani, amelyik a levél feladója és címzettje alapján hozhat döntést, hogy ki-kivel levelezhet. A csomagszűrők ACL rendszerei pontosan így működnek. Forrás IP és port, cél IP és port végül az alkalmazott transzport protokoll alapján. Valamint egyes fejléc elemeket is vizsgálat alá vonnak. Ennek az eszköznek a továbbfejlesztett változata az állapottartó csomagszűrő. Ez észreveszi a kapcsolatot az egyes csomagok között, azaz a kapcsolatot, nem az egyes csomagokat engedi át. De továbbra is vak az alkalmazási szintre. Neki teljesen mindegy, hogy a TCP/80-as porton HTTP vagy SSH szerver fut-e. Lényeg, hogy a hálózati kapcsolat megfeleljen a szabályoknak.
Nézzük az alkalmazást is
A bastion hostok ugyan kényelmetlenek voltak, ám ha messzebbről nézzük, végül az alkalmazási szinten érvényesítették a szabályokat (több esetben a bastion hostok iránymutatónak bizonyultak a tűzfal fejlesztéseknél).
Ki tapasztalta már például, hogy a Skype vagy az ICQ rendre kifog a tűzfalakon és akkor is kiutat talál, ha nincs engedélyezve? Az ilyen esetek megoldására találták ki a proxy tűzfalakat (a példa kicsit erőltetett, mert proxy-k hamarabb léteztek az itt említett alkalmazásoknál). Lényeg, hogy a bastion hostok nem routeolnak. Tehát nincs közvetlen kapcsolat a hálózatok között. A proxy tűzfal is ezt csinálja. A kliens kapcsolat végeztével eljátssza, hogy egy szerver, illetve a szerver felé azt, hogy ő a kliens. A klasszikus man-in-the-middle (MITM) esete. Majd a proxy elemzi, hogy a kliens és a szerver az adott protokoll előírásait betartja-e. Megfelelő kérések és válaszok mennek az előre meghatározott sorrendben és attribútumokkal. Így kikényszerítve a kívánatos protokoll használatot.
A rejtjelezett protokollok elterjedésével azonban már kevésbé volt hatékony a proxy használat. Amely okból a titkosított csatornák ellenőrzése fontossá vált. Proxy-k esetében ez megoldható volt, egyszerűen azok összekötésével. Egy proxy az SSL csatornát végződteti, majd az adatforgalmat átadja egy másik csatorna számára. A nem moduláris protokollelemzők pedig SSL ellenőrzési képességekkel lettek felruházva. Tehát a proxy-technológia lépést tartott a korral.
Egy furcsa szerzet
A tűzfalak egyik kiegészítőjének szánták a SOCKS szervereket. Ilyenkor a kliens közvetlenül nem kapcsolódhat a szerverhez, erre meg kell kérnie a SOCKS "tűzfalat". Ehhez egy egyszerű protokollt használtak, mely az alkalmazási és a transzport réteg közé épül be. Itt lelhetjük fel a bastion hostoktól ellesett másik technikát, a felhasználók azonosítását. Ugyanis a SOCKS szerverre csak azonosított felhasználók léphetnek be, pontosan úgy, mint akár a bastion hostra. Viszont a SOCKS önmagában más védelmet nem nyújt, így azt feltétlenül valamilyen másik tűzfal technológiával ajánlatos alkalmazni.
A szabályrendszer alapjai
Az eddigi tűzfalak esetében - a SOCKS-ot kivéve - a szolgáltatás igénybevételének feltétele az volt, hogy a felhasználó megfelelő IP címmel rendelkezzen. Ez manapság édes-kevés. Egyetlen IP-ről több felhasználó is érkezhet, DHCP esetén pedig minden bekapcsoláskor más és más IP címet kapunk a rendszertől. Erre tűzfal szabályokat nem lehet alapozni, mert minden valamire való rendszerben a jogosultságokat felhasználóknak adnak, nem IP címeknek. Azért, mert a főnök gépe elé ülök, még nem kéne megkapnom az ő jogosítványait. Ennek első megoldása a fent említett bastion és SOCKS rendszerek. A SOCKS azért is jó megoldás, mert szépen beilleszthető a vállalat autentikációs infrastruktúrájába, ezzel is kihasználva az SSO (Single Sign On) lehetőségeit. Ugyanezt valósítják meg ma már a modern tűzfal technológiák is, de mivel nem rendelkeznek az adott protokollokban hellyel (kivétel a HTTP és FTP), hogy a felhasználókat két ponton (a tűzfalon és a szerveren is) azonosítják, ezért trükkökhöz kell folyamodni.
Ilyenkor valamilyen kliens oldali alkalmazást (úgynevezett agent-et) telepítenek, vagy pedig valamilyen (általában web alapú) felületen kell engedélyeznünk a kapcsolatunkat. Ez akár nevezhető kétfaktoros autentikációnak is, amennyiben szervereket védünk.
A tartalom
A másik kritikus kérdés a tartalom. Kezdetben a tartalom szűrését kizárólag kliens oldalon oldották meg. A piac tele van különféle, a desktop gépekre telepíthető vírus és spam-szűrési lehetőségekkel. Ezek központi menedzsmentje számos esetben megoldott. Minél nagyobb egy hálózat, annál nehezebb a fájdalommentes üzemeltetés megvalósítása.
Természetesen ez nem jelenti a desktop megvalósítások végét vállalati környezetben sem, csupán azt, hogy a desktop védelem többé már nem elég. Az irány, hogy a tartalomszűrést azokon a kevés számú pontokon kell megvalósítani, ahol a felhasználónak nincs arra ráhatása: spam- és vírus-szűrés a fájl és levelező szervereken. A másik megoldás az úgynevezett viruswallok alkalmazása. Ezek olyan szerverek, amik az áthaladó forgalomban képesek a kártékony kódokat kiszűrni. Ezt szerencsére egy tűzfal is meg tudja valósítani. A proxy tűzfalak az értelmezett protokollból az adat részt átadják egy vírus és tartalomszűrő modulnak. Akár titkosított csatornákon belül is.
A jövő
Az eddigi megoldások, ha különféle módokon is, de a protokollok betartását ellenőrizték, nem a felhasználás módját. A világ azonban nagyot változott. Az internet elsődleges protokollja a HTTP(S) lett: webmailek, alkalmazások mind-mind ezt a protokollt használják. Az IT biztonsági vezetők pedig azt akarják szabályozni, hogy a felhasználók milyen alkalmazásokat indíthatnak. Vannak már olyan tűzfalak, amik ezt a funkciót szolgáltatják. Valószínű, hogy a tűzfalak fejődési iránya ez lesz.
Összegzésként láthatjuk tehát, hogy számos tűzfal technológia található a piacon. Jó tudni, hogy melyik milyen megoldásokat használ. Fontos megjegyezni, hogy az itt felsorolt védelmi eszközök közül nem csak egyet-egyet kell, vagy szabad használni. Minél több eszközünk van, annál kisebb a valószínűsége annak, hogy valaki kijátssza azt.
Höltzl Péter
Balabit IT Security
Szakértőnk korábbi cikkei
- Hálózatbiztonság: nincs tökéletes védelem!
- Mi történik a tűzfal mögött
