OT: záhadne chovani nekterych zarizeni v siti

[Mila Sos]

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.
>
>