Tűzfal: FreeBSD vs. OpenBSD

Fórumok

Tűzfal: FreeBSD vs. OpenBSD

Hozzászólások

Tűzfalat szeretnék építeni, és tapasztalattal rendelkezőktől kérdezném, hogy FreeBSD vagy OpenBSD OS-ből készítsem-e?

NetBSD-ből. Nekem bejött. Épp azon keresztül megy a net.

Nagyon QL-ul van dokumentálva.

Azt szoktak felelni az ilyen kerdesre, hogy azt valaszd amelyikhez a legjobban ertesz. Ha most kezded akkor azt valaszd, amelyik a gepedet a legjobban tamogatja (pl. openbsd csak egy cpu-t tamogat), a felhasznalasi teruletnek legjobban megfelel, vag yamelyiknek a fejlesztesi modellje hozzad a legkozelebb all.

En a helyedben tuzfalnak openbsd-t valasztanek.

Hehe, ez ojan mint hogy "makostesztat vagy lekvaros gombocot egyek?" )

Imho nem az a fontos h FreeBSD vagy OpenBSD, hanem hogy melyiknek a tuzfalkodja all kozelebb az ember fija szivehez

Amig az OpenBSD-benis bennvolt az ipfilter (a DarrenReed-fele) kod, addig ugye tokmindegy volt, bar FreeBSD-n van mellette egy IPFW is, de azer az ipf az igazi (imho) )

Most ugye letezik FreeBSD-n az IPFW es az IPF is, OpenBSD-re meg elkezdtek irni egy IPF-jellegu (bar egyelore kevesebbet tudo) tuzfalkodot, a PF-et.

Most en (szigoruan csak az IPF iranti elkotelezettsegembol kifolyolag) FreeBSD-t valasztanek, de ez em azt jelenti hogy az OpenBSD barmivel is rosszabb lenne. Csak en megszoktam az ipf-et.

Quote:

Most ugye letezik FreeBSD-n az IPFW es az IPF is, OpenBSD-re meg elkezdtek irni egy IPF-jellegu (bar egyelore kevesebbet tudo) tuzfalkodot, a PF-et.


Azt hiszem osszessegeben a PF mar tobbet tud, mint az IPF 3. Amit nem tud, az talan csak a load balancing es a tobb cimre valo NAT.

Quote:

On , írta:
Azt hiszem osszessegeben a PF mar tobbet tud, mint az IPF 3. Amit nem tud, az talan csak a load balancing es a tobb cimre valo NAT.



Hmm, lehet hogy jobban vegig kene neznem a doksijat ... )
En amit pl. hianyoltam belole az a nat eseten meghatarozhato kimeno porttartomany. Aztan lehet hogy az is benne van csak en voltam megint feluletes? )

Elmondaná nekem értheto"en valaki, hogy mi a különbség az állapottartó (stateful) és a hagyományos tu"zfalak között? Nagyon érdekel a dolog, de sajnos doksit nem találtam hozzá magyarul.

Köszi elo"re is.

A ´sima´ fw fix szabalyok szerint blokkol, vagy enged at valamit, mig a ´stateful´ dinamikus szabalyok alapjan. Pl alapbol tiltasz mindent, de ha a 80-as portra SYN flag-es csomag erkezik, akkor letrehoz egy ilyen szabalyt, es onnantol kezdve a megadott ip/port-rol engedi a forgalmat. Igy minden el lesz utasitva, kiveve, ami egy 80-as portra torteno csatlakozas ´iranyabol´ jon. Termeszetesen vannak mindenfele allitasi lehetosegek, hogy egy ilyen szabaly meddig eljen, mikor torlodjon.

Sziasztok!

