Suricata rule mismatch in 2.4.90

[Syngelik]

Version

2.4.90

Installation Method

Security Onion ISO image

Description

other (please provide detail below)

Installation Type

Standalone

Location

airgap

Hardware Specs

Exceeds minimum requirements

CPU

24

RAM

64 GB

Storage for /

500 GB

Storage for /nsm

48 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

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

Detail

My issue essentially mirrors the issue described in #13124

My initial installation was on release 2.4.60, after upgrading to 2.4.70 the issue began though instead of resolving as it did for a few in the above discussion after going to 2.4.80, I'm still experiencing it on 2.4.90.

After clicking on suricata rule mismatch within the detections tab

The message found within each of the warn events shown on the first picture "integrity check failed"

I would say very few configuration changes in the grand scheme of things had been made prior to 2.4.80 and only a couple of tuning changes as well. Forcing a sync of any kind within detections changes nothing, there are no entries in local.rules, and the metadata engine is still Zeek. There are no errors when running salt-call state.highstate

Please let me know what else I can try!

Guidelines

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

[Carlos-mb]

Look at this: #13525

[Carlos-mb]

This solution is much better: #13238 (reply in thread)

[Syngelik]

So I did come across this, but we're talking about a count of ~3500 total rules if I'm adding the two groups together. That's insane, is there no better way than manually enabling or disabling each rule?

[Carlos-mb]

I remember I was able to mark all rules listed using a filter and disable and enabled all together. Can you do that?

[defensivedepth]

@Syngelik Can you please post the output of the following, run from the Manager:

sudo salt-call pillar.get idstools

[Syngelik]

local:
----------
enabled:
True
sids:
----------
disabled:
enabled:
modify:
- 2013031 "startswith;" "startswith; content: !"redacted"; nocase;"
- 2013030 "startswith;" "startswith; content !"redacted"; nocase;"
- 2013028 "startswith;" "startswith; content: !"redacted"; nocase;"

[Syngelik]

Is there a way to reset the rules that are enabled/disabled to default?

I'm thinking I can disable and enable every suricata rule in detections and that should "reset" their status... if that makes sense.

[Syngelik]

Well I tried doing the above for kicks because I didn't mind having all rules enabled. now there are just 17408 rules enabled but not deployed. All 53k and change ET Open rules are now showing under enabled from the above output now instead.

[defensivedepth]

@Syngelik Is there literally nothing in the enabled or disabled section when you run sudo salt-call pillar.get idstools ?

Also, please confirm what version you are on - .80 or .90 ?

[defensivedepth]

eh, can you post the full output. ?

[Syngelik]

[Syngelik]

@defensivedepth Any other thoughts? Is there a way I can prevent it from trying to go out to the internet, presumably github?

[defensivedepth]

Can you doublecheck what version you are on?

[Syngelik]

[Syngelik]

Upgraded to .100, seems to have fixed it. Thanks.

[Syngelik]

@defensivedepth I lied, it blew up again. Kind of at a loss why the airgap installation insists on going out..?

[Syngelik]

I removed my proxy from all configurations and that allowed me to run the rule-update command and fixed the issue.