Tűzfalak - Laptörténet

Pitlik, 2008. február 1., 11:33-n

2008-02-01T11:33:24Z

Pitlik: Levédte a(z) Tűzfalak lapot [edit=sysop:move=sysop]

2008-02-01T11:33:07Z

Levédte a(z) Tűzfalak lapot [edit=sysop:move=sysop]

Herher: /* Történeti Modul */

2006-12-14T12:51:49Z

‎Történeti Modul

Herher, 2006. december 14., 12:51-n

2006-12-14T12:51:04Z

Herher, 2006. december 14., 12:42-n

2006-12-14T12:42:57Z

Új lap

=Történeti Modul=
*'''1980:'''A tűzfal az 1980as évek környékén bukkant fel amikor az Internet egy egészen új technologiaként jelent meg.
*'''1988:''' ''Első generáció a csomagszűrő(Packet filter):''Az első publikált tűzfalas technológia ebben az évben jött létre, amikor Digital Equipment Corporation (DEC)-től ismertetett egy fejlett szűrő rendszert, csomagszűrő tűzfalként. Ez a felbukkant rendszer volt az első generáció.
*'''1980-1990:''' ''Második generáció(Circuit level):''1980 és 1990 között az AT&T Bell Laboratórium két munkatársa, Dave Presetto és Howard Trickey, feltalálta a második generációs tűzfalat amely '''circuit level''' tűzfal néven vált ismertté.
*''Harmadik Generáció (Application Layer) Alkalmazás szintű tűzfal:''Gene Spafford a Purdue Egyetemről, Bill Cheswick az AT&T Laboratóriumból és Marcus Ranum által kitalált harmadik generációs tűzfal: application layer tűzfal vagy másnéven proxy tűzfal.
*'''1992:''' ''Újabb generációk:''Bob Braden és Anette DeSchin a Kelet Kaliforniai Egyetemen(USC) kitalálták a negyedik geneációs csomag szűrő rendszert. A termék mint "Visas" volt az első rendszer amely rendelkezett vizuális felülettel, szinekkel és ikonokkal, amelyek végrehajtották és elfogadták a Microsoft Windows vagy az Apple MacOs-t mint operációs rendszert. 1994-ben egy Izraeli cég amelyet Check Point Software Technologies-nek hívtak, készítette el a FireWall-1 szoftvert.
*'''Proxy:'''A második generációja a proxy tűzfalaknak volt a Kernel Proxy technológia. Ez a tervezés folyamatosan fejlődik, de ez alapvetőleg tagolt és kódolt, jelenleg széleskörűen használják mind a kereskedelemben mind pedig a hazai számítógépes rendszerekben. A Cisco az egyik legnagyobb és legismertebb internetes védelmi cég a világon különösen ennek a cégnek a PIX termékük amelyet 1997-ben publikáltak.
Az új következő generációs tűzfalak hatalma a fennálló alapos csomag vizsgálat az IPS által.

=Definíciós Modul=

*'''Csomagszűrés:'''
Ha jobban belegondolunk, két helyen nyílik lehetőség a „teljes” forgalom ellenőrzésére, a felhasználó számítógépén – erre jöttek létre a személyi tűzfalak – vagy a routereknél (útválasztó). Mint a nevéből is kitűnik, a router felelős azért hogy egy csomag a megfelelő célba jusson. Legalábbis kezdetben ez volt a dolguk, de így egy új feladatot is kaptak, méghozzá a csomagok szűrését, kontrollálását és a kapcsolatok felügyeletét, hiszen ez az a „pont” amin a teljes hálózati forgalom keresztülhalad. Ezen csomagszűrési feladat elvégzésére Linux alatt az iptables nevű program nyújtja a talán legérthetőbb és legkönnyebben alkalmazható megoldást. A csomagszűrők három legfontosabb lánccal dolgoznak – ennél azért több van – ezek az input, output, valamint a forward lánc. Az input lánchoz a routerbe beérkező csomagok mennek, az outputhoz a routerből kifelé haladó, a forward lánchoz pedig a két hálózati kártya között haladó csomagok. Minden lánchoz tartoznak szabályok, amelyeket mi adunk meg valamint egy döntés, ami a csomag szabályra való illeszkedése esetén következik be, ezt szintén mi definiálhatjuk.Többféle szűrést is végezhetünk, a legtriviálisabb az IP(ez DHCP esetében problémás) illetve MAC címre való szűrés valamint a „kiegészítő információkat”(TCP flageket) is figyelembe tudjuk venni pl SYN, ACK stb… Lehetőségünk nyílik magasabb rétegbeli(pl. adatkapcsolati réteg) információk alapján is döntést hozni, pl. port alapú szűrést végezni. A legtöbb csomagszűrő lehetőséget kínál – így az iptables is – a NAT(Network Address Translation) elvégzésére (PREROUTING, POSTROUTING lánc segítségével) valamint naplózásra is. Az előbb említett NAT, tulajdonképpen a hálózati címfordítás pl. adott esetben egy cég egyetlen publikus ip címmel rendelkezik az internet felé, de a hálózat több gépe is kapcsolódik az internetre mégpedig a routeren keresztül, ami elvégzi a címfordítást, azaz kifelé minden gép egy ip cím alól „látszik”. Az egyik hátránya az, hogy nem kínál tökéletes védelmet, mivel csak a csomagok fejlécét vizsgálja és a csomagokat is „egyenként”, nincs lehetőség a [[TCP]] kapcsolat teljes felügyeletére. Az állapottartás hiánya miatt pedig problémás a több porton folyó kommunikáció kezelése mint pl. az [[FTP]] esetében.

