Unicast ARP Requests: Considered Harmful?

Question

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 ("What can be done", paragraph 5) for example, unicast "keep-alive" requests are even said to be a problem when implementing attacks).

Yet this rule exists, and I cannot find any justification. Why is it suspicious for an ARP request to be unicast, when apparently in a lot of implementations this is considered a feature? 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.

Answer 1

The normal usage of ARP is through broadcast frames, because ARP is meant to allow machines to discover the MAC addresses of other hosts: this makes sense only if the MAC address is, indeed, not known beforehand. Normally, a machine is responsible for responding to requests about itself: if someone asks for the MAC address of the machine who currently owns IP address 10.0.17.42, then the said machine is supposed to respond; and, more importantly, other hosts on the network will refrain from responding, even if they know the MAC address of the current owner of the 10.0.17.42 address.

That only the address owner actually responds avoids drowning the network. If any machine was responding to all requests it sees, then a broadcast ARP request on a busy network could trigger hundreds of responses.

For a unicast ARP request to make sense, it should be sent to an host for which the MAC address is known, so not the IP address owner itself (otherwise, what would be the point of the request ?); but that host will not, by default, respond. Thus, legitimate unicast ARP requests will occur only in contexts where there is a known ARP-responder that has been configured to answer to ARP requests for IP addresses allocated to other machines. This is a rather unusual setup.

A Linux system can be configured to respond to ARP requests for other machines' addresses; this is called Proxy ARP. The main use case, though, is for some transparent firewalling: the LAN is split into several distinct LANs, without the local machines to be aware of the splitting. The machine which connects the sub-LANs together runs proxy ARP in order to maintain the illusion of a single LAN, while still filtering communications. But in that case, the machines are unaware of the setup; a unicast ARP request would occur only from one of the machines which would somehow know that a LAN-splitting was done.

So, in practice, unicast ARP requests are usually the sign of foul play. Normal machines won't do that.

Answer 2

Possibly due to MAC flooding attack - a kind of Unicast flood attack where an attacker would exhaust space in the MAC allocation table of a switch, so not being able to find the right address in the address cache (all were supplied by the attacker), it would flood the packet out to all ports (if a switch received a unicast packet with a destination address unknown to it, the packet is treated like a broadcast packet and is sent out to all hosts on the network). After most/all/target legitimate MACs were forced out of the table, it's a nice time to start a packet sniffer as the previously unavailable packets that were spat out by the switch are purportedly available for capture. Even if no packet capture intended this is already a type of DoS attack, esp. in large networks (due to the number of clients talking to the switch), which certainly degrades network performance.

BTW, unicast ARP requests are legitimate as per RFC1122 which states on Page 23:

(2) Unicast Poll -- Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls. Again, the timeout should be on the order of a minute, and typically N is 2.

Answer 3

I don't know any legitimate use for a unicast ARP request. You mention that this is a feature of some implementations; do you have any further details of that?

I suspect the malicious use for a unicast ARP request is to circumvent anti-spoofing features. For example, the Linux kernel won't listen to an unsolicited ARP response, but you can use a spoofed ARP request to trick it into thinking a response is solicited. And a unicast request is less likely to affect other devices or get noticed than a broadcast request.

Given there are so many rules in snort, I suggest you focus on gaining experience with a range of issues, rather than focusing on this one issue in great detail.

Answer 4

After some back-and-forth on the Snort mailing list (and failing to contact the author for this rule), I have decided to take

It's not the defined behaviour, and although ARP Polling may be a thing on some specific systems, the rule still needs to be there because we do not know a priori whether it's justified by some context-specific mechanism. And even if we do not see how they could be dangerous, there is no reason for a legitimate host to send unicast requests, and so it should trigger an alert like any unorthodox behaviour.

for an answer. You guys raise interesting points, but they are more like educated guesses and less like the "definitive" answer I sought, which I guess only Jeff Nathan can provide.

Thanks for your answers though, I did learn from them.

NB: before my edit this answer hazarded that maybe this was because a host adds a MAC<->IP pairing to his table regardless of whether the incoming ARP packet is a request or a reply (and so you could flood a host's table by sending requests), but then I realized that the reception algorithm in RFC 826 makes a host update his table as long as the Protocol Destination field corresponds to his IP, so the request would not have to be unicast for this attack to work - back to square one.

NB2: I had a fun talk with a colleague who is much more experienced than I am on the subject. I asked him about the rule and when I told him about ARP Polling his first reaction was to flip completly and run back to his machine to make sure it wasn't sending this kind of requests. Because there's no reason his computer should be talking to the network when he doesn't mean to :) (also because he argues that for a host that you do not contact frequently, this polling feature results in useless traffic).