> ha azt mondanak neked, hogy a halozatotok vedelmere CISCO PIX-et kell
> hasznalnod, milyen erveket, ellenerveket hoznal fel egy masik tuzfal, vagy
> eppen a Zorp alkalmazasara?
Szia!
A kerdes nem egyszeru, megprobalom roviden osszefoglalni, hogy nem technikai
ember ebbol mit ert meg, az jo kerdes. Talan az ismeretlen tamadasi
kiserleteket... (ld lentebb) jo olvasast :)
Szamos kulonbozo tuzfal technologia letezik, a Zorp es a PIX ket kulonbozo
technologiat valosit meg. Lassuk eloszor a PIX-et:
A PIX egy allapottarto csomagszuro, ami annyit tesz, hogy a beerkezo
csomagokat (itt fontos, hogy _csomagokrol_ van szo) megprobalja kapcsolathoz
rendelni (ehhez a csomag fejlec informacioit hasznalja fel, pl: IP forras
celcim, TCP flagek, portok), es ha ez az osszerendeles sikeres (tehat
megtalalja a csomaghoz tartozo kapcsolatot, es az a kapcsolat
engedelyezett), akkor a csomagot - altalaban valtozatlan formaban (majd
mindjart latjuk a kiveteleket) - tovabbitja a vedett halozat fele. A PIX a
csomag adatreszevel _NEM_ vagy csak nagyon kis mertekben foglalkozik (itt is
mindjart latjuk a peldakat).
Az elobb azt irtam, hogy a csomagokat nem mindig valtozatlan formaban
tovabbitjak, ez annyit jelent, hogy a PIX kepes a TCP fejlecben az sequence
numbereket kicserelni, a gyenge ISN (initial sequence number) elkerulesere,
valamint kepes az FTP-ben az adatkapcsolatra vonatkozo adatokat
megpatchelni. A csomagok azonban nagyreszt _valtozatlan_ formaban jutnak at
a vedett halozatra.
Azt is mondtam, hogy a csomagok adatreszevel a PIX nem, vagy csak nagyon
kicsit foglalkozik. A nagyon kicsi altalaban az a minimum, amivel egy NAT
jellegu funkcionalitas elerheto. Pl. az FTP protokoll adatcsatornajanak
megnyitasahoz a tuzfalnak tudnia kell, hogy a kliens ill. a szerver milyen
cimet adott, illetve ezt meg kell patchelni. Ez azt jelenti, hogy a PIX
ismeri az FTP PORT es PASV parancsait/valaszait.
Tehat az allapottarto tuzfal tulajdonsaga az, hogy a leheto legtobbet
megteszi a szures erdekeben, de szinte kizarolag a csomagok fejreszevel
foglalkozik. Sajnos nehany csomagszintu tamadast sem kepes elharitani,
hiszen alapvetoen router funkciokat lat el: az engedelyezett csomagokat
forwardolja.
Nagy problema SPF-nel, hogy nem mindig eldontheto egy csomagrol, hogy az egy
adott sessionbe tartozik, vagy nem (pl ha elveszik egy csomag egy TCP
sessionbol, attol az az koveto darabot erdemes atengedni, feltetelezve, hogy
majd a hianyzo darabot is ujraadja a kliens), tovabbi hatrany lehet, hogy IP
stackek kozott lehetnek kulonbsegek: peldaul atlapolo fragmentek
kezeleseben/ertelmezeseben, igy elkepzelheto, hogy a tuzfal mas forgalmat
"lat", mint a kapcsolat valos vegpontja. (ugyanez a problema amugy
elokerulhet Network IDS-nel is)
Ennyit eloljaroban az SPF-ekrol.
A Zorp, mint azt valoszinuleg tudod, alkalmazas szintu atjarokbol, un.
proxykbol all. Ez egy teljesen mas tuzfal technologia, es a kovetkezo modon
mukodik:
A tuzfal egy specialis (de userspace-bol futo, ellentetben az SPF-ekkel,
ahol a teljes feldolgozas kernelben tortenik) program, ami kapcsolatokat
fogad (itt fontos, hogy _kapcsolatrol_ van szo), majd a kliens neveben
tovabb kapcsolodik a szerver fele, majd a ket kapcsolat kozott kereseket
kozvetit.
Itt tehat nem egy kapcsolatrol van szo, amit a tuzfal ertelmez, hanem ket
fuggetlen kapcsolatrol: 1. a kliens es a tuzfal kozott, 2. a tuzfal es a
szerver kozott. Eredetileg a proxy tuzfalak nem transzparensek voltak, a
modernebbek mar egytol egyig transzparensek, bar ehhez modositott IP stackre
van szukseg. (a Linux ezt alapbol tartalmazza)
A ket kapcsolatbol kovetkezoen a csomagszintu tamadasok jo resze mar nem is
jatszik, a kapcsolat adatreszerol a fejleceket levagjuk, majd egy ujabb
kapcsolatba "beleontjuk", az eredetitol fuggetlen csomagokat hozva letre. A
proxy tuzfal _soha_ nem tovabbit csomagokat (legalabbis, ha a proxy
funkcioit nezzuk, termeszetesen az IP forward es a proxy megferhet egymas
mellett, bar nagyon specialis esetekben).
Tovabbi finomitas a proxy tuzfalakban, hogy a fejlecekrol levalasztott
adatreszt formai/biztonsagi ellenorzesnek vetik ala. Ennek az ellenorzesnek
a megvalositasa az, hogy a proxyk _ismerik_ az alkalmazasi protokollokat,
igy minden protokollhoz kulonbozo proxy kell.
Osszehasonlitani lehet tuzfalakat peldaul az ellenorzes melysege szerint. A
Zorpnal alapveto tervezesi szempont volt a default DENY hozzaallas, tehat
_minden_ protokoll elemet ismernunk kell, ami a protokoll mukodesehez
elengedhetetlen. Ismert FTP parancsok szama:
iptables/ipchains masq: 2 (PORT, PASV)
PIX: bizonytalan, valoszinuleg 2 (PORT, PASV)
TIS fwtk: 30 korul, de a parancsok parametereit/valaszait nem ellenorzi, a
lehetseges parancsok nem bovithetok
Zorp: 34, a parancsok parametereit _is_ ellenorzi, a lehetseges
valaszkodokkal egyutt. Mind a parancsok, mind a valaszok halmaza
bovitheto.
Annak, hogy protokoll ellenorzes tortenik szamos elonye van:
* egy megnyitott adatcsatornan tenyleg csak az engedelyezett protokoll
hasznalhato (pl: nem lehet IRC protokollt hasznalni a megnyitott 80-ason,
illetve a bekuldott trojai program nem fog tudni kimenni a kuldojehez a
443-on)
* mivel az alkalmazasi szintu tamadasok joresze megserti a protokollt, ezert
ezek megfoghatok _ismeretlenul_ is (pl: a CodeRed nem ment keresztul egy
Zorp-os HTTP proxyn, a legutolso BSD-s telnetd exploit szinten nem, de
azert ez nem csodaszer, mert a NIMDA viszont igen, ilyenkor fel kell
kesziteni a tuzfalat a tamadas ismeretere)
* ha a tuzfal arra kepes (a Zorp nyilvan igen) lehetoseg van a protokollok
IBSZ-nek megfelelo szukitesere (pl: FTP ugyan engedelyezett, de csak
anonymous felhasznaloknak, es azoknak is csak letoltesre)
Zorp specifikus proxy funkcio, hogy a kulonbozo protokollokat ismero
proxykat tetszoleges strukturaba ossze lehet fogni => bonyolult egymasba
agyazasok is lekezelhetok, mint pl: HTTPS, pop3s.
Tovabbi Zorp ujitas, hogy az adminisztrator kepes a donteseit egy
programozasi nyelven megfogalmazni. Termeszetesen ehhez csak akkor kell
nyulnia, ha az alapbol nyujtott szolgaltatasok nem elegendoek.
Osszefoglalva tehat:
PIX Zorp
fejlec tartalma alapjan dont a kapcsolat vegpontjai, _ES_ az
adatfolyam tartalma alapjan dont
erzekeny lehet csomagszintu a csomagszintu tamadasok max. a tuzfalat
tamadasokra erhetik
nem kepes a protokollok programozasi nyelv all rendelkezesre a
melyebb ellenorzesere, igy protokoll ellenorzes finomitasara,
nincs lehetoseg protokoll ha erre szukseg van (az alapertelmezestol
elemek tiltasara persze nem muszaly elternunk)
_nem_ kepes ismeretlen A tamadasi modszerek joresze megfoghato
tamadasokat megfogni, sot ismeretlenul is, de felkeszitheto alapbol
IDS nelkul meg ismerteket sem nem megfogott, de ismertte valt biztonsagi
hibak ismeretere, IDS itt is hasznos
termeszetesen.
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1