**'''Állapottartó csomagszűrők:'''
A csomagszűrők egyik továbbfejlesztett változata az állapottartó csomagszűrők családja. Az alkalmazások fejlődése megkövetelte, hogy az ismeretlen serverekkel történő kommunikációt is biztonságosabbá lehessen tenni. Erre az elektronikus kereskedelem megjelenésével kimondottan nagy szükség volt. Az állapottartó csomagszűrők egy bizonyos ideig tárolják a beérkező csomagokat, és csak a megfelelő információ birtokában döntenek, úgy, hogy a csomagok közötti összefüggéseket is figyelembe veszik. A tűzfalnak azonosítania kell a kapcsolat kezdetét és végét és ezáltal az ezek között zajló folyamatot. Ezek alapján a kapcsolatba nem illő csomagokat tudja azonosítani. Tehát az állapottartó csomagszűrés az egész kapcsolatot képes vizsgálni, míg az előző csomagszűrési fajta „csak” magát a csomagot vizsgálta. Pédául egy TCP kapcsolat esetén nem csak az ACK flag megléte, esetleg hiánya, hanem az egész kapcsolat nyomon követése adja meg az információt a döntéshez. A vizsgálatok mélysége között alapvetőleg nincs különbség, hanem csak a kapott információ feldolgozásában. Az állapottartó csomagszűrő meg tudja különböztetni pl. a kapcsolat kiépítését kezdeményező csomagokat valamint annak lezárását kezdeményező csomagokat és már „gyanús lehet számára” ha pl. egy adat csomag megelőzi a kapcsolat kiépülését kezdeményező csomagot. Tehát ez a csomagszűrés az egész kapcsolatot képes felügyelni. Egyébként ezek a csomagszűrők is szabályláncokkal dolgoznak, elődjükhöz hasonlóan. Persze ez a megoldás sem nyújt tökéletes védelmet, gondoljunk csak arra, hogy a csomagszűréssel csak az adott csomag mintegy 5% -át – a csomag fejlécét – vizsgáljuk és a „maradék” 95% mehet tovább, adatként, ami ugye bármit tartalmazhat. A megoldást az alkalmazásszintű tűzfalak vagy proxyk megjelenése jelentette, amelyek a csomagszűrőkkel kb. egyszerre kezdtek fejlődni(párhuzamosan).

*'''Bastion Host avagy bástya hoszt:'''
A tűzfalak egy következő alternatívája a Bastion Host volt, ami igazából nem teljesen nevezhető tűzfalnak, mert ez tulajdonképpen egy server gép, amire a felhasználók be tudnak jelentkezni és az erőforrásait igénybe tudják venni, egyszerre akár több felhasználó is(multiuseres üzemmód). Tulajdonképpen két kapcsolat van, az egyik a felhasználó és a Bastion Host, a másik pedig a Bastion Host és az internetes server között. Ha a felhasználó valamit el akart érni a neten, akkor előbb be kellett jelentkeznie a Bastion Hostra és azon kezdeményezheti az erőforrás elérését. A felhasználó gépe és a server között nincs direkt csomagkapcsolat. Ez jóval megnehezíti, vagy lehetetlenné teszi a csomagszintű támadásokat. Ettől kezdve már nem a csomagra fogunk koncentrálni, hanem a kapcsolatra, a kapcsolatorientált protokollok miatt is. A tűzfalak képesek lesznek betekinteni a csomagok adat részébe is. A Bastion Host nevű megoldás egy továbbfejlesztett változata a [[Proxy]] illetve a Socks tűzfalak.

*'''A Socks tűzfalak:'''
A Socks tűzfalak valahol „középen” helyezkednek el a Proxy és a csomagszűrők között. Csomagszűrőnek nem nevezhetőek, mert a kliens és a server között nem mennek csomagok de alkalmazásszintűnek sem nevezhető mert a hálózati szintre tehető a működése. Ezen megoldások igen rövid életűek voltak. A Socks Proxy lényege az, hogy a felhsználó gépére telepítésre kerül egy program, ami átveszi a hálózati kapcsolatok kezelését az operációs rendszertől. Ha a felhasználó kapcsolódni szeretne egy serverhez, akkor ezt a telepített program intézi, oly módon, hogy kapcsolódik a Socks Proxy egy adott portjához, és „megmondja” neki, hogy mihez szeretne kapcsolódni. Majd a Proxy fog kapcsolódni a kliens által megadott serverhez. A kliens az adatforgalmát a Socks Proxyn keresztül bonyolítja. A megoldás a hálózat szempontjából nem transzparens, valamint klasszikus értelemben nem nevezhető csomagszűrőnek, mert a kliens és a server között nem „közlekednek” csomagok. Valahol a csomagszűrők fölött de az alkalmazásszintű tűzfalak alatt helyezkedik el ez a megoldás.

