[Snort-sigs] Unicast ARP Request: Considered Harmful?
Kevin Le Gouguec
kevin.le-gouguec at ...3902...
Sun May 18 06:32:04 EDT 2014
I'm playing around with Snort's downloadable rules and I found one which is easy to activate: sending a unicast ARP request. Okay, so I start injecting ARP requests, making sure the destination is not set to broadcast. And sure enough, Snort picks it up. Great, let's move on and do more complex stuff.
Though, I'm not sure I understand why this rule exists at all. From what I've read most ARP spoofing/cache poisonning attacks make use of ARP replies; requests do not seem to cause anyone any trouble (here for example, unicast "keep-alive" requests are even said to be a problem when implementing attacks).
I found a thread where Jeff Nathan explains what the ARP preprocessor does, but not why. He points at TCP/IP Illustrated's chapter 4; I skimmed through it, but I could not find a justification for this rule.
So why is it suspicious for an ARP request to be unicast, when apparently in a lot of implementations this is considered a feature (e.g. ARP polling in RFC 1122 provides cache validation) ? There's a book on intrusion detection focusing on Snort that says "ARP requests that are sent to a Unicast address are often the sign of an attack designed to modify ARP caches". I... can't see how?
Then again, I don't have much experience with network security so I guess I'm not thinking creatively enough.
 http://insecure.org/sploits/arp.games.html ("What can be done", paragraph 5)
More information about the Snort-sigs