ettercap MITM attack -- no events in Security Onion

[Jim Solderitsch]

I have a small test network 192.168.3.0/24 (although only a few hosts are live at any one moment) that I am sniffing with SO. I launch an MITM attack via ettercap between two of the hosts via an ettercap etterfilter running on a third host and I expected that out of the box I would see some events reported even without doing any rule configuration.

I did not see any events reported (Snorby/Sguil/squert) after the attack was completed.

Is this expected? I did a bit of on-line searching about MITM and SO and didn't discover anything right away.

I am willing to do rule additions/configuration. Using Snort rather than Suricata.

Suggestions appreciated.

Jim

[Jim Solderitsch]

After I posted this, I did find information about the arpspoof preprocessor and it was commented out in my snort.conf file. So I expect if I enable this with the right parameters I will see events/alerts. Will be trying that shortly.

[Jim Solderitsch]

I did make some changes to snort.conf for my attempt to detect MITM:

# ARP spoof detection. For more information, see the Snort Manual - Configuring Snort - Preprocessors - ARP Spoof Preprocessor
preprocessor arpspoof
preprocessor arpspoof_detect_host: 192.168.3.1 ba:f6:b1:71:85:64
preprocessor arpspoof_detect_host: 192.168.3.4 b8:27:eb:ac:86:3a

I re-started snort and did not see any events. I then restarted SO and still did not see any events after performing an instance of arp spoofing. Is there some other configuration changes I need to make? The host that is doing the MITM is at address 192.168.3.20. The hosts whose arp tables I want to protect are the ones listed in the arpspoof_detect_host lines. Maybe I need to consult some other places for information here.

Once again, pointers appreciated.

Jim

[Kevin Branch]

ARP poisoning attacks can be evasive of detection by a NIDS as the poisoned ARP streams can be sent purely as unicast packets to the MITM victims.  That means no evidence of such an attack is likely to traverse any of your network choke points that SO would be watching.  Some brands of switches support arp spoofing detection.  You might need to shift your detection of this out to your switching fabric and then have your switches send their logs via syslog to your SO box where you can build an OSSEC rule to alert you on this kind of event.

Kevin

--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[Jim Solderitsch]

Thanks for the information. There is a -unicast option to the snort preprocessor but adding that in did not seem to help. I just have a very trivial local network based on VMware connected to the OS X Shared Internet network and I will see if any logs are being kept anywhere in the virtual plumbing. I am just trying to learn what my options are and this information helps.

Thanks

Jim

[Richard Bejtlich]

Hi Jim,

Can you see the frames sent by Ettercap, if you run Tcpdump or Tshark or even Wireshark, on the sensor?

Sincerely,

Richard

[Jim Solderitsch]

I am running an all-in-one version of Security Onion where I am sensing the eth1 interface and using eth0 as the admin interface.

I am not sure how to run these tools on the sensor per se, although I can run them against the eth1 interface. SO will not allow me to run wireshark live against eth1 unless I run as root. I guess I need to try this to at least to see iff the arp frames appear.

I am running Kali Linux as one of the hosts on the network and this is the source of the ettercap attack. Running wireshark on this host shows me arp packets of course.

But the source and destination appear in a funny form like Vmware_9b:xx:yy and Raspberr_a0:uu:vv where I have removed the actual MAC-like characters -- not at all like numeric IP addresses. So these "addresses" might be invisible to SO. Can I add them to the HOME_NET in snort.conf?

Other events for this host that SO does detect like the curl test does appear in SO's UIs.

I guess being so primitive an attack provides a certain amount of stealth as far as SO is concerned.

Thanks for the response!

Jim

[Jim Solderitsch]

I just ran the command:

sudo tcpdump -n -i eth1 -e 'arp or icmp'

on the Security Onion VM and I am seeing plenty of arp traffic related to the ettercap attack including the "who-has" requests and then the resulting "is at" re-direct replies where the two hosts being attacked now relay through the attacker. So the issue of no SO events is not related to lack of visibility.

My enablement of the arpspoof preprocessor looks likt this:

# ARP spoof detection. For more information, see the Snort Manual - Configuring Snort - Preprocessors - ARP Spoof Preprocessor

preprocessor arpspoof: -unicast
preprocessor arpspoof_detect_host: 192.168.3.1 ba:f6:b1:xx:yy:zz
preprocessor arpspoof_detect_host: 192.168.3.4 b8:27:eb:xx:yy:zz
preprocessor arpspoof_detect_host: 192.168.3.20 00:0c:29:xx:yy:zz

where I use the actual MAC addresses for these hosts.

So still a little puzzled, although I appreciate that NSM is not the best place for detecting this type of attack.

Jim

[Jim Solderitsch]

I did some more research including searching this group and it looks like arpwatch and argus in combination may do the detection/alerting I have in mind since I can't get snort's arp spoof preprocessor to work. Looks like arpwatch is simple enough to get data coming in and out but I am not sure how I can use argus to integrate detection of arp spoofing into the core event collection processing and reporting offered by Security Onion.

Is there a tutorial I can follow to make this happen?

Tips appreciated.

Jim

[Jim Solderitsch]

I continue to beat my head against this wall.

Looks like the roadmap for Security Onion has arpwatch support scheduled for May 2015 (issue# 369). What to do in the meantime?

I did install arpwatch with apt-get and it functions from the command line in debug mode. I am monitoring my sniffing interface (eth1) and I see messages about new MAC addresses for the same IP address when I run my attack and I see lines formatted as emails about "flip flop" MAC addresses.

But if I run via /etc/init.d, then where can I find where these messages are being written/sent. Some of my research suggests that these messages are logged to syslog but SO uses syslog-ng and I don't see where I can go to see these messages.

Also the arpwatch docs say that emails can be sent when notable arp cache changes are detected. Can Security Onion do that? Or do I have to wait until the issue 369 is resolved?

Thanks for any advice here. Be glad to read the docs if there are some.

[Jim Solderitsch]

Just a note to say that even though the arpwatch log records are being eaten up by the Security Onion logging apparatus, the email functionality works if you have a working MTA -- using ssmtp for that. After an MITM attack I get emails delivered highlighting the suspect IP and MAC address pairings.

I made a new post asking for help on seeing OSSEC being able to generate alerts rather than producing mails (or in addition to). OSSEC out of the box is supposed to support that but I don't see how to configure that in Security Onion with my limited experience.

[Jim Solderitsch]

To resolve this thread, thanks to the advice of Kevin Branch, I am using arpwatch within Security Onion to create log records that OSSEC is able to process (once I divert the arpwatch log records via a modification to syslog-ng.conf) and the higher level alerts from OSSEC's rule supporting arpwatch appear as events in the squert UI. I did have to install arpwatch into SO and do some configuration.

But the effect I want to achieve is now visible. It took a fair amount of research and some trial and error to get here.

[Qing Wang]

Hi Jim,

I am facing the exactly same issue on ARP spoofing detection in SNORT/Security Onion. wondering how did you fix that problem back to that time? (What kind of configuration you have done?)

Looking forward to hear from you~

Thanks,
Jack