Stateful inspection mehanizam je naprednija verzija paket filtra jer poput njega presre�e sav promet, te ga propu�ta ili odbacuje na temelju predefiniranih pravila. Me�utim, velika je razlika u tome �to paket filtar provjerava pakete samo na network i transport razini OSI modela, tj. na temelju informacija izvu�enih iz IP i TCP/UDP zaglavlja, dok stateful inspection analizira vi�e podataka. Ideja stateful inspection mehanizma je da je ispitivanje paketa izoliranih od ostatka komunikacije nedovoljno, te da se mora obavljati u �irem kontekstu kako bi se mogle donijeti kriti�ne sigurnosne odluke.

Ispitivanje �ireg konteksta se odnosi na:
a) analiziranje svih komunikacijskih razina iz kojih se izvla�e va�ni podaci o vezi, komunikacijskom stanju i aplikaciji
b) informacije dobivene od prija�njih komunikacijskih veza, na primjer PORT izlazna naredba FTP komunikacije se mo�e pohraniti kako bi se ulazna FTP podatkovna veza mogla verificirati
c) informacije dobivene od drugih aplikacija, na primjer, propu�ta se predefinirana vrsta prometa za korisnika, �iji je identitet prethodno provjeren, ovisno o njegovim predefiniranim pravima
d) manipuliranje kombinacijama informacija dobivenih na prethodna tri na�ina.

Pomo�u gore navedenih analiza informacija stateful inspection mehanizam mo�e rije�iti probleme UDP i RPC protokola. UDP protokol je te�ak za filtriranje jer nema razlike izme�u zahtjeva i odgovora, odnosno ne uspostavlja se veza. Kako je svaki paket UDP protokola sam za sebe, prije stateful inspection mehanizma problem sa UDP paketima se uglavnom rje�avao tako da su se prema definiciji odbacivali ili pak potpuno prihva�ali, �to je jako lo�e za sigurnost mre�e. Stateful inspection mehanizam mo�e osigurati UDP bazirane aplikacije tako �to odr�ava virtualnu vezu nad UDP komunikacijom. Svaki paket s UDP zahtjevom koji je propu�ten kroz vatrozid se pohranjuje, pa se UDP paketi koji putuju u suprotnom smjeru verificiraju na temelju pohranjenih UDP zahtjeva. Paketi koji odgovaraju na zahtjev se propu�taju, a ostatak se odbacuje. Po�eljni dodatak je i vremenska dimenzija koja omogu�uje definiranje maksimalnog vremena unutar kojeg mora sti�i odgovor na zahtjev ili se vi�e ne propu�ta. Komplikacija s RPC baziranim uslugama je �to se ne koriste predefinirani portovi ve� se dinami�ki alociraju. Stateful inspection mehanizam mo�e i RPC bazirane usluge osiguravati pohranjivanjem konteksta iz prethodne komunikacije.
Za razliku od do sada spomenutih vatrozidnih mehanizama, paket filtra i stateful inspectiona, application level proxy ne koristi generalno isti princip za sav promet koji kroz njega prolazi. Application level proxy je vatrozidni mehanizam koji se sastoji od skupina kodova napisanih posebno za svaku pojedinu aplikaciju. To zna�i da �e vatrozid propustiti komunikaciju odre�ene aplikacije samo u slu�aju da sadr�i specijalizirani program za tu aplikaciju. Takav program za jednu aplikaciju se naziva proxy usluga i sastoji se od poslu�itelja i klijenta. Kada do vatrozidnog sustava s application level proxyjem do�u paketi neke aplikacije, vatrozid �e u slu�aju da sadr�i potrebnu proxy uslugu, otvoriti novu vezu prema pravom odredi�tu prido�lih paketa ako ti paketi zadovoljavaju predefinirane uvjete. Ako ne zadovoljavaju, ili vatrozidni sustav ne sadr�i potrebnu proxy uslugu, paketi se odbacuju.
Na primjer, korisnik se �eli telnet aplikacijom spojiti na neki poslu�itelj na Internetu, pritom korisnikov promet mora pro�i kroz vatrozidni sustav s application level proxyjem. Da bi to bilo mogu�e, vatrozid mora sadr�avati telnet proxy uslugu. Korisnik pokre�e telnet klijent program koji se spaja na telnet poslu�itelj, koji je dio telnet proxy usluge vatrozidnog sustava. Taj telnet poslu�itelj pokre�e telnet klijent program, koji je tako�er dio telnet proxy usluge vatrozidnog sustava, koji se spaja sa �eljenim telnet poslu�iteljem na Internetu. Proxy usluga prima pakete jedne i druge telnet veze, analizira njihova zaglavlja i sadr�aj, te ako zadovoljavaju pravila prenosi ih iz jedne telnet veze u drugu. Dobra strana application level vatrozidnog mehanizma je sigurnost jer se propu�ta samo dobro definirani promet, jer ne postoji opasnost da me�u razli�itim skupinama pravila do�e do ne�eljenih interakcija, jer se detaljno analizira protokol na aplikacijskoj razini, pa je mogu�a vrlo precizna kontrola pristupa i jer se ne uspostavlja direktna veza izme�u za�ti�enog i vanjskog ra�unala. Lo�a strana je �to za svaku mre�nu uslugu koja se �eli koristiti s �ti�ene mre�e mora postojati program koji �e propu�tati promet te mre�ne usluge. Takvi uslu�ni programi postoje za standardne aplikacije poput telneta, FTP-a i SMTP-a. Za specifi�ne aplikacije potrebni su korisni�ki napisani uslu�ni programi, �to zna�i dosta dodatnog posla, pa se postavlja pitanje isplativosti ulaganja za odre�enu aplikaciju. Daljnji problem s application level proxyjem je u�inkovitost jer zbog detaljnog ispitivanja paketa na razini aplikacije dolazi do zna�ajnog utro�ka vremena. Mogu�a je i vrlo neugodna situacija da implementacija application level proxyja zahtijeva modifikaciju korisni�koga klijent programa, iako je to danas dosta rijetko.
Proxy poslu�itelj stoji izme�u korisnika unutra�nje mre�e i usluge na vanjskoj mre�i Internetu. To zna�i da proxy poslu�itelj preuzima svu komunikaciju izme�u korisnika i Interneta, a njegova glavna odlika je transparentnost.

