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