Richard Willmann wrote:
cely problem o ktorom ste diskutovali spociva v moznosti nekontrolovaneho
narastu poctu zaznamov v stavovej tabulke. Spravne?
Ano - aniz by statovy firewall prinasel tak nepstradatelnou
funkcionalitu, ze "to za to stoji".
* dostatocne vykonnom stroji,
To ovsem neni jen o procesoru a u gigabitove linky se dostavas na
hranice toho, co zvladnou sbernice. A u tech mas vyber, a zejmena vyber
z podporovanych karet docela omezeny.
prinos moze vyvazit a vo vacsine pripadov aj vyvazi
Okrem lepsieho pocitu
V tomto hodnoceni se neshodujeme. Ja si "lepsiho pocitu" asi nevazim
dostatecne a trvam na trochu hmatatelnejsich pozitivech, kdyz uz mi maji
omluvit nevyhody ;-)
je spracovanie paketov stavovym firewallom (ale opat, nie vzdy ale obvykle)
rychlejsie nez tym nestavovym (z casti overene v praxi a aj v
manualovych strankach je napisane, ze vyhladavanie v tabulke stavov je
rychlejsie nez v tabulke firewallovych pravidiel).
No tak to v zadnem pripade. A nebo se nebavime o stejnem firewallu.
ipfw je implementovano tak, ze stavy uklada jako uplne normalni pravidla
- jen je neuklada do tabulky X, ale do tabulky Y, pricemz pravidla z
tabulky Y se uplatnuji jako "include" v okamziku, kdy nastane urcita
podminka v tabulce X.
Uz jsem tu psal, ze v mem nestavovem firewallu projde 90% paketu nejvyse
10 pravidel. Az bude v tabulce Y dalsich 100 pravidel vygenerovanych
dynamicky (a to jsem velmi umirneny v odhadu poctu) tak jsem v poctu
prochazenych pravidel proste o rad jinde.
A, a to zas mam ozkouseno ja, se projevi na latenci tech prochazejicich
pakety (a proto obcas prehazuju poradi pravidel ve firewallu abych co
nejvice paketu vyridil co nejdrive)
Nicmene, nerad bych tu zabrednul do diskuse, nakolik je latence 50ms
misto 5ms problem. Hlavni potiz se stavovymi firewally je jinde - a to v
miste, ktere nevyresis ani vetsi pameti, ani nakupem silnejsiho
procesoru, ani toleranci vuci vetsi latenci.
Uz to tu padlo - kazdy stavovy firewall ma nejaky limit na pocet
vytvorenych pravidel. Tento limit je az prilis snadne vycerpat a proti
takovemu vycerpani se prakticky nelze branit.
Pokud k nemu dojde, a to z jakehokoliv duvodu, nastanou problemy s
beznym uzivanim te chranene site. A v mem pripade plati, ze za tuto cenu
o "lepsi pocit" nestojim.
Zabezpeceni site je komplexni problem - ne vsechno musi resit centralni
router/firewall a me pripada, ze zrovna tohle je vec, u ktere za reseni
v tomto miste zaplatim neprijatelnou cenu - zatimco kdyz ji nebudu resit
tady, tak se mi vyresi velmi lacino, prakticky sama.
Zabezpeceni site je nedeterministicky problem - souvisi se zvazovanim
rizik a s odhady skod a to je samo o sobe vic loterie nez veda. Takze je
samozrejme, ze co clovek, to jiny nazor, jake skody a jaka rizika hrozi
a jak je to-ktere ochranen opatreni omezi - a tudiz - co clovek to jiny
nazor na efekt konkretniho opatreni v konrketni siti ...
Stavovy firewall nektera rizika eliminuje, uplne jina nove vytvari. Muj
nazor je, ze ve vysledku je jeho dlouhodoby efekt s ohledem na sumu
vzniklych skod typicky zaporny, i kdyz jiste lze najit situace, kdy to
tak neni.
To ale neni jediny, tim mene jediny spravny, nazor ... ;-)
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