Proxy usluga u stvari daje iluziju da je korisnik direktno spojen sa stvarnim
poslu�iteljem tra�ene usluge, dok poslu�itelj usluge ima iluziju da daje uslugu direktno korisniku na proxy ra�unalu (a ne ra�unalu korisnika tra�ene usluge).

Slika 3. Proxy vatrozid, primjer telnet konekcije

Veza koja se prekida na poslu�itelju bit �e kompletirana u dva koraka:
o prvo se uspostavlja veza sa posebnim proxy poslu�iteljem (FTP, HTTP, DNS, Mail)
o a onda se uspostavlja veza sa stvarnim poslu�iteljem

Koraci u radu proxy poslu�itelja su:
-procjenjuje zahtjeve proxy klijenta i odlu�uje koji odobriti, a koji odbiti.
-Ako je zahtjev odobren, kontaktira poslu�itelj usluge na Internetu u ime klijenta (odakle i ime proxy �to u prijevodu zna�i opunomo�enik).
-Nastavlja s izmjenom zahtjeva proxy klijenta stvarnom poslu�itelju.
-Proslje�uje odgovore stvarnog poslu�itelja prema proxy klijentu.

Proxy poslu�itelj nije samo prosljeditelj zahtjeva korisnika, on ovisno o politici
sigurnosti mo�e prihvatiti ili odbaciti zahtjev. Na primjer, FTP proxy mo�e zabraniti korisniku prijenos datoteka ili dozvoliti prijem datoteka samo s odre�enih poslu�itelja.
Prednosti proxy usluge su:
-skrivanje unutra�njih mre�nih adresa
-mo�e lokalno zapisati podatke koji se �esto ponavljaju (caching)
-vr�i inteligentno filtriranje
-mo�e izvr�iti provjeru autenti�nosti korisnika
-nije potrebna posebna verzija klijent programa na klijent ra�unalu
-za�ti�uje korisnika od slabe i lo�e veze generiraju�i nove IP pakete

Circuit level proxy radi na istom principu kao i application level proxy, na principu aplikacije koja djeluje kao posrednik. Svaka komunikacija i prema van i prema unutra�njoj mre�i mora se spojiti na circuit level proxy prije prolaska kroz vatrozidni sustav. Circuit level proxy provjerava promet i na temelju definiranih pravila pristupa odre�uje koja veza smije biti uspostavljena, a koja ne. Nakon toga proxy uspostavlja vezu sa �eljenim odredi�tem i prenosi pakete. Razlika izme�u application level i circuit level proxyja je u tome �to application level proxy radi na tri gornje razine ISO OSI mre�nog modela - application, presentation, session, a circuit level proxy radi na transport razini. Mogu�e je da implementacija proxyja zahtijeva modifikaciju klijent programa. Vrlo ra�ireni circuit level proxy je Socks koji je ujedno postao i de facto standard.
SOCKS protokol je proxy za vatrene zidove na prijenosnoj razini. Zadatak Socks poslu�itelja kao vatrenog zida je odvajanje sjednice izme�u unutra�nje i vanjske mre�e, stvaranjem sigurnog prolaza za unutra�nje korisnike sa za�titom adresiranja i strukture �ti�ene mre�e.
Socks poslu�itelj presre�e sve TCP i UDP zahtjeve izme�u lokalne mre�e i Interneta i na osnovu pravila Socks veze propu�ta zahtjev za uslugu koja se onda izvr�ava na udaljenom poslu�itelju ili klijent ra�unalu.

Veza izme�u ra�unala unutra�nje mre�e i Internet mre�e prekida se na ra�unalu
vatrenog zida, da bi se kompletirala u tri koraka:
-kad korisnik starta klijent aplikaciju prema odredi�nom poslu�itelju ona se inicira na Socks poslu�itelju
-Socks poslu�itelj ispituje da li je veza dozvoljena za izvori�no ra�unalo
-ako je veza dozvoljena Socks poslu�itelj kompletira vezu

Socks funkcija zahtijeva poseban Socks klijent i poslu�itelj program. Socks klijent je posebna verzija normalnog klijent programa (kao �to je Telnet ili FTP klijent) koji radi s proxy poslu�iteljem, a ne stvarnim poslu�iteljem usluge na Internetu.

Ispravna implementacija vatrozida sve vi�e postaje primarnim alatom za za�titu dijelova mre�e od posebnog interesa, a s obzirom da je napredak ra�unalnih tehnologija izuzetan, i jako �esta tema u praksi. Kratkim pregledom kroz osnovne tehnologije vatrozida dan je i pregled osnovnih postavki, na�in njihovog rada i mogu�nosti, te njihova ograni�enja kojih �esto administratori mre�a nisu u potpunosti svjesni. Sasvim je jasno da vatrozid ne mo�e pru�iti potpunu za�titu, ali njegova ispravna i metodi�na provedba je prvi korak prema uspje�noj za�titi kriti�nih podataka na mre�i.

Zlatko �unji�, Ing. Inf. UniPC
http://www.unipc.ch/index.php