[nSLUG] Getting CPU cycles during an ARP storm
donald.teed at gmail.com
Sun Sep 18 21:32:42 ADT 2005
On 9/18/05, Stephen Gregory <nslug at kernelpanic.ca> wrote:
> Dual cpus can help, however in your case the pci bus may have been close
> to saturation so no ammount of cpu power would have help. A dedicated
> firewall would have helped. It should packet filter only, no proxies,
> and limits set on the ammount of logging. A single cpu linux box would
> be sufficient.
I talked to one other user who didn't notice a slow down
on their system and they claimed to not be running
the Win XP firewall. That, and the task manager or top
on Gentoo running on sparc showing a high load factor
seemed to indicate that it was purely the task of looking
at the packets in that volume which was taxing the
performance. If I unplugged the ethernet cable, the system
became responsive. Not knowing what the source
of the storm was, and what it might intend to do as an exploit,
I didn't try shutting off either variety of software firewall.
I am a little concerned that you saw a large volume of arp requests, and
> that those requests caused a denial of service. Arp is a local network
> protocol so such an attack would indicate a local attack. Arp should
> also be handled by the network card. And should not slow down the
> system. The only way an arp storm would impact the cpu is the network
> card was in promiscuous mode.
It was a local network issue, and I don't know what was learned
about the source of it.
I tried to simulate the problem at home using macof (part
of dsniff package on Debian). It can produce a high volume of
arp garbage. However it did not replicate the CPU hit on
a Win XP target running the XP SP2 firewall. Also tried
havoc, mentioned on packetstorm, and that produced a 30%
CPU hit on a PIII-700 laptop, but other than lack of ethernet,
it didn't make the system unresponsive.
There are tons of exploits and tools out there, and the simple
description of ARP flood probably doesn't really describe what
had happened that day.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG