shaping provozu

[Dan Lukes]

Zbyněk Burget napsal/wrote, On 02/07/07 09:25:
> Ten snort nevypada na prvni pohled uplne spatne. obavam se ale, ze 
> system analyzy logu a podle nej prepisovani ipfw ruli nejakym skriptem 
> nebude realny u site s tokem ve spicce kolem 10 mbit.
> Kdyby to bylo 50 pocitacu, jeste by se to asi dalo osefovat, ale u 
> neceho vetsiho asi uz ne.
> Jo, kdyby snort mohl vratit packet do IPFW s nejakym flagem, na zaklade 
> ktereho bych rozhodl, co s nim dal, to by bylpresne to, co potrebuju. 
> Ale tohle bohuzel asi neumi - tedy ja nic takoveho aspon v dokumentaci 
> snortu nenasel a ani o takovem mechanismu v IPFW nevim.


	Mechanismus v IPFW2 je. TAGovani paketu jako takove mozne je po dobu 
jejich zpracovani v kernelu. IPFW umi paket oznacit a (ne)existence 
oznaceni lze pouzit v matchovaci podmince nejakeho pravidla, nicmene, 
TAGy jsou v ramci kernelu opravdu dostupne opravdu obecne, takze tento 
mechanismus mohou pouzivat i jine komponenty, ktere se k paketum v jadre 
dostanou.

	Ale obavam se, ze tento mechanismus je SNORTu nedostupny. Ja ho sice 
neznam, ale podle toho, co padlo tady, tak on sedi na nejakem read-only 
rozhrani (bpf?), analyzuje pakety, a kdyz chce vyvolat nejakou akci, tak 
musi pouzit nekoho jineho - zmenit pravidla ipfw nebo tak. Sam pakety 
podle vseho menit neumi.

	Jinak je ale na siti s tokem ~10Mbps davat pozor i na tohle - na te uz 
je videt kazde pravidlo, kterym paket v ipfw musi projit, takze je 
jejich pocet dulezite drzet na co nejmensim cisle.

	Na takovehle siti, podle pripojeni soudim, ze to je velka sit, uz mam 
ale za jiste, ze technicka opatreni jsou sice mozna, ale vhodnejsi 
metodou reseni jsou opatreni organizacni.

						Dan



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