HostDoS[8] Attack ( arpNd ) detected on vlan

  • 0
  • 3
  • Question
  • Updated 2 years ago
  • Answered
I have enterasys S8 switch and found following log on the switch. we have found many no of SA  mac addressees in the logs.

HostDoS[8] Attack ( arpNd ) detected on vlan.0.6 [ InPort(ge.8.27) LEN(64) DA(FF:FF:FF:FF:FF:FF) SA(00:1C:C4:54:EC:25) ETYPE(0806) ]

how should i identify the exact loophole, we have not implemented and configured ipv6  in the network.

Photo of Sandeep Rajguru

Sandeep Rajguru

  • 112 Points 100 badge 2x thumb

Posted 3 years ago

  • 0
  • 3
Photo of Martin Flammia

Martin Flammia

  • 5,048 Points 5k badge 2x thumb


Out of interest, where a lot of these SA mac addresses logged against the same port? - assume you have considered implementing antispoofing to close the loophole?

Photo of MartinS


  • 430 Points 250 badge 2x thumb
We have the same issue with 2 different customers!
SSA HostDoS[1] and S8 Chassis HostDoS[4]
Photo of Mike D

Mike D, Alum

  • 3,852 Points 3k badge 2x thumb
Hello Martin, Sandeep,

The arpNd hostdos log entry is tripped by a single device sending more than 3 arps (or neighbor discovery packets) in <.5 seconds. 

The action taken is this:  That SA is put in the penalty box for a short period of time.  The router will not process arps (nor nd...) for this end station during this period.  
After the time interval has passed, traffic is again allowed from that source address.  If still misbehaving, back to jail.  
No penalty in the traditional sense of course -  The client doesn't know and doesn't care about the steps taken by the router.  It's about protecting functional capacity on the router.

Then we're back to the original question from Sandeep: 
so what's going on?
Understanding the criteria for the arp/nd attack flag gives you a single piece of data.  You need more.  The messaging itself is descriptive enough. It might be all you will need:  vlan, port, mac; the location and address of the offending end station.  
Or - understanding context may still be a stretch. 

How the network arrives at this point is a broad topic; I won't be covering it in detail here.  With a little luck, a few thoughts will allow you to put still more puzzle pieces in place.

Naturally, this event may be an attack.  Maybe nefarious activity on the part of a user - or some other presence on your trusted network.  It may be something as simple as glitchy equipment may be responsible.   Maybe a bad piece of hardware rapidly sending arp, or  a nic driver sending high rates of neighbor discovery or arp (seen in power save mode), maybe a L2 loop, maybe a security scan tool running.  We've encountered each of these in gtac.  
I'm sure there are other circumstances we haven't yet seen that result in replication of - or repeating of - broadcast and/or multicast traffic.

Let us know how it turns out Gents