Please check my YAML rules to suppress Suricata alerts

[Green-Pool]

Version

2.4.60

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

12

RAM

64GB

Storage for /

200GB

Storage for /nsm

2TB

Network Traffic Collection

span port

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

Additional information:

• Host server: Dell R630, 1x E5-2699v3 18C/36T 2.3GHz 128GB Ram
• Host operating system: Linux Mint with Oracle Virtual Box as VM Host
• VM1: SO Standalone. 12 cores. 64GB RAM (58% in use). 200GB hard disk for SO and 2TB for data storage
• VM2. SO Intrusion Detection Honeypot. 2 cores. 2GB RAM (54% in use). 100GB disk space
• VM3. SO Forward sensor. 4 cores. 12GB RAM (48% in use). 200GB disk space
• Endpoints: Five desktops with endpoint agents (mix of Windows and Linux)

/opt/so/log/suricata/
1 rule files processes. 36850 rules successfully loaded. 0 rules failed.
Threshold config parsed: 0 rules(s) found

My installation is intended as a self-paced learning exercise. Installed on my home network with 43 client devices (desktops, phones, tv, IoT, security cameras, etc). Primary upstream network security is provided by Ubiquiti.

As it is a home network, some of the alerts can be suppressed. For example, rule.uuid, 2027397, “ET POLICY Spotify P2P Client”.

In idstools.sids.modify, I have added the following YAML rule;

# Suppress Spotify warnings
2027397:
  - suppress:
      gen_id: 1
      track: by_either
      ip: 192.168.0.0/16

However, Suricata is still generating alerts for this rule. Note the extract from the log (above) "Threshold config parsed: 0 rules(s) found"

I have also tried completely disabling the rule in idstools.sids.disable and this does not suppress alert generation for me either.

2048911
2018904
2027397

I suspect that the problem is the formatting of my YAML rules. Could someone please have a look at my modified rules for me?

In the dumb questions list;
Q1. I assume that I can include comments in my YAML rules (just to keep track of which modification is doing what?
Q2. For the idstools.sids.disable, it is just rule numbers?

Here is a slightly expanded extract of my YAML rules.

# Suppress Spotify warnings
2027397:
  - suppress:
      gen_id: 1
      track: by_either
      ip: 192.168.0.0/16
# Supress Android connectivity check on TV VLAN
2036220:
  - suppress:
      gen_id: 1
      track: by_either
      ip: 192.168.4.0/24
# Suppress QUAD 9 rules as we are directing traffic to QUAD 9
2048911:
  - suppress:
      gen_id: 1
      track: by_either
      ip: 149.112.112.112
# Suppress QUAD 9 rules as we are directing traffic to QUAD 9
2048911:
  - suppress:
      gen_id: 1
      track: by_either
      ip: 9.9.9.9

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[robbiemarshall]

Try removing those comments. Right now, comments are only supported for BPFs. You can also check your logs for any errors.

[Green-Pool]

Robbie,

Thanks for taking a look at my problem. I reloaded the file without comments, and the the rule suppression is still not working as I expected. If I am reading the log file correctly, (line 8) it seems to be saying that it has loaded a rule file correctly.

Nominating rule numbers in "NIDS rules manually disabled" dialog does not suppress alerts either.

I have also restarted the host VM. Below is the output of suricata.log after a few hours running.

[11 - Suricata-Main] 2024-05-01 00:39:55 Notice: suricata: This is Suricata version 7.0.4 RELEASE running in SYSTEM mode
[11 - Suricata-Main] 2024-05-01 00:39:55 Info: cpu: CPUs/cores online: 12
[11 - Suricata-Main] 2024-05-01 00:39:55 Info: suricata: Setting engine mode to IDS mode by default
[11 - Suricata-Main] 2024-05-01 00:39:55 Info: privs: dropped the caps for main thread
[11 - Suricata-Main] 2024-05-01 00:39:55 Info: conf: Running in live mode, activating unix socket
[11 - Suricata-Main] 2024-05-01 00:39:55 Info: logopenfile: eve-log output device (regular) initialized: /nsm/eve-%Y-%m-%d-%H:%M.json
[11 - Suricata-Main] 2024-05-01 00:39:55 Info: logopenfile: stats output device (regular) initialized: stats.log
[11 - Suricata-Main] 2024-05-01 00:39:58 Info: detect: 1 rule files processed. 36850 rules successfully loaded, 0 rules failed, 0
[11 - Suricata-Main] 2024-05-01 00:39:58 Info: threshold-config: Threshold config parsed: 0 rule(s) found
[11 - Suricata-Main] 2024-05-01 00:39:59 Info: detect: 36853 signatures processed. 1130 are IP-only rules, 4877 are inspecting packet payload, 30814 inspect application layer, 0 are decoder event only
[11 - Suricata-Main] 2024-05-01 00:40:03 Info: runmodes: bond0: creating 5 threads
[11 - Suricata-Main] 2024-05-01 00:40:03 Info: unix-manager: unix socket '/var/run/suricata/suricata-command.socket'
[11 - Suricata-Main] 2024-05-01 00:40:04 Notice: threads: Threads created -> W: 5 FM: 1 FR: 1   Engine started.

Is there another log file that could give me further clues?

[robbiemarshall]

I see the issue now. You're placing those suppress rules in the wrong location. They need to be under Suricata > thresholding > SIDs.

[Green-Pool]

Ahhh, thank you. My bad. A rookie mistake.

But I can confirm that (in the correct location) having comments in the YAML rules doesn't affect the engine.

The other thing I found out is that there can be only one SID. For example, if I need to suppress alerts for two local IP addresses, these need to be under the one entry (instead of two entries with the same SID but different IP address).

I am making a lot more progress with understanding Security Onion 2.4 than I ever had playing with previous versions. Next step is to write up some custom Suricata rules that I have in mind.