BPF rules don't block any traffic on Suricata, Zeek and Steno

[Axtrus]

Version

2.4.20

Installation Method

Security Onion ISO image

Description

other (please provide detail below)

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

64

RAM

252

Storage for /

2 TB

Storage for /nsm

2 TB

Network Traffic Collection

span port

Network Traffic Speeds

1Gbps to 10Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Hello everyone,

I'd like some help on my security onion server, in fact I'm trying to filter certain traffic in my network that I found to be noisy.
I've followed the instructions on the Security Onion documentation and created the following rules which are applied to the config section of BPF suricata, zeek and PCAP:

not (host 172.16.12.10 and host 172.30.224.94) &&
not (host 170.32.24.243 or host 170.41.0.67 or host 170.32.3.213 or host 170.34.3.42) &&
not (host 173.41.0.100 or host 173.34.0.110 or host 173.32.2.39 or host 173.32.1.110 or host 173.32.224.110) &&
not tcp dst port 7081 &&
not (src port 0 or dst port 0)

None of the above rules worked as intended, I'm still seeing Suricata alerts from these hosts.

Does anyone know how to make it work to block traffic from all hosts in the BPF rules above?
And could be the problem why it's not working ?

Regards.

Guidelines

• I have read the above statement and can confirm my post is relevant to Security Onion 2.4.

[dougburks]

Were you following the 2.4 documentation?
https://docs.securityonion.net/en/2.4/bpf.html

[Axtrus]

Here are the requested screenshots

[dougburks]

This is strange as I've tested Suricata BPFs on a system here and it works fine for me.

Can you confirm that this is a standalone installation and there are no other sensors sending Suricata alerts?

Have you made any other changes to the configuration?

What is the output of the following?

ps aux |grep suricata

Have you tried restarting Suricata?

Have you tried rebooting the box?

[Axtrus]

I confirm that this is a standalone installation and i have made no changes to the configuration

• Yes I've already restarted Suricata but it didn't work.

Yesterday I've rebooted the box after updating the BPF rules on Suricata and Steno. To my big surprise I saw that almost all rules are working now except this : not (src port 0 or dst port 0) as you can see in the screenshot below

[dougburks]

Looking at the screenshot, the alerts are for ICMP traffic. Unlike TCP and UDP, ICMP doesn't really have any concept of source port or destination port. (Suricata logs src_port as 0 and dest_port as 0 simply to indicate that there was no actual port value.) Therefore, applying a port-based BPF won't have any effect on ICMP traffic. Here are some alternatives:

• you could apply a BPF to exclude ICMP traffic altogether or based on source IP address or destination IP address (or both)
• you could disable or suppress the alert itself as shown at https://docs.securityonion.net/en/2.4/managing-alerts.html#disable-the-alert

[Axtrus]

Okay well noted, thanks for your feedback and support Doug.

[InfosecGoon]

It looks like you're using a mix of ANDs and ORs, which is a little confusing and may not be applying in the way you intend. Try something like this to ignore traffic from those hosts:

not host 172.16.12.10 &&
not host 172.30.224.94 &&
not host 170.32.24.243 &&
not host 170.41.0.67 &&
not host 170.32.3.213 &&
not host 170.34.3.42 &&
not host 173.41.0.100 &&
not host 173.34.0.110 &&
not host 173.32.2.39 &&
not host 173.32.1.110 &&
not host 173.32.224.110

[Axtrus]

Thanks for your response, I changed the configs and applied the rules as you've suggested but i got the same results

[Acewiza]

I've had issues with the BPF stuff. Not offering any insight or suggestions, but I've struggled with it in the past, not attempting it again until something changes.

LATE UPDATE: I take it back - working for me now.

[petiepooo]

Here's how we format and validate our BPFs; YMMV.

We format the yaml like this with different global and site-specific exclusions noted as comments:

zeek:
  bpf:
    - "!(udp port 123)&&" # GLOBAL
    - "!(ip net 15.0.0.0/8)&&" # HP GLOBAL
    - "!(ip net 17.0.0.0/8)&&" # APPLE GLOBAL
    - "!(ip net 31.13.74.0/24)&&" # FACEBOOK GLOBAL
    - "!(ip net 157.240.0.0/16)" # FACEBOOK GLOBAL

We also have installed the 'yq' package on the system, which is a yaml parsing and analysis tool similar to what jq is for json. With that tool, we are able to run this command to verify that the yaml syntax is correct and to generate the resulting concatenated BPF expression:

# yq '.zeek.bpf | ... comments="" | join(.)' /opt/so/saltstack/local/pillar/global.sls
!(udp port 123)&&!(ip net 15.0.0.0/8)&&!(ip net 17.0.0.0/8)&&!(ip net 31.13.74.0/24)&&!(ip net 157.240.0.0/16)

You can run the resulting expression into tcpdump in debug mode to verify it is valid BPF:

# tcpdump -d '!(udp port 123)&&!(ip net 15.0.0.0/8)&&!(ip net 17.0.0.0/8)&&!(ip net 31.13.74.0/24)&&!(ip net 157.240.0.0/16)'
(000) ldh [12]
(001) jeq #0x86dd jt 2 jf 8
(002) ldb [20]
(003) jeq #0x11 jt 4 jf 43
(004) ldh [54]
(005) jeq #0x7b jt 42 jf 6
(006) ldh [56]
(007) jeq #0x7b jt 42 jf 43
.........

You can use the so-bpf-compile script to check validity of the bpf syntax, which just calls tcpdump behind the scene and outputs the compiled BPF in bytecode:

# so-bpf-compile eno2 '!(udp port 123)&&!(ip net 15.0.0.0/8)&&!(ip net 17.0.0.0/8)&&!(ip net 31.13.74.0/24)&&!(ip net 157.240.0.0/16)'

Note the use of 'ip' preceeding each net or host block in the example. Without that, the block is checked twice: as bare IP and with a VLAN header. If you know you will not receive any VLAN headers, adding IP as part of the expression simplifies the resulting filter by avoiding that second check. To see for yourself, check the resulting debug output from tcpdump with or without it.

Also note extensive use of '&&' for AND and '!' for NOT. There is a limit to the length of the BPF string before zeek barfs on it, and those tokens are shorter than their equivalent strings, plus they allow you to eliminate surrounding spaces when placed next to other strings. Eg. you can use '!(ip&&port 53)' instead of '!(ip AND port 53)' which is a 12% reduction in string length for that example.

There is also a maximum length for the compiled BPF string that stenographer will accept. I have not seen these string length limits documented and have not fully characterized them myself, so just beware of really long BPFs.

[Axtrus]

Hi thanks so much for your participation and feedback but i tried to follow your suggestion and it didn't work.... I'm still seeing the traffic i don't want to see

[Acewiza]

You might actually want to "see" those alerts if using the log4 vulnerabilities - just not from certain hosts. Try putting just one argument in the 1st dialog and select the desired onion below, Like Doug suggested.

[innovate-support]

I experienced the same issue with BPF not seeming to work at all, and I was only trying to ignore 1 IP.
Only a reboot of the Sensor resolved the issue. After the reboot all the alerts that I wanted to ignore stopped appearing as expected.
I'm using v2.4.30 in a Distributed deployment.