Mindenféle nagyképüséget félretéve szeretném a homályt egy kicsit oszlatni itt a tűzfalak ügyében. Osztályozzuk őket mondjuk a kapcsolat/protokoll elelmzésének szintjén illetve fejlődési sorrendjük szerint: Legöregebb az bastion host. Ez olyan, mikor be ssh-zol a routerre és onnan a célgépre (természetesen agent forwardal. Szóval a két hálózat határán figyelő eszköz nem routeol a két hálózat között. Ez igencsk korszerűtlen már. Vannak csomagszűrők PF és SPF. Ezek a hálózati réteg IP szintjéig elemzika kapcsolatot/csomagot. A sima PF minden egyes csomag (packet) IP fejléce alapján hozza meg a döntését, tehát forrás és cél cím és port valamint egy pár bit alapján (SYN egyebek) illetve a protokoll típousa (udp/tcp/icmp egyebek) alapján. ilyen az ipchains is a Linuxban. Az állapottartó egy kicsit már okosabb, mert az az egész kapcsolatra vonatkozóan tud döntéseket hozni, de még mindég csak az IP fejlécek szintjén. Ilyen pl a netfilter/iptables. Persze paranoidoknak még ez sem elég, ezért megalkották a proxykat (most nem a különböző cache-ekre, gondoljatok - pl squid) ezek a tejes protokolt elemzik (ezért hívják application level gateway-nek is) ami azt jelenit, hogy nem csak az IP fejlécbe néz bele, hanem a az adott protokollhoz tartozó parancsokat is ellenőrzi, pl egy HTTP kapcsolatban a Host, vagy a GET vagy a PUT parancsokat. Ez persze már jóval nagyobb ismeretet igényel, mint egy egyszerű csomagszűrés. Mondok egy példát. A csomagszűrőn nem engeded át csak a http-t (TCP/80). Namost, ha te egy gépen ssh-t futtatsz a 80-as porton, akkor az a "tűzfaladon" a át fog menni, de a proxy-n NEM. És ez a legfontosabb!!!! Vannak elvetemültek, akiknek ez sem elég, és ezért kitalálták a moduláris application level gatewayt, ami az összetett protokollok elemzésére szolgál, pl egy TLS1/SSL3-ba ágyazott HTTP, POP3 vagy bármi más. Ezek előbb lebontják az SSL réteget éas megnézik, hogy a beleágyazott protokoll valóban az -e, aminek lennie kell.

Remélem nem kavaram össze semmit.

Üdv,

scott at balabit pont hu

Nem. Nagyon ertheto volt. Csak az a kerdesem, hogy egy applikacio szintu tuzfal (proxy, ami nem squid) pl. a ti (ugye, balabit ) Zorp-otok nagy forgalom eseten nem igenyel extrem nagy gepet? Mert ugye minden egyes csomagba belenezni a TCP payload alapjan, es tartalom alapjan nem kis melo. Foleg olyan halozatoknal ahol van tobb szaz kliens, es huzzak a csikot rendesen. Vagy erre van valami terheleseloszto megoldas? Akar tobb gepen keresztul?

Quote:

On 2003-01-03 09:52, Anonymous wrote:
Nem. Nagyon ertheto volt. Csak az a kerdesem, hogy egy applikacio szintu tuzfal (proxy, ami nem squid) pl. a ti (ugye, balabit ) Zorp-otok nagy forgalom eseten nem igenyel extrem nagy gepet? Mert ugye minden egyes csomagba belenezni a TCP payload alapjan, es tartalom alapjan nem kis melo. Foleg olyan halozatoknal ahol van tobb szaz kliens, es huzzak a csikot rendesen. Vagy erre van valami terheleseloszto megoldas? Akar tobb gepen keresztul?



Itt találsz választ a kérdésedre: http://www.balabit.hu/hu/products/benchmark/. Amúgy vannak loadbalancer eszközök (többnyire hardweres és drága) de azért nekünk többnyire a linux kernel korlátai szabnak csak nem a proxy lassúsága, bár ez a 2.4-es kernellel már jobb lesz. Van 2.2-es kernelen zorp ami nagy fogalmú hálózatot véd és szerencsére bírja.

Egyébként nem szerettem volna reklámot a zorpnak, inkább itt a technológiák megértése volt a cél.

Hali


scott @ balabit hu

Quote:

Egyébként nem szerettem volna reklámot a zorpnak, inkább itt a technológiák megértése volt a cél.



hehe, magyar programnak sose art egy kis reklam, foleg ha jo programrol van szo. tobb helyen jartam mar ahol hasznaljak a zorpot, es eddig mindenki csak dicserte. Es azota meg megjobban szimpatikus, hogy bekerult a Debianba (egyelore csak a sidbe). Van, vagy lesz a Zorpnak nem-Linuxos verzioja is? Mondjuk valamilyen BSD, Solaris, vagy egyeb?

[ Ezt az üzenetet szerkesztette:: trey 03-01-2003 10:41 ]

Alakul a dolog, de nincsenek jó híreim. Eddig sajnos csak linux-os Zorp van (i386 és sparc, no meg a debian mind platformon...) A Solaris-os port már készülget az ehhez szükséges kernel modul (Solarisra) kész. Sajnos a BSD-kből is (mint a 2.4-es kernelből) kifelejtették/kihagyták a transzparens proxy támogatást, ezért a modult BSD-re is meg kellene írni ezt a kernelmodult, ami idő hiányában nem készült még el, egyelőre kilátás sincs rá sajnos. de ha valaki kedvet érez hozzá...


scott @ balabit hu

Quote:

On 2002-10-18 16:57, Anonymous wrote:

Quote:

Azt hiszem osszessegeben a PF mar tobbet tud, mint az IPF 3. Amit nem tud, az talan csak a load balancing es a tobb cimre valo NAT.


Mindkettot tudja mar...