Suricata disablesid.conf and expected suricata log output

darcey

If I disable rules by GID:SID using an SID management file, I still see those rules apparently being parsed at startup in the suricata.log.

e.g. I tried disabling a few rules for which I see SC_ERR_INVALID_SIGNATURE in the log. Then I restart suricata.
However suricata.log shows similar errors/warnings for those SIDs yet /var/log/suricata/suricata_vtnet023002/sid_changes.log seems to indicate the majority of SIDs I attempted to disable were not enabled anyway.

********************************************************
Starting auto RULE CATEGORY management for LAN
Start Time: 2021-10-16 09:13:37
Processing disable_sid list: disable-sid-custom.conf
    Parsed 0 potential Rule Categories to match from the list of tokens.
    Disabled 0 matching Rule Categories.
End Time: 2021-10-16 09:13:37
********************************************************

********************************************************
Starting auto SID management for LAN
Start Time: 2021-10-16 09:13:37
Processing disable_sid list: disable-sid-custom.conf
    Parsed 27 potential SIDs to match from the provided list of tokens.
    Found 3 matching SIDs in the active rules.
    Changed state for 3 SIDs to 'disabled'.
End Time: 2021-10-16 09:13:37
********************************************************

Does suricata parse all SIDs at startup, log any anomalies, and only then apply any enable/disable rules?

bmeeks

Two things could be in play here.

First I will answer your last question -- "no, Suricata (and Snort) are only fed the final set of rules you have enabled after all SID management and user-forced options have been processed."

The two reasons you might still see disabled SIDs getting loaded are: (1) some SIDs got pulled in by the automatic flowbit resolution logic; or (2) the SID state order processing drop-down selector is not set correctly for what you are trying to achieve.

Rules pulled in via flowbit resolution will have the "no-alert" tag added, so those rules will load and fire when necessary, but won't alert. But since they are pulled in, they will be parsed during startup. Do some Google research on flowbits for Snort and Suricata to learn more about them if you are not familiar with them. Flowbits are critical components of the IDS/IPS processing chain.

The SID State Order drop-down on the SID MGMT tab determines what order any enablesid.conf and disablesid.conf files are processed. That setting literally determines which file is processed first (the enablesid.conf or the disablesid.conf). Which rules wind up enabled or disabled can be controlled by the last file executed when both files match the same SIDs. So remember that when doing some things by category name and other things by GID:SID.

Finally, those errors you see are simply Suricata saying it can't load those rules, so other than a bit of log spam, the errors are harmless. They have no impact on Suricata's operation.

My best guess is that auto-flowbits resolution is "enabling" those rules for you because other enabled rules are testing some flowbits set by those rules.

The processing logic works like this:

Load rules categories enabled by the user from the CATEGORIES tab.
Process options from the SID MGMT tab files. This might enable or disable additional rules by either category or GID:SID value.
Process any flowbits requirements (this may add additional rules not selected by the user directly, but required by rules the user did select because of tested flowbits).
Lastly, process any user-forced enable or disable options for specific GID:SID pairs.

So if you truly want a specific GID:SID to never, ever be loaded, then you need to user-force disable that specific rule either on the RULES tab (by loading the corresponding category and then finding and clicking the State icon to choose user-disabled); or on the ALERTS tab by finding the GID:SID and clicking the icon to user-forced disable the rule.

darcey

@bmeeks Thanks alot. I'm sure you have covered this before, but that has helped me considerably.

I understand the log errors are not necessarily fatal. But I chose to use those rules mentioned in the suricata.log file as a starting point to try out sid management. I've taken your advice and trying to read up on suricata flowbits, though I'm some way off understanding its implications for overriding a disabled SID.

So, in my example SID management runs, finds 27 candidates to disable (this corresponds to the number of SIDs I list in my disable-sid.conf.
Of those, it says 3 are 'active' and changes their state to 'disabled'.
However, the resulting rules file (/usr/local/etc/suricata/suricata_40334_vtnet2/rules/suricata.rules), though updated, remains unchanged compared to when SID management is disabled.
I was expecting at least 3 rules to be absent from the newly generated file.
Under SID Management, for the interface in question I have it set like this:
Screenshot at 2021-10-17 08-54-33.png

bmeeks

Are you positive these rules are not user-forced from some previous actions?

Post the full content of your disable-sid-custom.conf file here, and I will attempt to reproduce your issue.

Also go to the RULES tab and select "User Forced Enabled Rules" in the Category drop-down box. See if anything is listed then on the RULES tab. This will double-check that those SIDs are not listed in the user-forced section.

darcey

@bmeeks said in Suricata disablesid.conf and expected suricata log output:

Are you positive these rules are not user-forced from some previous actions?

I thought so. However I rechecked "User Forced Enabled Rules" and there were some listed there.
I apologise for not double checking. I knew I had forced disabled some of the STREAM rules, but wasn't aware of the enabled's. I'd restored pfsense from backup after playing around and thought I had a clean(ish) starting point :-/

So, removing those force enabled rules eliminated many of the errors I saw in the suricata.log at startup, and the remainder I 've now successfully disabled via SID MGMNT.

Thanks for your help. I now have a better understanding and the confidence to mess it up further!

bmeeks

@darcey said in Suricata disablesid.conf and expected suricata log output:

@bmeeks said in Suricata disablesid.conf and expected suricata log output:

Are you positive these rules are not user-forced from some previous actions?

I thought so. However I rechecked "User Forced Enabled Rules" and there were some listed there.
I apologise for not double checking. I knew I had forced disabled some of the STREAM rules, but wasn't aware of the enabled's. I'd restored pfsense from backup after playing around and thought I had a clean(ish) starting point :-/

So, removing those force enabled rules eliminated many of the errors I saw in the suricata.log at startup, and the remainder I 've now successfully disabled via SID MGMNT.

Thanks for your help. I now have a better understanding and the confidence to mess it up further!

Glad you got it sorted out .