*'''Alkalmazásszintű tűzfalak:'''
Az alkalmazásszintű, azaz Proxy tűzfalak az első nem csomagszűrési elven működő tűzfalak között. Ez tulajdonképpen a Bastion Host rendszer továbbfejlesztett változata, a Bastion Hostra való bejelentkezésből adódó kényelmetlenségek kiküszöbölése volt az elsődleges feladata. A Proxy működési elve hasonló a Bastion Hostéhoz, a kliens gép és az internetes server között szintén nincs direkt kapcsolat, a serveren(tűzfalon) – ami két hálózati kártyával rendelkezik – fut egy proxy démon, ami kommunikál a klienssel az egyik hálózati csatolón, és az internetes kiszolgálóval a másikon. A kliens „megmondja” a Proxy-nak, hogy milyen erőforrást szeretne elérni a neten, a Proxy kapcsolódik a megadott serverhez és a kapott adatot továbbítja a kliensnek. Ez a megoldás képes kiszűrni a csomagszintű támadásokat. A Proxyk nem csak a csomag fejlécét vizsgálták, hanem képesek voltak betekinteni a csomag adat részébe is, esetleg változtattak is a csomagon. Mivel mélyebben tudja vizsgálni a csomagokat ezért nem okoz problémát a több portot használó alkalmazások tűzfalazása sem mint pl. az FTP, mert „láthatja” hogy mi lehet a következő portcím. A Proxy egyik hátránya, hogy a protokolloknak támogatniuk kell a Proxy-s működést.

**'''Transzparens Proxyk:'''
A transzparens Proxyk előnye az volt, hogy a már-már áttekinthetetlen konfigurációk helyett egy jóval egyszerűbb megoldást kínált. Az elődjével az volt a legnagyobb probléma, hogy sok alkalmazás nem támogatta, valamint a programonként változó konfigurációból adódóan egyre nagyobb volt az emberi tévedés okozta kockázat. A cél a transzparencia megvalósítása és a Proxyt nem támogató programok kezelése volt. Mivel a tűzfalon, a teljes forgalom áthalad ezért lehetőség volt a csomagszűrőhöz hasonló funkciók ellátására. A működési elve az volt, hogy a kliensen nem kellett Proxy-t beállítani hanem direktben próbáltak kapcsolódni a kiszolgálóhoz, de a tűzfal a csomagokat „elkapja” és magára irányítja. Innentől kezdve pedig úgy működött, mint a nem transzparens Proxy-k. A használata jóval kényelmesebb és rugalmasabb volt elődjénél. Azonban újabb probléma merült fel, mégpedig az összetett protokollok. Ilyen pl. a HTTPS, ami egy [[HTTP]] protokollból és egy [[SSL]] protokollból tevődik össze( pl. Neptun)Tehát muszáj volt a tűzfalak terén is előrelépni, így születtek meg a moduláris Proxyk.

**'''Moduláris Proxy-k:'''
A tűzfalak ezen vállfaja nem kényelmi okokból, hanem a biztonság növelése érdekében született meg. A moduláris Proxyk rendelkeztek a transzparens Proxy-k minden tulajdonságával, azonban a lényeges különbség az volt, hogy a transzparens Proxy-k minden protokollhoz külön komponenssel rendelkeztek, amik nem tudtak együttműködni. Ezzel ellentétben a moduláris Proxy-k programjai képesek együttműködésre, és a „felesleges” redundanciát is csökkentették(ugyanazon funkciókat több modul is megvalósított). Például a fentebb említett [[HTTPS]] protokoll egy összetett protokoll. A moduláris Proxy esetén van egy HTTP Proxy és egy SSL Proxy, amik együttműködnek. A bejövő adatokat az SSL Proxy visszafejti, majd átadja a HTTP Proxynak, ami az adatokat már „sima” http kérésnek értelmezi. Lehetőség van úgymond „beágyazásra” vagy többszintű beágyazásra is, tehát pl. a HTTPS –nél még tartalomszűrést is beiktathatunk. Azt mondhatjuk, hogy ezen tűzfaltípusokkal lehetőség nyílik az eddigi problémák rugalmasabb kezelésére, gyorsabb megoldására. Ahhoz, hogy a Proxy-k képesek legyenek a teljes átmenő forgalom elemzésére és befolyásolására, ismerniük kell az adott protokollhoz tartozó teljes utasításkészletet valamint képesnek kell lennie az átvitt adatok teljes elemzésére. Az előbbit hívjuk mély protokollelemzésnek, az utóbbit pedig content vectoringnak.
Meglepő talán, de a protokollok betartását egyik hálózati eszköz sem ellenőrzi. Mondhatjuk, hogy sajnos de minden hálózati eszközben vannak olyan biztonsági rések, amiket a protokollt „sértő” utasításokkal ki lehet játszani. Ha a Proxy ismeri a protokollra vonatkozó teljes utasításkészletet, akkor észre tudja venni a nem megfelelő utasításokat és megtagadhatja a nem szabványos kapcsolatot. A content vectoring azaz a tartalomszűrés modulként épül be, és általában víruskeresést valósítanak meg segítségével, de előfordul, hogy kulcsszavakra is szűrnek. Jelenleg a moduláris proxy-k kínálják a legmodernebb megoldást a tűzfalak közül.

=Linkek=
http://www.balabit.hu/common-dl/wps/WP_theevolutionofthefirewall_060626_hu.pdf

http://en.wikipedia.org/wiki/Firewall_%28networking%29

=Ajánlott Irodalom Modul=
''Andrew S. Tanenbaum: Számítógép Hálózatok''

''Saját történeti fordítás: http://en.wikipedia.org/wiki/Firewall_%28networking%29''

← Régebbi változat		A lap 2008. február 1., 11:33-kori változata
41. sor:		41. sor:

	''Saját történeti fordítás: http://en.wikipedia.org/wiki/Firewall_%28networking%29''		''Saját történeti fordítás: http://en.wikipedia.org/wiki/Firewall_%28networking%29''
		+
		+	[[Kategória:Lexikon_(classic)]]

← Régebbi változat	A lap 2008. február 1., 11:33-kori változata
(Nincs különbség)

@@ 4. sor: / 4. sor: @@
 *'''1980-1990:''' ''Második generáció(Circuit level):''1980 és 1990 között az AT&T Bell Laboratórium két munkatársa, Dave Presetto és Howard Trickey, feltalálta a második generációs tűzfalat amely '''circuit level''' tűzfal néven vált ismertté.
 *''Harmadik Generáció (Application Layer) Alkalmazás szintű tűzfal:''Gene Spafford a Purdue Egyetemről, Bill Cheswick az AT&T Laboratóriumból és Marcus Ranum által kitalált harmadik generációs tűzfal: application layer tűzfal vagy másnéven proxy tűzfal.
-*'''1992:''' ''Újabb generációk:''Bob Braden és Anette DeSchin a Kelet Kaliforniai Egyetemen(USC) kitalálták a negyedik geneációs csomag szűrő rendszert. A termék mint "Visas" volt az első rendszer amely rendelkezett vizuális felülettel, szinekkel és ikonokkal, amelyek végrehajtották és elfogadták a Microsoft Windows vagy az Apple MacOs-t mint operációs rendszert. 1994-ben egy Izraeli cég amelyet Check Point Software Technologies-nek hívtak, készítette el a FireWall-1 szoftvert.
+*'''1992:''' ''Újabb generációk:''Bob Braden és Anette DeSchin a Kelet Kaliforniai Egyetemen(USC) kitalálták a negyedik geneációs csomag szűrő rendszert. A termék mint "Visas" volt az első rendszer amely rendelkezett vizuális felülettel, szinekkel és ikonokkal, amelyek végrehajtották és elfogadták a [[Microsoft Windows]] vagy az [[Apple MacOs]]-t mint operációs rendszert. 1994-ben egy Izraeli cég amelyet [[Check Point Software Technologies]]-nek hívtak, készítette el a [[FireWall-1]] szoftvert.
 *'''Proxy:'''A második generációja a proxy tűzfalaknak volt a Kernel Proxy technológia. Ez a tervezés folyamatosan fejlődik, de ez alapvetőleg tagolt és kódolt, jelenleg széleskörűen használják mind a kereskedelemben mind pedig a hazai számítógépes rendszerekben. A Cisco az egyik legnagyobb és legismertebb internetes védelmi cég a világon különösen ennek a cégnek a PIX termékük amelyet 1997-ben publikáltak.
 Az új következő generációs tűzfalak hatalma a fennálló alapos csomag vizsgálat az IPS által.

@@ 11. sor: / 11. sor: @@
 *'''Csomagszűrés:'''
