Suricata rule disable & suppression not working in 2.4

[tsmith-spscc]

Version

2.4.60

Installation Method

Security Onion ISO image

Description

other (please provide detail below)

Installation Type

Distributed

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

24

RAM

192

Storage for /

1 TB

Storage for /nsm

40 TB

Network Traffic Collection

tap

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

I am trying to tune my Security Onion configuration and it appears that some (if not all) Suricata alerts are not being either disabled or suppressed using the methods described in the "Managing Alerts" section of the manual.

For instance, I am trying to bulk disable the STUN Suricata rules using the following syntax:

re:STUN

I have placed this in the following location:
Administration > Configuration > idstools > SIDS > Disabled

Additionally, I am trying to suppress specific alerts by filtering specific IPs. One alert in particular is generating millions of alerts a day and is a known false positive in my environment. The syntax used to suppress the alert is:

2101411:

• suppress:
  gen_id: 1
  track: by_src
  ip: 10.20.80.50

This has been placed in the following location:
Administration > Configuration > suricata > thresholding > SIDS

I am still receiving alerts for the above rule where the source IP listed in the suppression configuration is the source IP in the alert.

In both instances, the grid values have been applied and all nodes have been updated. These configuration changes have been in place for well over a week and I am still receiving these alerts.

Any assistance is appreciated.

Guidelines

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

[tsmith-spscc]

Clearly I did something incorrect with the post formatting, but rest assured the suppression configuration I've applied uses a - not a bullet point.

2101411:
  - suppress:
      gen_id: 1
      track: by_src
      ip: 10.20.80.50

[Syngelik]

Seconding this issue, entered SID 2100366 in disabled within configuration, alerts for that rule are still flowing in and no change was made to the file in suri/all.rules - Ended up commenting it out manually. Confirmed no flowbits are set.

EDIT: Closer inspection shows that the disable.conf file under idstools/etc is blank, so looks like the GUI change isn't making it to the backend conf files for the next highstate...?

[InfosecGoon]

Disabling the rule should put the SID into /opt/so/saltstack/local/pillar/idstools/soc_idstools.sls - is there anything in that file?

[tsmith-spscc]

Yes, the rules I attempted to disable appear in the soc_idstools.sls file.

In what file do the suricata suppression configurations live? I'd like to check that as well if possible. Thanks.

[Syngelik]

@InfosecGoon - Also see the SID in the .sls file, any ideas?

This was a fresh install with next to no other changes made.

[tsmith-spscc]

Changes to Suricata rules, both disabling and suppressions, are now working for me. I made no changes to the method in which I disabled or suppressed a Suricata rule, it just started working. Although it did take weeks in some cases for the rule change to take effect.

Playbook custom filters still aren't working though.