BPF filter not working

[Kevin]

Hello,

I'm trying to perform a simple filter on one IP. My /etc/nsm/rules/bpf.conf file has one line:

!(host 10.5.79.151)

Ideally I'd like every service to filter this IP out, but the most important is not capturing and saving any traffic relating to this address. Even after running 'service nsm restart' I'm still seeing snort.log files containing traffic related to this IP address.

Any ideas as to why this is happening would be greatly appreciated.

Thanks.

[Kevin Branch]

Are any of your sensor interfaces receiving VLAN tagged packets?  If so, read the VLAN section of this page:

https://github.com/Security-Onion-Solutions/security-onion/wiki/BPF

Kevin

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
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.

[Kevin]

I tried that as well. That IP seems to still be getting through.

[Kevin Branch]

Have you confirmed that all the relevant /etc/nsm/HOST-IFACE/bpf-pcap.conf files are symlinked to /etc/nsm/HOST-IFACE/bpf.conf files which are themselves symlinked to /etc/nsm/rules/bpf.conf ?  

Also from the SO sensor where the incorrectly filtered traffic is being captured, when you run a live tcpdump using your unheeded BPF, do you see traffic involving the IP that is supposed to be excluded?

Kevin

[Kevin]

It appears that all the symlinks are in place. I've included a screenshot of them.

I'm seeing the host appear in tcpdump when running this command:

tcpdump -i eth2 | grep 10\.5\.79\.151

Was that what you were asking? Or did you want me to try using a filter in the tcpdump command?

[Kevin Branch]

Try this.  Do you still see the packets that the BPF is supposed to exclude?

tcpdump -i eth2 "!(host 10.5.79.151)" -nn | grep "10\.5\.79\.151"

If you do still see them, then try this:

tcpdump -i eth2 "not host 10.5.79.151 and not (vlan and host 10.5.79.151)" -nn | grep "10\.5\.79\.151"

Kevin

[Kevin]

Thanks, Kevin. I'm still seeing the packets after trying both of those.

[Kevin Branch]

Please send a screenshot of you running that last command command again, including the command and the first several lines of output.

tcpdump -i eth2 "not host 10.5.79.151 and not (vlan and host 10.5.79.151)" -nn | grep "10\.5\.79\.151"

Also, after running that tcpdump, you might take a peek at the output of "dmesg" to see if the kernel is barking about something.

I've never seen what you are describing, but let's see if we can yet get to the bottom of it.

Kevin

[lyse...@gmail.com]

Just to kick in… have you executed sudo rule-update after making the change to BPF

 

Regards,

Lysemose

[Kevin]

Thanks, Lysemose. I've tried running rule-update and the symlinks appear to all be working.

Kevin, I've attached the tcpdump screenshot. Anything I should be looking out for in the dmesg output?

[Kevin Branch]

Kevin,

Aha, you have GRE encapsulation going on.  That is why your BPF isn't working.  The BPF criteria is applying to the outer GRE packet, not to the IP packet encapsulated within the GRE packet.  Now why do you have GRE packets at all?  Are you using some kind of RSPAN to get your mirrored traffic?  

Kevin

[Kevin]

Ahh okay, yes sorry, I should've mentioned that all traffic on that interface is coming from a span port. Is there anything we can do to filter it out?

[Kevin Branch]

What kind of switch are you using and how is the span port configured?  Most span/mirror ports don't encapsulate the traffic like that.  If your environment requires that the span port traffic be GRE encapsulated, there should still be a way to work with it, but let's make sure it is needed first.

Kevin

On Wed, Jul 27, 2016 at 12:15 PM, Kevin <kdse...@gmail.com> wrote:

Ahh okay, yes sorry, I should've mentioned that all traffic on that interface is coming from a span port. Is there anything we can do to filter it out?

[Kevin]

This sensor is currently deployed in a client's network. I'm waiting to hear back what we can do about the encapsulation.

[Kevin Branch]

In the mean time, you might look this over:

http://brezular.com/2015/05/03/decapsulation-erspan-traffic-with-open-source-tools/

Which option to use depends on whether you have plain traffic encapsulated in a GRE tunnel or ERSPAN-encapsulated packets inside of a GRE tunnel.

Kevin