-Ha jobban belegondolunk, két helyen nyílik lehetőség a „teljes” forgalom ellenőrzésére, a felhasználó számítógépén – erre jöttek létre a személyi tűzfalak – vagy a routereknél (útválasztó). Mint a nevéből is kitűnik, a router felelős azért hogy egy csomag a megfelelő célba jusson. Legalábbis kezdetben ez volt a dolguk, de így egy új feladatot is kaptak, méghozzá a csomagok szűrését, kontrollálását és a kapcsolatok felügyeletét, hiszen ez az a „pont” amin a teljes hálózati forgalom keresztülhalad. Ezen csomagszűrési feladat elvégzésére Linux alatt az iptables nevű program nyújtja a talán legérthetőbb és legkönnyebben alkalmazható megoldást. A csomagszűrők három legfontosabb lánccal dolgoznak – ennél azért több van – ezek az input, output, valamint a forward lánc. Az input lánchoz a routerbe beérkező csomagok mennek, az outputhoz a routerből kifelé haladó, a forward lánchoz pedig a két hálózati kártya között haladó csomagok. Minden lánchoz tartoznak szabályok, amelyeket mi adunk meg valamint egy döntés, ami a csomag szabályra való illeszkedése esetén következik be, ezt szintén mi definiálhatjuk.Többféle szűrést is végezhetünk, a legtriviálisabb az IP(ez DHCP esetében problémás) illetve MAC címre való szűrés valamint a „kiegészítő információkat”(TCP flageket) is figyelembe tudjuk venni pl SYN, ACK stb… Lehetőségünk nyílik magasabb rétegbeli(pl. adatkapcsolati réteg) információk alapján is döntést hozni, pl. port alapú szűrést végezni. A legtöbb csomagszűrő lehetőséget kínál – így az iptables is – a NAT(Network Address Translation) elvégzésére (PREROUTING, POSTROUTING lánc segítségével) valamint naplózásra is. Az előbb említett NAT, tulajdonképpen a hálózati címfordítás pl. adott esetben egy cég egyetlen publikus ip címmel rendelkezik az internet felé, de a hálózat több gépe is kapcsolódik az internetre mégpedig a routeren keresztül, ami elvégzi a címfordítást, azaz kifelé minden gép egy ip cím alól „látszik”. Az egyik hátránya az, hogy nem kínál tökéletes védelmet, mivel csak a csomagok fejlécét vizsgálja és a csomagokat is „egyenként”, nincs lehetőség a [[TCP]] kapcsolat teljes felügyeletére. Az állapottartás hiánya miatt pedig problémás a több porton folyó kommunikáció kezelése mint pl. az [[FTP]] esetében.
+Ha jobban belegondolunk, két helyen nyílik lehetőség a „teljes” forgalom ellenőrzésére, a felhasználó számítógépén – erre jöttek létre a személyi tűzfalak – vagy a routereknél (útválasztó). Mint a nevéből is kitűnik, a router felelős azért hogy egy csomag a megfelelő célba jusson. Legalábbis kezdetben ez volt a dolguk, de így egy új feladatot is kaptak, méghozzá a csomagok szűrését, kontrollálását és a kapcsolatok felügyeletét, hiszen ez az a „pont” amin a teljes hálózati forgalom keresztülhalad. Ezen csomagszűrési feladat elvégzésére Linux alatt az iptables nevű program nyújtja a talán legérthetőbb és legkönnyebben alkalmazható megoldást. A csomagszűrők három legfontosabb lánccal dolgoznak – ennél azért több van – ezek az input, output, valamint a forward lánc. Az input lánchoz a routerbe beérkező csomagok mennek, az outputhoz a routerből kifelé haladó, a forward lánchoz pedig a két hálózati kártya között haladó csomagok. Minden lánchoz tartoznak szabályok, amelyeket mi adunk meg valamint egy döntés, ami a csomag szabályra való illeszkedése esetén következik be, ezt szintén mi definiálhatjuk.Többféle szűrést is végezhetünk, a legtriviálisabb az [[IP]](ez [[DHCP]] esetében problémás) illetve [[MAC]] címre való szűrés valamint a „kiegészítő információkat”([[TCP]] flageket) is figyelembe tudjuk venni pl [[SYN]], [[ACK]] stb… Lehetőségünk nyílik magasabb rétegbeli(pl. adatkapcsolati réteg) információk alapján is döntést hozni, pl. port alapú szűrést végezni. A legtöbb csomagszűrő lehetőséget kínál – így az iptables is – a [[NAT]](Network Address Translation) elvégzésére ([[PREROUTING]], [[POSTROUTING]] lánc segítségével) valamint naplózásra is. Az előbb említett [[NAT]], tulajdonképpen a hálózati címfordítás pl. adott esetben egy cég egyetlen publikus ip címmel rendelkezik az internet felé, de a hálózat több gépe is kapcsolódik az internetre mégpedig a routeren keresztül, ami elvégzi a címfordítást, azaz kifelé minden gép egy ip cím alól „látszik”. Az egyik hátránya az, hogy nem kínál tökéletes védelmet, mivel csak a csomagok fejlécét vizsgálja és a csomagokat is „egyenként”, nincs lehetőség a [[TCP]] kapcsolat teljes felügyeletére. Az állapottartás hiánya miatt pedig problémás a több porton folyó kommunikáció kezelése mint pl. az [[FTP]] esetében.
 **'''Állapottartó csomagszűrők:'''
