http://brezular.com/2015/05/03/decapsulation-erspan-traffic-with-open-source-tools/
But when I walked through this blog entry I was unable to get the tunnel to see the GRE decapsulated traffic. I do see the GRE encapsulated traffic on our monitoring interface (which I gave an IP address).
It sounds like at least some of the more important tools like snort and bro will work with GRE encapsulated traffic from initial searching. Do I just not try to setup the virtual interface with the traffic unwrapped and everything in Security Onion will know what to do when it sees the GRE encapsulation or do I need to troubleshoot why I'm not seeing packets in the tunnel interface?
TIA,
Steve
From having a look here, it appears Snort should have the ability to decode GRE traffic by default:
https://www.snort.org/faq/readme-gre
Bro also appears to support the use of GRE tunnels (I'm assuming by default):
https://www.bro.org/sphinx-git/install/release-notes.html
Traditionally, with Security Onion you would have a dedicated monitor interface (promiscuous mode, without an IP assigned) to collect traffic from a tap / SPAN port, and a dedicated management interface (IP assigned).
Snort and Bro will then listen on the monitor interface and process the traffic.
Is there any reason why you are not able to configure the machine as above?
Hopefully, this helps.
Thanks,
Wes
--
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 https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
Simply put: Firewall
My distribution doesn't need to be locked down for what I'm doing so I just ran: sudo ufw disable and the encapsulated traffic on my eth1 started pumping into the GRE tunnel interface of tun0.
Hope that helps!