[Snort-sigs] Unicast ARP Request: Considered Harmful?

Kevin Le Gouguec kevin.le-gouguec at ...3902...
Sun May 18 08:36:16 EDT 2014


The rule can be found in preproc_rules/preprocessor.rules:

alert ( msg: "ARPSPOOF_UNICAST_ARP_REQUEST"; sid: 1; gid: 112; rev: 1; metadata: rule-type preproc ; classtype:protocol-command-decode; )

It can be activated by adding "preprocessor arpspoof -unicast" to snort.conf.

I found some documentation on the website:

http://www.snort.org/search/sid/112-1

Again though, no explanation as to why a unicast ARP request is suspicious enough to deserve its own rule.
I get that "weird though apparently harmless" behaviour should be detected, and a unicast request could be just that (no reason not to broadcast a request, since either you contact the correct host directly so you already know his MAC address, or you contact the wrong host and the protocol states that he should discard the request). Except it's actually a legitimate feature used for cache validation. I'm ready to believe that it can be a sign of attack, but not before I understand why.



----- Original Message -----
From: "Joel Esler (jesler)" <jesler at ...3865...>
To: "Kevin Le Gouguec" <kevin.le-gouguec at ...3902...>
Cc: snort-sigs at lists.sourceforge.net
Sent: Sunday, May 18, 2014 1:25:40 PM
Subject: Re: [Snort-sigs] Unicast ARP Request: Considered Harmful?

It helps us to know which rule you are talking about though. 

--
Joel Esler
Sent from my iPhone

> On May 18, 2014, at 6:36, "Kevin Le Gouguec" <kevin.le-gouguec at ...3902...> wrote:
> 
> Hi all,
> 
> 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[1] for example, unicast "keep-alive" requests are even said to be a problem when implementing attacks).
> 
> I found a thread[2] 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[3] 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.
> 
> 
> 
> [1] http://insecure.org/sploits/arp.games.html ("What can be done", paragraph 5)
> [2] http://sourceforge.net/p/snort/mailman/message/15537465/
> [3] http://books.google.fr/books?id=sVqEFXjbcRoC&pg=PA162&lpg=PA162&dq=arpspoof+unicast&source=bl&ots=D3LwL4dWB8&sig=FTkey-EGTw7s5e9Uhlf4mS_fjVw&hl=en&sa=X&ei=HTl2U67xNJDR4QTt7YHYAw&ved=0CEwQ6AEwBw#v=onepage&q=arpspoof%20unicast&f=false
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org
> 
> 
> Please visit http://blog.snort.org for the latest news about Snort!




More information about the Snort-sigs mailing list