-A csomagszűrők egyik továbbfejlesztett változata az állapottartó csomagszűrők családja. Az alkalmazások fejlődése megkövetelte, hogy az ismeretlen serverekkel történő kommunikációt is biztonságosabbá lehessen tenni. Erre az elektronikus kereskedelem megjelenésével kimondottan nagy szükség volt. Az állapottartó csomagszűrők egy bizonyos ideig tárolják a beérkező csomagokat, és csak a megfelelő információ birtokában döntenek, úgy, hogy a csomagok közötti összefüggéseket is figyelembe veszik. A tűzfalnak azonosítania kell a kapcsolat kezdetét és végét és ezáltal az ezek között zajló folyamatot. Ezek alapján a kapcsolatba nem illő csomagokat tudja azonosítani. Tehát az állapottartó csomagszűrés az egész kapcsolatot képes vizsgálni, míg az előző csomagszűrési fajta „csak” magát a csomagot vizsgálta. Pédául egy TCP kapcsolat esetén nem csak az ACK flag megléte, esetleg hiánya, hanem az egész kapcsolat nyomon követése adja meg az információt a döntéshez. A vizsgálatok mélysége között alapvetőleg nincs különbség, hanem csak a kapott információ feldolgozásában. Az állapottartó csomagszűrő  meg tudja különböztetni pl. a kapcsolat kiépítését kezdeményező csomagokat valamint annak lezárását kezdeményező csomagokat és már „gyanús lehet számára” ha pl. egy adat csomag megelőzi a kapcsolat kiépülését kezdeményező csomagot. Tehát ez a csomagszűrés az egész kapcsolatot képes felügyelni. Egyébként ezek a csomagszűrők is szabályláncokkal dolgoznak, elődjükhöz hasonlóan. Persze ez a megoldás sem nyújt tökéletes védelmet, gondoljunk csak arra, hogy a csomagszűréssel csak az adott csomag mintegy 5% -át – a csomag fejlécét – vizsgáljuk és a „maradék” 95% mehet tovább, adatként, ami ugye bármit tartalmazhat. A megoldást az alkalmazásszintű tűzfalak vagy proxyk megjelenése jelentette, amelyek a csomagszűrőkkel kb. egyszerre kezdtek fejlődni(párhuzamosan).
+A csomagszűrők egyik továbbfejlesztett változata az állapottartó csomagszűrők családja. Az alkalmazások fejlődése megkövetelte, hogy az ismeretlen serverekkel történő kommunikációt is biztonságosabbá lehessen tenni. Erre az elektronikus kereskedelem megjelenésével kimondottan nagy szükség volt. Az állapottartó csomagszűrők egy bizonyos ideig tárolják a beérkező csomagokat, és csak a megfelelő információ birtokában döntenek, úgy, hogy a csomagok közötti összefüggéseket is figyelembe veszik. A tűzfalnak azonosítania kell a kapcsolat kezdetét és végét és ezáltal az ezek között zajló folyamatot. Ezek alapján a kapcsolatba nem illő csomagokat tudja azonosítani. Tehát az állapottartó csomagszűrés az egész kapcsolatot képes vizsgálni, míg az előző csomagszűrési fajta „csak” magát a csomagot vizsgálta. Pédául egy TCP kapcsolat esetén nem csak az [[ACK]] flag megléte, esetleg hiánya, hanem az egész kapcsolat nyomon követése adja meg az információt a döntéshez. A vizsgálatok mélysége között alapvetőleg nincs különbség, hanem csak a kapott információ feldolgozásában. Az állapottartó csomagszűrő  meg tudja különböztetni pl. a kapcsolat kiépítését kezdeményező csomagokat valamint annak lezárását kezdeményező csomagokat és már „gyanús lehet számára” ha pl. egy adat csomag megelőzi a kapcsolat kiépülését kezdeményező csomagot. Tehát ez a csomagszűrés az egész kapcsolatot képes felügyelni. Egyébként ezek a csomagszűrők is szabályláncokkal dolgoznak, elődjükhöz hasonlóan. Persze ez a megoldás sem nyújt tökéletes védelmet, gondoljunk csak arra, hogy a csomagszűréssel csak az adott csomag mintegy 5% -át – a csomag fejlécét – vizsgáljuk és a „maradék” 95% mehet tovább, adatként, ami ugye bármit tartalmazhat. A megoldást az alkalmazásszintű tűzfalak vagy proxyk megjelenése jelentette, amelyek a csomagszűrőkkel kb. egyszerre kezdtek fejlődni(párhuzamosan).
 *'''Bastion Host avagy bástya hoszt:'''
@@ 20. sor: / 20. sor: @@
 *'''A Socks tűzfalak:'''
-A Socks tűzfalak valahol „középen” helyezkednek el a Proxy és a csomagszűrők között. Csomagszűrőnek nem nevezhetőek, mert a kliens és a server között nem mennek csomagok de alkalmazásszintűnek sem nevezhető mert a hálózati szintre tehető a működése.   Ezen megoldások igen rövid életűek voltak. A Socks Proxy lényege az, hogy a felhsználó gépére telepítésre kerül egy program, ami átveszi a hálózati kapcsolatok kezelését az operációs rendszertől. Ha a felhasználó kapcsolódni szeretne egy serverhez, akkor ezt a telepített program intézi, oly módon, hogy kapcsolódik a Socks Proxy egy adott portjához, és „megmondja” neki, hogy mihez szeretne kapcsolódni. Majd a Proxy fog kapcsolódni a kliens által megadott serverhez. A kliens az adatforgalmát a Socks Proxyn keresztül bonyolítja. A megoldás a hálózat szempontjából nem transzparens, valamint klasszikus értelemben nem nevezhető csomagszűrőnek, mert a kliens és a server között nem „közlekednek” csomagok. Valahol a csomagszűrők fölött de az alkalmazásszintű tűzfalak alatt helyezkedik el ez a megoldás.
+A Socks tűzfalak valahol „középen” helyezkednek el a [[Proxy]] és a csomagszűrők között. Csomagszűrőnek nem nevezhetőek, mert a kliens és a server között nem mennek csomagok de alkalmazásszintűnek sem nevezhető mert a hálózati szintre tehető a működése.   Ezen megoldások igen rövid életűek voltak. A Socks Proxy lényege az, hogy a felhsználó gépére telepítésre kerül egy program, ami átveszi a hálózati kapcsolatok kezelését az operációs rendszertől. Ha a felhasználó kapcsolódni szeretne egy serverhez, akkor ezt a telepített program intézi, oly módon, hogy kapcsolódik a [[Socks Proxy]] egy adott portjához, és „megmondja” neki, hogy mihez szeretne kapcsolódni. Majd a[[ Proxy]] fog kapcsolódni a kliens által megadott serverhez. A kliens az adatforgalmát a Socks Proxyn keresztül bonyolítja. A megoldás a hálózat szempontjából nem transzparens, valamint klasszikus értelemben nem nevezhető csomagszűrőnek, mert a kliens és a server között nem „közlekednek” csomagok. Valahol a csomagszűrők fölött de az alkalmazásszintű tűzfalak alatt helyezkedik el ez a megoldás.
 *'''Alkalmazásszintű tűzfalak:'''
