-
Version2.4.70 Installation MethodNetwork installation on Red Hat derivative like Oracle, Rocky, Alma, etc. Descriptionupgrading Installation TypeEval Locationon-prem with Internet access Hardware SpecsMeets minimum requirements CPU4 RAM8 Storage for /1TB Storage for /nsm1TB Network Traffic Collectiontap Network Traffic SpeedsLess than 1Gbps StatusYes, all services on all nodes are running OK Salt StatusNo, there are no failures LogsNo, there are no additional clues DetailRecently I upgraded to 2.4.70. I was running a recent release before that as well. I had local rules configured, as well as thresholds. So, after reading in the documentation was "Rule Mismatch" implies, I remove the local rules, as well as the thresholds, hoping I could configure them again via detections later. Currently, no local rules are configured and no thresholds are set. I switched back to only using the ETOPEN ruleset, seeing also the ruleset import via url has been made readonly. Yet, I still get the rule mismatch in the detections tab. I checked the logs, and I can see that the integrity check has failed (
How can I remediate this issue? PS. The issue may be related to or be similar to the issue in #13109 Guidelines
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 19 replies
-
|
Custom rulesets via the URL option is not currently supported in Detections, which is why you are seeing a Custom rulesets via the URL is on the roadmap - #13115 |
Beta Was this translation helpful? Give feedback.
-
|
I have already removed all custom rules, being those present under local rules and those imported via URL. I rebooted the machine several times, yet rule sync is not possible. Moreover, the rules mentioned in the integrity check report as I think the Detections module reached something like a deadlock due to an initial configuration it could not handle. Now that the configuration is set to something it should be able to handle, it's not able to recover as it appears to me. Is there any way to fully reset the Detections module? |
Beta Was this translation helpful? Give feedback.
-
|
@Koen1999 Do you have any custom configuration? |
Beta Was this translation helpful? Give feedback.
-
|
I configured some Suricata address groups and port ranges, and a couple that are unrelated to detections such as allowed IP ranges. All these configurations were changed through the Configurations tab in the Web UI. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so looking at the integrity check report: {"fields":{"deployedButNotEnabled":["2005216","2040859","cut off here, but a lot more rules."],"detectionEngine":"suricata","enabledButNotDeployed":[],"intCheckId":"3e1146d5-9540-4ee1-b233-5a59b849c7bc"},"level":"info","timestamp":"2024-05-31T13:44:18.475761792Z","message":"integrity check report"} Can you confirm that the rule with the SID of 2005216:
|
Beta Was this translation helpful? Give feedback.
-
|
Also, after you have completed the above, please do the following: Run |
Beta Was this translation helpful? Give feedback.
-
|
@defensivedepth , thanks for the additional support.
The rule is clearly enabled. I can also confirm having received alerts associated with some of the rules mentioned in the integrity report. Please find below the output of |
Beta Was this translation helpful? Give feedback.
-
|
@Koen1999 Ok, let's try a different angle.
And then click a Also, what OS are you running? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so I didnt realize that the Suricata rules didnt import at all. So let's hone in on that import process:
Then do a Full Sync and post the output. |
Beta Was this translation helpful? Give feedback.
-
|
As part of that, also grep the logs for:
|
Beta Was this translation helpful? Give feedback.
-
|
I did not truncate the log file this time, due to it's length, I attached it as a file. |
Beta Was this translation helpful? Give feedback.
-
|
@defensivedepth , I just followed this step linked in the other issue (#13124 (reply in thread)) and found that it helped resolve a failure when calling |
Beta Was this translation helpful? Give feedback.
-
|
Great to hear! |
Beta Was this translation helpful? Give feedback.
-
|
@defensivedepth , do you know how adding local rules should function? After the initial import had succeeded, I added local rules using the + button in the detections menu. With those rules disabled, everything works fine, but once I enable them, I get the rule mismatch, saying that some rules are deployed but not enabled. If I check which rules are enabled under idstools in the configuration menu, I can see that the detections module has added my local rules to the (first empty) list. |
Beta Was this translation helpful? Give feedback.
-
|
I tried calling salt state.highstate, and then did a full sync using the detections interface. It did not resolve the issue. |
Beta Was this translation helpful? Give feedback.
-
|
Can you confirm that the new rules are in |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I just checked and can confirm that the local rules added through the detections menu are present in |
Beta Was this translation helpful? Give feedback.
-
|
@Koen1999 On Friday we internally confirmed there is a bug with the Suricata integrity check when adding custom rules and enabling them. We are working on a fix. Functionally it is working as expected (the custom rules are being deployed), but the integrity check is not seeing those rules. |
Beta Was this translation helpful? Give feedback.
-
|
@defensivedepth , thanks for the update. I will patiently await the bug fix. |
Beta Was this translation helpful? Give feedback.
@defensivedepth , I just followed this step linked in the other issue (#13124 (reply in thread)) and found that it helped resolve a failure when calling
salt-call state.highstate. I had rollover configured to 1 day, which apparently caused issued for the detections module. After following the steps mentioned there, the issue can be considered resolved for me.