ipfw keep-state

Dan Lukes dan at obluda.cz
Thu Apr 19 15:40:24 CEST 2007


Juraj Belák napsal/wrote, On 04/19/07 10:27:
>> 	A cemu konkretneji na tom nerozumis ? Proste zaznam pro spojeni ve 
>> stavu "established" expiruje za jinak dlouhou dobu nez spojeni ve stavu 
>> "fin-wait".
> Vrta mi v hlave prave ta "jinak dlouha doba". Povedzme, ze teoreticky
> mi cez firewall prechadzaju pakety z par stovak klientov - moze nastat
> pripad, ze mi zostane visiet naraz tolko otvorenych spojeni aj zasluhou
> dynamickych rules, ze firewall potrebuje taku dlhu dobu na spracovanie
> paketov, ze na vstupe sa zahlti?

	To je furt nejake nedorozumeni. "Stav spojeni" je neco, co si kazdy z 
koncovych bodu i firewall uchovava sam. V idealnim pripade by vsichni 
tri mely mit stejnou predstavu o tom, v jakem stavu spojeni je, ale z 
ruznych (prevazne chybovych) duvodu to obcas neplati. Chybama nemyslim 
chyby v kodu jadra, i kdyz i to je moznost, jako spis ztraty paketu pri 
sitovem prenosu.

	Pro koncove body nezustane spojeni otevrene proto, ze si to preje 
firewall.

	Ale ano, prilis velke mnozstvi pravidel (treba i tech dynamickych) muze 
snizit pruchodnost routeru, to muze vyustit ve vyssi ztratovost paketu a 
to muze v konecnem dusledku vest az k tomu, ze jedna strana bude 
povazovat spojeni za uzavrene a druha (a firewall mozna taky) za otevrene.

	Je to to, na co se ptas ?

	Za "normalniho" protozu je vznik takove situace spis mene pravdepodobny 
- aplikace, zejmena TCP, aktualni "tlak" reguluji podle moznosti - a 
uzavreni se, neni-li prostistranou potvrzeni, nekolikrat opakuje, takze 
by k "definitivni ztrate synchronizace" spis dochaet nemelo.

	Nicmene, firewall se nedela kvuli "hodnym hochum". A v pripade utoku, 
at uz "z venku", nebo (treba kvuli zavirovanemu stroji) zevnitr k necemu 
nepeknemu skutecn edojit muze ...


>>> Podla coho (a ci vobec) treba menit default hodnotu 
>>> /net.inet.ip.dummynet.hash_size 64.
>> 
>> 	Bude tezke poradit. Schazi nam klicova informace - ceho se snazis 
>> dosahnout, nebo, mozna jinak, co te vede vubec k myslence, ze bys mel 
>> nejake hodnoty menit.

> Detto ako vyssie. Ma zmysel predchadzat (teoretickemu?) zahlteniu 
> firewallu napriklad tym, ze nepouzijem dynamicke rules,

	Na to proste neexistuje obecna odpoved. S dynamickymi pravidly jsi 
ochranen pred urcitymi riziky a vystaven jinym.

	V siti, kde je firewall na routeru jen doplnkovym zabezpecenim, protoze 
hlavni zabezpeceni si musi zajistit kazda koncova stanice sama (treba 
proto, ze si uvedomujeme, ze zavirovany pocitac "uvnitr" by mel volne 
pole pusobnosti, ktere by firewall na routeru nemohl zachytit) je IMHO 
vhodnejsi nestavovy firewall - zvysene riziko toho, ze router obcas 
propusti neco, co by stavovy firewal zachytil je male, protoze stanice 
maji vlastni ochranu. Zvysene riziko uspesneho DoS na stavovy firewall 
tak prevazuje.

	Naproti tomu v siti, kde je router hlavnim zabezpecovacim prvkem a 
stanice vlastni zabezpeceni nemaji (a v horsim pripade jsou dokonce 
neudrzovane) bude patrne vhodnejsi statovy firewall - protoze riziko, ze 
neco, co nezachytime vevnitr nasledne opravdu uskodi je znacne. Tak 
znacne, ze DoS riziko stavoveho firewallu muze byt vyhodnoceno jako 
prijatelne.

	Psal jsem, ze ja stavove firewally nepouzivam, protoze moje site jsou 
prvniho typu. Ale siti a zpusobu jejich sprav a vztahu mezi spravou a 
uzivateli je milion, takze v danych konrketnich pripadech mohou vyjit 
jako "lepsi" jine pristupy - vcetne toho, ze se stavovy firewall ukaze 
byt vhodnejsi nez nestavovy.

	Otazky zabezpeceni a bezpecnosti vubec maji malokdy nejake obecne 
odpovedi. Snad krome otazky "a muze presto nekdo uspesne zautocit", kde 
je nepodminenou odpovedi "ano" ...

					Dan


-- 
Dan Lukes                                               SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz





More information about the Users-l mailing list