-Az alkalmazásszintű, azaz Proxy tűzfalak az első nem csomagszűrési elven működő tűzfalak között. Ez tulajdonképpen a Bastion Host rendszer továbbfejlesztett változata, a Bastion Hostra való bejelentkezésből adódó kényelmetlenségek kiküszöbölése volt az elsődleges feladata. A Proxy működési elve hasonló a Bastion Hostéhoz, a kliens gép és az internetes server között szintén nincs direkt kapcsolat, a serveren(tűzfalon) – ami két hálózati kártyával rendelkezik – fut egy proxy démon, ami kommunikál a klienssel az egyik hálózati csatolón, és az internetes kiszolgálóval a másikon. A kliens „megmondja” a Proxy-nak, hogy milyen erőforrást szeretne elérni a neten, a Proxy kapcsolódik a megadott serverhez és a kapott adatot továbbítja a kliensnek. Ez a megoldás képes kiszűrni a csomagszintű támadásokat. A Proxyk nem csak a csomag fejlécét vizsgálták, hanem képesek voltak betekinteni a csomag adat részébe is, esetleg változtattak is a csomagon. Mivel mélyebben tudja vizsgálni a csomagokat ezért nem okoz problémát a több portot használó alkalmazások tűzfalazása sem mint pl. az FTP, mert „láthatja” hogy mi lehet a következő portcím. A Proxy egyik hátránya, hogy a protokolloknak támogatniuk kell a Proxy-s működést.
+Az alkalmazásszintű, azaz Proxy tűzfalak az első nem csomagszűrési elven működő tűzfalak között. Ez tulajdonképpen a Bastion Host rendszer továbbfejlesztett változata, a Bastion Hostra való bejelentkezésből adódó kényelmetlenségek kiküszöbölése volt az elsődleges feladata. A Proxy működési elve hasonló a Bastion Hostéhoz, a kliens gép és az internetes server között szintén nincs direkt kapcsolat, a serveren(tűzfalon) – ami két hálózati kártyával rendelkezik – fut egy proxy démon, ami kommunikál a klienssel az egyik hálózati csatolón, és az internetes kiszolgálóval a másikon. A kliens „megmondja” a Proxy-nak, hogy milyen erőforrást szeretne elérni a neten, a Proxy kapcsolódik a megadott serverhez és a kapott adatot továbbítja a kliensnek. Ez a megoldás képes kiszűrni a csomagszintű támadásokat. A Proxyk nem csak a csomag fejlécét vizsgálták, hanem képesek voltak betekinteni a csomag adat részébe is, esetleg változtattak is a csomagon. Mivel mélyebben tudja vizsgálni a csomagokat ezért nem okoz problémát a több portot használó alkalmazások tűzfalazása sem mint pl. az [[FTP]], mert „láthatja” hogy mi lehet a következő portcím. A Proxy egyik hátránya, hogy a protokolloknak támogatniuk kell a Proxy-s működést.
 **'''Transzparens Proxyk:'''
-A transzparens Proxyk előnye az volt, hogy a már-már áttekinthetetlen konfigurációk helyett egy jóval egyszerűbb megoldást kínált. Az elődjével az volt a legnagyobb probléma, hogy sok alkalmazás nem támogatta, valamint a programonként változó konfigurációból adódóan egyre nagyobb volt az emberi tévedés okozta kockázat. A cél a transzparencia megvalósítása és a Proxyt nem támogató programok kezelése volt. Mivel a tűzfalon, a teljes forgalom áthalad ezért lehetőség volt a csomagszűrőhöz hasonló funkciók ellátására. A működési elve az volt, hogy a kliensen nem kellett Proxy-t beállítani hanem direktben próbáltak kapcsolódni a kiszolgálóhoz, de a tűzfal a csomagokat „elkapja” és magára irányítja. Innentől kezdve pedig úgy működött, mint a nem transzparens Proxy-k. A használata jóval kényelmesebb és rugalmasabb volt elődjénél. Azonban újabb probléma merült fel, mégpedig az összetett protokollok. Ilyen pl. a HTTPS, ami egy [[HTTP]] protokollból és egy [[SSL]] protokollból tevődik össze( pl. Neptun)Tehát muszáj volt a tűzfalak terén is előrelépni, így születtek meg a moduláris Proxyk.
+A transzparens Proxyk előnye az volt, hogy a már-már áttekinthetetlen konfigurációk helyett egy jóval egyszerűbb megoldást kínált. Az elődjével az volt a legnagyobb probléma, hogy sok alkalmazás nem támogatta, valamint a programonként változó konfigurációból adódóan egyre nagyobb volt az emberi tévedés okozta kockázat. A cél a transzparencia megvalósítása és a Proxyt nem támogató programok kezelése volt. Mivel a tűzfalon, a teljes forgalom áthalad ezért lehetőség volt a csomagszűrőhöz hasonló funkciók ellátására. A működési elve az volt, hogy a kliensen nem kellett Proxy-t beállítani hanem direktben próbáltak kapcsolódni a kiszolgálóhoz, de a tűzfal a csomagokat „elkapja” és magára irányítja. Innentől kezdve pedig úgy működött, mint a nem transzparens Proxy-k. A használata jóval kényelmesebb és rugalmasabb volt elődjénél. Azonban újabb probléma merült fel, mégpedig az összetett protokollok. Ilyen pl. a [[HTTPS]], ami egy [[HTTP]] protokollból és egy [[SSL]] protokollból tevődik össze( pl. Neptun)Tehát muszáj volt a tűzfalak terén is előrelépni, így születtek meg a moduláris Proxyk.
 **'''Moduláris Proxy-k:'''
