ARP Flood

[Verwijderd]

Sinds enige tijd hebben we problemen op ons netwerk v.w.b. de performance. We hebben 14 switches, verdeeld onder twee stacks. De beide stacks zijn verbonden met een dubbele glaskabel (2 Gb). Alle traffic lampjes op beide stacks staan bijna constant aan. Als ze al knipperen gaat dat synchroon.

We hebben een sniffer losgelaten op het netwerken het blijkt dat er enorm veel ARP pakketten verstuurd worden van een vaste source (alleen MAC bekend) naar FF.FF.FF.FF.FF.FF

Daarnaast zijn er een hoop clients die UDP pakketten versturen naar MAC FF.FF.FF.FF.FF.FF met ip adres 255.255.255.255

Wie weet hoe ik een MAC adres kan opsporen en wie weet een oplossing voor het hele probleem.

TIA

[ACoolDude]

je zou als je kwalitatief goede switches hebt, de poorten van de switches uit kunnen lezen. Hier wordt dan het aangesloten mac-adres vermeld. Cisco heeft deze feature standaard, ik weet niet wel merk jullie hebben.

[ACoolDude]

Nog eventjes dit: Met het commando "arp -a" kun je ook in je lokale tabel kijken, wellicht dat dat ff.ff.ff.ff.ff systeem ertussen staat, dan heb je gelijk het IP adres

[Krypt]

FF.FF.FF.FF.FF is het broadcast MAC adres... zit een computer te schreeuwen over het netwerk metde vraag welk ip-adres bij welke mac hoort...

Normaal worden broadcast in hetzelfde segment gehouden tenzij dit wordt toegelaten door je routers.. of heb je geen routers ertussen staan??

[edit]
In de sniffer info moet ook de inhoud van het ARP pakket staan.. hierin staat meestal wie om welk ip zit tevragen..

[ACoolDude]

De udp paketten naar ff.ff.ff.ff.ff zijn dus normale broadcasts, da's correct Krypt.
Maar dat verklaard niet waarom er vanaf 1 werkplek zo'n ARP flood komt.

[ACoolDude]

Dit vond ik bij google. >> http://www.incidents.org/react/code_redII.html

[Krypt]

Kan vanalles zijn... Heb ik bij een klant ook gehad, bleek een brakke netwerkkaart te zijn..

Weet niet precies wat ie deed, maar het lijkt wel erg verdacht veel op dit..
Computer zit het netwerk rond te schreeuwen (de vraag zit in het arp pakket) en aangezien het ip niet bekend is begint elke pc weer rond te schreeuwen met de vraag wel ipadres de computer met dat macadres heeft... et voila.. UDP broadcast storm..

Kijk eens naar de eerste reeks van het macadres, daarmee kan je zoeken van welke fabrikant het kaartje vanaf komt.. en ook ff in het pakket zelf kijken..

[edit]
Virii kan het ook zijn, niet aan gedacht..

[Verwijderd]

Heb de veroorzaker al gevonden. Heb een network scanner gebruikt om alle devices op het netwerk te scannen en heb via een search het MAC adres weten te achterhalen.

De pc waar de ARP pakketten vandaan kwamen had een SETI client geinstalleerd. Toe de client uitgeschakeld werd was de ARP flood over. Kan me bijna niet voorstellen dat een SETI client zoveel verkeer veroorzaakt....

Overigens was er in het pakket niets te lezen. behalve het suorce en destination adres stond er weinig in.

[Krypt]

Wijst toch op een rotte kaart...Grote kans dat als je dat ding boot onder dos, dat de broadcasts weer terugkomen.. SETI heeft er niets mee te maken, lijkt me..

[Verwijderd]

als het echt arps zijn kun je toch in het pakket zien van welk ip adres het mac adress gezocht wordt, dan zie je gelijk wat er probeerd bereikt te worden, zet dan gelijk ff een flood limit op de betreffende poort, kan het niet zo'n grote impact meer hebben,

Krypt schreef op 10 september 2002 @ 09:53:
Wijst toch op een rotte kaart...Grote kans dat als je dat ding boot onder dos, dat de broadcasts weer terugkomen.. SETI heeft er niets mee te maken, lijkt me..

[Verwijderd]

Betreffende poort? Van de switch bedoel je?
Voor zover ik de switches heb bekeken (Baystack 450) is daar weinig op in te stellen.

[Verwijderd]

das jammer, want daarmee had je de impact kunnen verminderen.

[Verwijderd]

Heb je geen last van broadcaststorms? ofwel een loop in jouw switch omgeving. Je geeft al aan dat de beide stacks verbonden zijn met dubbele glasvezel kabel. Wanneer deze niet gechanneld zijn, dan kun je last krijgen van een broadcast loop. Het zou kunnen dat een broadcast van de ene stack naar de ander stack gestuurd wordt en weer terug. etc. etc. Cisco gebruikt hiervoor de spanningtree protocol die bij dubbele verbindingen 1 poort blokkeerd zodat broadcaststorms worden voorkomen.