Re: OT: záhadne chovani nekterych zarizeni v siti
ahoj, tomuhle jsme nadavali bugovy proxy arp a resili jsme to v roce 2003 v clnetu na apcku... skoncilo to vymenou zarizeni u klienta. a bacha na STP :) muze se taky stat ze pokud pouzivas stp tak to naklonuje stp paket a cela vetev na ciscu jde dolu :) Vilem -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: OT: záhadne chovani nekterych zarizeni v siti
Zdravím. A nepomohlo by zvednout na tom Ciscu arp timeout, aby tam byl záznam déle než na routeru ? Pavel Honzejk Dne 30.1.2013 15:19, Zbyněk Burget napsal(a): Zdravím vespolek, omlouvam se za prokazatelne OT, ale vim, ze tady najdu asi nejvic odborniku a tudiz nejvetsi sanci na odpoved. Uz jsem to pred nedavnem zesil soukromne s Danem a po vymene jednoho podezreleho strojku jsem si myslel, ze mam po problemech. Bohuzel jsem se pletl. V poslednich dnech se mi na siti objevily hned dalsi dve zarizeni, ktere se chovaji uplne stejne. Popisu situaci problem, jak se mi ho podarilo analyzovat. Jedna se o prevazne bezdratovou sit, kde je z historickych duvodu nekolik subnetu na jednom fyzickem sitovem prostoru. Zacne to tak, ze nekdo doma vypne PC vcetne bezdratoveho zarizeni. Dana IP, vcetne MAC adresy tedy zmizi ze site. Po nejakem case vyexpiruje prislusny zaznam v MAC tabulce na centralnim switchi (Cisco), ale v arp tabulce routeru zaznam prozatim jeste je. Ted se stane to, ze nejaky libovolny klient (ktery ale je v jinem subnetu) posle packet tomu vypnutemu klientovi. Ten dojde na router, ktery zjisti, ze v arp tabulce ma prislusny zaznam a packet odesle. Switch ale uz bohuzel nevi, do ktere vetve site ho ma odeslat a tak ho posle na vsechny strany. A tady prichazi kamen urazu. Misto toho, aby se packet v tichosti ztratil, protoze na siti uz neni prijemce, ozve se domaci routrik uplne jineho zakaznika, ktery vyhodnoti, ze ten packet k nemu proste prisel spatne a je potreba to napravit. A proto ho odesle zpet routeru (s originalni zdrojovou i cilovou IP adresou). No a router se packet opet snazi dorucit... Co mam povidat, sit to zaplavi tak, ze je nepouzitelna. Do doby, nez vyexpiruje (nebo je smazan) arp zaznam v routeru one puvodne vypnute stanice. Veskere IP i MAC adresy jsou v poradku, takze nejaky utok typu MITM bych vyloucil. Pri prvotnim vyskytu problemu jsme i se zakaznikem, kteremu se takto jeho domaci routrik choval vyhodnotili, ze je ten routrik vadny. Byl vymenen a problem zmizel. Ted se mi na siti zjevily dalsi dva domaci routery, ktere se chovaji uplne stejne. Ve vsech trech pripadech se jedna o jineho vyrobce routeru, jedna se o zakazniky na jinych fyzickych vetvich site i jinych subnetech. Coz ve mne nahlodalo myslenku, ze se mozna nejedna o vadu zarizeni, ale ze se z nejakeho mnou zatim nepochopeneho duvodu ty zarizeni chovaji spravne a ja hledam pricinu v jine kupce sena. Resenim bude fyzicke oddeleni a odroutovani jednotlivych subnetu, na cemz se pracuje, ale predstavuje to rozsahlejsi rekonfiguraci site (vcetne zmen ve fyzicke topologii) a neni to otazkou nekolika dni. Workarround by byl zkratit dobu platnosti zaznamu v arp tabulce (nevim, jak dalece je to rozumne - a taky jsem zatim napatral po tom, jako toho na FBSD dosahnout). No a samozrejme nejlepsi resenei je pochopit proc se to deje a tem zarizenim vysvetlit, ze se tak nemaji chovat. Kdyby mel nekdo podobnou zkusenost pripadne nekoho napada, co s deje, pisnete mi, prosim. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: OT: záhadne chovani nekterych zarizeni v siti
On 01/30/13 15:19, Zbyněk Burget: Misto toho, aby se packet v tichosti ztratil, protoze na siti uz neni prijemce, ozve se domaci routrik uplne jineho zakaznika, ktery vyhodnoti, ze ten packet k nemu proste prisel spatne a je potreba to napravit. A proto ho odesle zpet routeru (s originalni zdrojovou i cilovou IP adresou). No a router se packet opet snazi dorucit... Co mam povidat, sit to zaplavi tak, ze je nepouzitelna. Do doby, nez vyexpiruje (nebo je smazan) arp zaznam v routeru one puvodne vypnute stanice. Problem vznikne jen v kombinaci nekolika okolnosti. Na te fyzicke siti jsou je nakonfigurovana vic nez jedna logicka IP sit. Tim se k routriku klienta muze dostat paket, jehoz IP adresa nepatri do zadne site, kterou tento router zna. S takovymi mix-sitemi je vzdycky trochu potiz, prinejmensim v oblasti IP broadcastu (obzvlast s nespecifickym 255.255.255.255) ale vetsinou to samo o sobe jeste neznamena katastrofu. Teprve kdyz se to spoji s dalsimi okolnostmi. Paket o kterem je rec a ktery na routrik dorazi, nema jeho cilovou MAC. Za normalnich okolnosti by karta v nepromiskuitnim modu takovy paket ani neprijala a vsechno by bylo naprosto v pohode. Problemem jsou ruzne podivne router-bridge s takovymi featurami jako je klonovani vnitrni MAC ven a tak - tam je casto karta trvale prepnuta v promiskuitnim modu a softwarovy filtr, ktery by kontrolu cilove MAC implementoval je vadny nebo zcela chybi. Tim se paket, ktery nemel byt vubec prijat dostane do vyssich vrstev - a ty, uz legitimne a korektne, reaguji forwardovanim (a pripadnym ICMP_REDIRECT). Takovy routrik lze povazovat za vadny neb za rutinniho provozu by se nemelo na hodnotu cilove MAC kaslat a ignorovat ji. No, a kdyz se spoji mixovana sit (tvoje chyba) se zarizenim s touto vadou (problem nekvalitniho zarizeni vyrobce), vznikne katastrofa. Resenim bude fyzicke oddeleni a odroutovani jednotlivych subnetu Ano. Dostatecnym "fyzickym" oddelenim muze byt i zavedeni VLANu. Workarround by byl zkratit dobu platnosti zaznamu v arp tabulce (nevim, jak dalece je to rozumne - a taky jsem zatim napatral po tom, jako toho na FBSD dosahnout). Castejsi ARP dotazy budou vytezovat sit, vcetne vsech zakaznickych linek (ARP je broadcast). Nastaveni je trivialni ukon: sysctl net.link.ether.inet.max_age=(cas v sekundach) No a samozrejme nejlepsi resenei je pochopit proc se to deje a tem zarizenim vysvetlit, ze se tak nemaji chovat. A to ja si celkem myslim, ze vim co se tam deje. Potiz je v tom, ze ten zarizenim to budes tezko vysvetlovat. Mozna se ti podari najit takovou kombinaci (de)aktovovanych featur kdy vnejsi karta v promiskuitnim modu nepojede, nebo treba pojede, ale nejaky kod dal bude spravne zahazovat pakety, ktere na routrik prijit nemely. Ale mozna se ti takovou kombinaci najit nepodari - nebo ano, ale vypnes tim uzivateli neco, co bude chtit. A taky to na kazdem zarizeni bude jinak. A i kdy to zvladnes, uzivatel by uz nesmel do konfigurace nijak zasahovat (protoze i mala nevinna zmena muze zpusobit navrat puvodniho chovani). Zkraceni ARP muze problem castecne resit. Presneji zkrati dobu po kterou je v cele siti kvuli problemu akutni pretizeni. Dalsi moznost je zkratit TTL u paketu, ktere do tohoto segmentu posilas. Omezis tam delku "kolovani" a tudiz i mnozstvi paketu, ktere v konkretnim okamziku sit pretezuji. Myslim, ze na tohle neni ve FreeBSD nastroj, ale mohlo by byt pomerne jednoduche to jako "hack" dodelat. Dalsi potencialni reseni je nahradit chybejici/vadny filtr konfiguraci na koncovem portu tveho switche (ktery vede do takoveho vadneho routriku) a routriku zadne pakety s MAC adresou, ktera neni jeho, nepredavat (broadcasty a multicasty nepocitam). To neni bezna schopnost switchu, takze si nejsem jisty, jestli to neni cista teorie. Nicmene, jedinym "nehackovym" resenim je skutecne "de-mixovat" tu sit. Tedy - nemit na jedne L2 siti vic ruznych L3 siti kdy koncova zarizeni vzdy znaji jen nektere z nich. Dan P.S. Mila Sos wrote: maximálně dát ICMP redirect a ne poslat packet zpět Pokud vim, tak ne - vyznam ICMP_REDIRECT neni "paket jsem zahodil" ale "tentokrat jsem to preposlal, ale priste to posilej primo". Takze preposlani paketu je korektni (kdyby slo o paket, ktery byl routeru adresovan, coz v nasem pripade neni). -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
RE: OT: záhadne chovani nekterych zarizeni v siti
> > To nic nemění na tom že routříky by ten provoz měly zahodit, maximálně > > dát ICMP redirect a ne poslat packet zpět. > > O tom jsem taky presvedcen, ze na ten packet namaji vubec reagovat, kdyz > neni urcen pro ne (a to ani podle IP, ani podle MAC adresy). Co je ale > primeje k tomu, aby ho zpracovaly, nemam tucha. Na druhou stranu musim > uznat, ze se ho znazi zpracovat jakoze spravne. Nevim, jestli to bude uplne stejne, ale resili jsme sveho casu to, ze jedna serie levnych routeru mela hacknuty firmware, ktery delal podobny bordel. Uz je to nejaky patek zpet, takze pevne verim, ze to moc nezvoram, ale snazili se poslouchat v siti a kdyz na jinem ip dosli k zaveru, ze neni provoz, tak se zacali tvarit, ze jsou ten "nefunkcni" routrik. U nas jsme to resili vymenou 1000 ks klientskych routeru, nastesti vyrobce uznal chybu a vsechny vymenil. Jinak ja resim stale to, ze BSD mi meni branu zrejme dle slunicka, takze se nedivim uz nicemu... Radek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: OT: záhadne chovani nekterych zarizeni v siti
Dne 30.1.2013 15:51, Mila Sos napsal(a): Zdar Omezení ARP zivota: sysctl net.link.ether.inet.max_age já v domácí síti používám 60s místo defaultních (tuším) 2700, nemyslím si že by to mělo přinést nějakou komplikaci Ono tohle neni ale na domaci siti, je to na siti, kde je radove nekolik set zarizeni a spickove toky dosahuji 150 mbit... To že se jedná o různé výrobce neznamená že nemají shodný firmware. To je sice fakt, ale pri srovnani Belkin versus SMC mi to neprijde prilis pravdepodobne. obávám se že ze síťového pohledu je rozjíždění více subnetů v rámci jedné VLAN čuňárna Tam sice o VLANy nejde, jsem si vsak plne vedom neprilis stastne topologie site. Jak jsem psal, resi se to, bohuzel je do beh na delsi trat - predelavat neco takoveho za provozu. Pokud disponujete switchem CISCO, pak předpokládám že by klienty stačilo oddělit konfiguračně na tomto switchi pomocí VLAN do skupin (na základě adres subnetů) a pak spoj na router řešit jako TRUNKový spoj všech VLAN V te siti ale neni jen to jedno Cisco - v tom Ciscu se jen sbihaji vsechny vetve site. Odroutovani jednotlivych subnetu bude resene jinde, casto bude vice subnetu (a routeru) v jedne fyzicke vetvi. To Cisco je jen L2 switch, takze podle adres subnetu filtorvat nemuzu - ale ono to opravdu nebude potreba. To nic nemění na tom že routříky by ten provoz měly zahodit, maximálně dát ICMP redirect a ne poslat packet zpět. O tom jsem taky presvedcen, ze na ten packet namaji vubec reagovat, kdyz neni urcen pro ne (a to ani podle IP, ani podle MAC adresy). Co je ale primeje k tomu, aby ho zpracovaly, nemam tucha. Na druhou stranu musim uznat, ze se ho znazi zpracovat jakoze spravne. -- Zbyněk Burget Mlýnská 397 798 26 Nezamyslice tel: 588 580 000, 739 930 931 http://www.burgnet.cz IČ: 606 88 220; DIČ: CZ7210184674 -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: OT: záhadne chovani nekterych zarizeni v siti
Zdar Omezení ARP zivota: sysctl net.link.ether.inet.max_age já v domácí síti používám 60s místo defaultních (tuším) 2700, nemyslím si že by to mělo přinést nějakou komplikaci To že se jedná o různé výrobce neznamená že nemají shodný firmware. obávám se že ze síťového pohledu je rozjíždění více subnetů v rámci jedné VLAN čuňárna Pokud disponujete switchem CISCO, pak předpokládám že by klienty stačilo oddělit konfiguračně na tomto switchi pomocí VLAN do skupin (na základě adres subnetů) a pak spoj na router řešit jako TRUNKový spoj všech VLAN To nic nemění na tom že routříky by ten provoz měly zahodit, maximálně dát ICMP redirect a ne poslat packet zpět. S pozdravem Mila On 2013/01/30 15:19, Zbyněk Burget wrote: Zdravím vespolek, omlouvam se za prokazatelne OT, ale vim, ze tady najdu asi nejvic odborniku a tudiz nejvetsi sanci na odpoved. Uz jsem to pred nedavnem zesil soukromne s Danem a po vymene jednoho podezreleho strojku jsem si myslel, ze mam po problemech. Bohuzel jsem se pletl. V poslednich dnech se mi na siti objevily hned dalsi dve zarizeni, ktere se chovaji uplne stejne. Popisu situaci problem, jak se mi ho podarilo analyzovat. Jedna se o prevazne bezdratovou sit, kde je z historickych duvodu nekolik subnetu na jednom fyzickem sitovem prostoru. Zacne to tak, ze nekdo doma vypne PC vcetne bezdratoveho zarizeni. Dana IP, vcetne MAC adresy tedy zmizi ze site. Po nejakem case vyexpiruje prislusny zaznam v MAC tabulce na centralnim switchi (Cisco), ale v arp tabulce routeru zaznam prozatim jeste je. Ted se stane to, ze nejaky libovolny klient (ktery ale je v jinem subnetu) posle packet tomu vypnutemu klientovi. Ten dojde na router, ktery zjisti, ze v arp tabulce ma prislusny zaznam a packet odesle. Switch ale uz bohuzel nevi, do ktere vetve site ho ma odeslat a tak ho posle na vsechny strany. A tady prichazi kamen urazu. Misto toho, aby se packet v tichosti ztratil, protoze na siti uz neni prijemce, ozve se domaci routrik uplne jineho zakaznika, ktery vyhodnoti, ze ten packet k nemu proste prisel spatne a je potreba to napravit. A proto ho odesle zpet routeru (s originalni zdrojovou i cilovou IP adresou). No a router se packet opet snazi dorucit... Co mam povidat, sit to zaplavi tak, ze je nepouzitelna. Do doby, nez vyexpiruje (nebo je smazan) arp zaznam v routeru one puvodne vypnute stanice. Veskere IP i MAC adresy jsou v poradku, takze nejaky utok typu MITM bych vyloucil. Pri prvotnim vyskytu problemu jsme i se zakaznikem, kteremu se takto jeho domaci routrik choval vyhodnotili, ze je ten routrik vadny. Byl vymenen a problem zmizel. Ted se mi na siti zjevily dalsi dva domaci routery, ktere se chovaji uplne stejne. Ve vsech trech pripadech se jedna o jineho vyrobce routeru, jedna se o zakazniky na jinych fyzickych vetvich site i jinych subnetech. Coz ve mne nahlodalo myslenku, ze se mozna nejedna o vadu zarizeni, ale ze se z nejakeho mnou zatim nepochopeneho duvodu ty zarizeni chovaji spravne a ja hledam pricinu v jine kupce sena. Resenim bude fyzicke oddeleni a odroutovani jednotlivych subnetu, na cemz se pracuje, ale predstavuje to rozsahlejsi rekonfiguraci site (vcetne zmen ve fyzicke topologii) a neni to otazkou nekolika dni. Workarround by byl zkratit dobu platnosti zaznamu v arp tabulce (nevim, jak dalece je to rozumne - a taky jsem zatim napatral po tom, jako toho na FBSD dosahnout). No a samozrejme nejlepsi resenei je pochopit proc se to deje a tem zarizenim vysvetlit, ze se tak nemaji chovat. Kdyby mel nekdo podobnou zkusenost pripadne nekoho napada, co s deje, pisnete mi, prosim. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
