Suricata: rule mismatch + so-elastalert missing +

[ejgh-oe]

Version

2.4.70

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

10

RAM

32

Storage for /

500G

Storage for /nsm

500G

Network Traffic Collection

span port

Network Traffic Speeds

1Gbps to 10Gbps

Status

No, one or more services are failed (please provide detail below)

Salt Status

Yes, there are salt failures (please provide detail below)

Logs

No, there are no additional clues

Detail

Hi,
After upgrading from 2.4.60 -> 2.4.70 I had to reboot all nodes because OS-Updates were installed automatically waiting to be activating by rebooting all nodes (Status "Reboot" on the Grid display). After rebooting the manager mode didn't come online (Status "Fault").

Rebooting the manager node didn't help - neither did salt-call state.highstate

# salt-call state.highstate
[INFO    ] Creating module dir '/var/cache/salt/minion/extmods/grains'
[INFO    ] Syncing grains for environment 'base'
[INFO    ] Loading cache from salt://_grains, for base
[INFO    ] Caching directory '_grains/' for environment 'base'
local:
    Data failed to compile:
----------
    The function "state.highstate" is running as PID 303805 and was started at 2                                           024, Jun 14 14:25:45.126449 with jid 20240614142545126449
#

Tried "salt-call state.highstate" several times over half an hour or so - same error message as above.

On the Detections tab I also got a "!" likely to be caused by this:

Clicking on "Suricata Rule Mismatch" brings me to the Hunt interface giving

and scrolling to the right reveals

Interestingly enough the problems mentioned above didn't occur after upgrading from 2.4.60 > 2.4.70 - they started after rebooting all nodes as of today.

Thanks much in advance for any clue...

Guidelines

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

[cm-ops]

If you click on the "Rule Mismatch", and filter for the "Integrity Check Report" log, what does it show?

Also, if so-elastalert is still showing missing, check your Elasticsearch cluster health - sudo so-elasticsearch-query _cluster/health?pretty

[ejgh-oe]

First of all the good news: the "so-elastalert"-problem seems to have disappeared over time - after several hours (basically overnight) so-elastalert was up&running again without any intervention from my side.

The "Rule Mismatch"-problem is still there though. Filtering for "Integrity Check Report" gives

and scrolling down further

So these errors occur every couple of minutes

I exported one of the detail pages to json and found something very interesting:

There's a section soc.fields.deployedButNotEnabled

with the following content:
"soc.fields.deployedButNotEnabled": [ "9000008", "9000021", "9000020", "9000017", "9000016", "9000018", "9000002", "9000009", "9000013", "9000005", "9000004", "9000011", "9000012", "9000003", "9000007", "9000015", "9000019", "9000006", "9000010", "9000014" ],

These numbers seem to correspond to the SID-numbers of my local suricata rules.

These rules have been there for quite a while and I never had any problems with them. I configured then in 2.4.60 via Administration > Configuration > Advanced settings > idstools > rules > Local Rules and they've been working perfectly since then.

To me it seems like SecurityOnion is complaining about local rules, despite they seem to work OK (if the weren't working I had got tons of false positives).

Any clue as to what's going on here?

[defensivedepth]

Yes, this is a known bug that will be fixed in the upcoming release.

[ejgh-oe]

Perfect - thanks much.

[defensivedepth]

@ejgh-oe 2.4.80 was released yesterday and has a number of fixes for Detections. I would suggest upgrading and seeing if that fixes the issue.

[ejgh-oe]

Thanks for letting me know. I've already planned upgrading to 2.4.80 early next week - keep you posted as to the result.

[ejgh-oe]

Hi,
Unfortunately, upgrading to 2.4.80 didn't solve the problem - Suricata rule mismatch is still there flagging all my custom rules (range 9000000 and above); same behavior as the one I described in my postinv above.
Please let me know if you need any logs, screenshots etc. - anything that can help in tracking this down.