5

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.

2

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.

|improve this answer|||||
  • 1
    Cf. RFC 1122 § 2.3.2.1 (mentioned by JSmyth): unicast requests can be sent to a host whose IP is known to validate cache entries. Thanks for explaining the Proxy ARP thing :) – Peniblec May 17 '14 at 15:51
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.

|improve this answer|||||
  • Thanks, Unicast Poll was indeed what I was referring to when I said it could be "a feature". Okay this required some reading about how MAC address tables work but I think I got it. Any reason the attacker would flood the switch with ARP requests, of all things? – Peniblec May 17 '14 at 16:11
  • @Peniblec Well, maybe to see if the target hardware goes nuts when, say, you send out something like "Who has 192.168.0.1 - tell 192.168.0.1" to 192.168.0.1 which is a switch? A Cisco guy would know this for sure. Looks like you do think creatively enough though (: – JSmyth May 17 '14 at 16:38
1

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.

|improve this answer|||||
  • As mentioned by JSmyth, RFC 1122 § 2.3.2.1 defines "Unicast Poll" as a mechanism for ARP cache validation. Good point about the spoofed request though. As for what I should focus on, I do plan on getting a broader view on network threats :) I just noticed this particular rule did not make sense to me, so I figured I'd ask. – Peniblec May 17 '14 at 15:42
  • @Peniblec - ok, I see. I expect a large number of snort rules will trigger on things that are theoretically legitimate. The point is to trigger on things that are likely to indicate an attack and unlikely to false positive. IDS is far from perfect, but it does have its uses. – paj28 May 17 '14 at 16:41
0

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).

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.