zvlasny problem z firewallom
arpanet na post.cz
arpanet na post.cz
Čtvrtek Březen 11 14:48:19 CET 2004
> > Mam takyto problem. Mam firewall na PII 500MHz, RedHat 9, jadro 2.4.23
> opathovane na BridgeNF (to je ta vec aby sa aplikovali iptables cez bridge).
> V kancelarii mam skusobny server, ked pred neho dam firewall (na nom so ho
> vlastne vzdy skusal) tak vsetko bezi ok. Ked ten firewall dam na salu pred
> normalny server klesne priepustnost asi na 10KB/s. Bez neho to bezi asi
> 9500KB/s, ale skusobny server bezal stale asi 8700KB/s ci s firewallom alebo
> bez rozdieli boli iba nepatrne. Potom som spravil pokus a dal som firewall
> iba za svoj PC a bez problemov som cez neho pristupoval na oba
> serveri.Nechapem to, lebo ten firewall je vlasne bridge cize nema ip nieko
> nemeni adresny priestor len obcas stopne niaky ten paket, proste
> inteligentnejsi kus kablu. Ma niekto napad co to moze sposobovat?
>
> Je mozne aby tento problem niako sposoboval router? (napryklad ci mu nemozu
> byt divne tie mac adresy sietoviek vo firewalle) Je mozne vidiet tieto mac
> adresy ked sietovky idu v promisc mode ?
>
nevim jestli je to neni pouze muj blud ... ale
pokud vy jste za tim bridgem ... a pristupujete k siti skrz nej
tak to funguje asi takhle
1. paket vyleze z vasi sitovky do dratu
2. bridge na sitovce bliz k vam slysi paket a jukne
na jeho zdrojovou a cilovou MAC adresu ... jukne
do svych tabulek .... (bridge si buduje seznamy
na kterem drate (interni sitovce) slysi ktere
zdrojove adresy) .... a za
a) zdrojova a cilova jsou na stejne strane ...
-> bridge nedela nic
b) zdrojova a cilova jsou na ruzne strane
-> nabere paket na lopatu, prohodi ho skrz
pravidla ip tables a vyplivne na cilovou stranu
(nebo zahodi)
c) cilova MAC neni v tabulkach ...
-> jako b... ale na vsechny sitovky (segmenty)
krome te z ktere prisel tenhle paket
d) zdrojova MAC neni v tabulkach
-> zapamatuje si odkud paket prisel ...
-> dale jako b
e) neni znam ani zdroj ani cil ...
-> jako d c
xxx) cilova mac je FFFF.FFFF.FFFF
(asi doufam ze to nejni 0000.0000.0000)
jedna se o eth. broadcast
-> jako u c
3. a jedeme znovu od zacatku ...
z toho mi vychaziiii ze vy jako klient tlacite data
skrz bridge na server ... a ostatni toho po vas moc nechtej
a) tabulka MAC adres nenjni moc velka ...
skrz bridge jdou jenom vase pakety ...
-> tim padem se ten bridge muze docela nudit
b) vy a spousta dalsich klientu tlaci data na ten server
...
-> to bude ten bridge docela dost zpocenej a uhonenej ...
proste si myslim na rozdil od ip ... kde si ta masina vsima
jen svejch eth paketu a dal se rozhoduje podle IP adr ... atd
tak ten bridge ma docela dost prace kdyz se musi o kazdym eth
paketu kterej svistii dratem vokolo rozhodnout esli ho nabrat
na lopatu a nebo ne ....
vem te si treba takovejch 20 kompuuu na eth siiti kteryy si na jedne
strane dratu povidaj se sebou se serverem a k tomu spoustu veselejch broadcastu ... a na druhy strane site ten server za bridgem ...
ten bridge musiii vyhodnotit kazdej paket kterej si svistii draatem
okolo ....
-> sem se nejak rozkecal ... proste sw bridge je reseni ... ale
ne pro hustej provoz ... a ne pro Lan <x> Server .... ale mozna je to
jenom muuj dojem ...
s pozdravem arpanet na post.cz
-----Banshee foot--------------------------------
Better Artificial Inteligence than Natural Stupidity
a nekdy je nejlepczi kedluben -)
Další informace o konferenci Linux