-A tűzfalak ezen vállfaja nem kényelmi okokból, hanem a biztonság növelése érdekében született meg. A moduláris Proxyk rendelkeztek a transzparens Proxy-k minden tulajdonságával, azonban a lényeges különbség az volt, hogy a transzparens Proxy-k minden protokollhoz külön komponenssel rendelkeztek, amik nem tudtak együttműködni. Ezzel ellentétben a moduláris Proxy-k programjai képesek együttműködésre, és a „felesleges” redundanciát is csökkentették(ugyanazon funkciókat több modul is megvalósított). Például a fentebb említett [[HTTPS]] protokoll egy összetett protokoll. A moduláris Proxy esetén van egy HTTP Proxy és egy SSL Proxy, amik együttműködnek. A bejövő adatokat az SSL Proxy visszafejti, majd átadja a HTTP Proxynak, ami az adatokat már „sima” http kérésnek értelmezi. Lehetőség van úgymond „beágyazásra” vagy többszintű beágyazásra is, tehát pl. a HTTPS –nél még tartalomszűrést is beiktathatunk. Azt mondhatjuk, hogy ezen tűzfaltípusokkal lehetőség nyílik az eddigi problémák rugalmasabb kezelésére, gyorsabb megoldására. Ahhoz, hogy a Proxy-k képesek legyenek a teljes átmenő forgalom elemzésére és befolyásolására, ismerniük kell az adott protokollhoz tartozó teljes utasításkészletet valamint képesnek kell lennie az átvitt adatok teljes elemzésére. Az előbbit hívjuk mély protokollelemzésnek, az utóbbit pedig content vectoringnak.
+A tűzfalak ezen vállfaja nem kényelmi okokból, hanem a biztonság növelése érdekében született meg. A moduláris Proxyk rendelkeztek a transzparens Proxy-k minden tulajdonságával, azonban a lényeges különbség az volt, hogy a transzparens Proxy-k minden protokollhoz külön komponenssel rendelkeztek, amik nem tudtak együttműködni. Ezzel ellentétben a moduláris Proxy-k programjai képesek együttműködésre, és a „felesleges” redundanciát is csökkentették(ugyanazon funkciókat több modul is megvalósított). Például a fentebb említett [[HTTPS]] protokoll egy összetett protokoll. A moduláris Proxy esetén van egy [[HTTP Proxy]] és egy [[SSL Proxy]], amik együttműködnek. A bejövő adatokat az [[SSL Proxy]] visszafejti, majd átadja a HTTP Proxynak, ami az adatokat már „sima” http kérésnek értelmezi. Lehetőség van úgymond „beágyazásra” vagy többszintű beágyazásra is, tehát pl. a HTTPS –nél még tartalomszűrést is beiktathatunk. Azt mondhatjuk, hogy ezen tűzfaltípusokkal lehetőség nyílik az eddigi problémák rugalmasabb kezelésére, gyorsabb megoldására. Ahhoz, hogy a Proxy-k képesek legyenek a teljes átmenő forgalom elemzésére és befolyásolására, ismerniük kell az adott protokollhoz tartozó teljes utasításkészletet valamint képesnek kell lennie az átvitt adatok teljes elemzésére. Az előbbit hívjuk mély protokollelemzésnek, az utóbbit pedig content vectoringnak.
 Meglepő talán, de a protokollok betartását egyik hálózati eszköz sem ellenőrzi. Mondhatjuk, hogy sajnos de minden hálózati eszközben vannak olyan biztonsági rések, amiket a protokollt „sértő” utasításokkal ki lehet játszani. Ha a Proxy ismeri a protokollra vonatkozó teljes utasításkészletet, akkor észre tudja venni a nem megfelelő utasításokat és megtagadhatja a nem szabványos kapcsolatot. A content vectoring azaz a tartalomszűrés modulként épül be, és általában víruskeresést valósítanak meg segítségével, de előfordul, hogy kulcsszavakra is szűrnek. Jelenleg a moduláris proxy-k kínálják a legmodernebb megoldást a tűzfalak közül.