Support #3102
closedRule sid: 2019401 does not get disabled
Description
I was testing disabling some rules and no matter what I do, it refuses to comment it out. In fact, if I have it commented on the rule file it parses from, it still uncomments it. Coincidentally, this is rule # 2019401 which is mentioned in the comments of the enable/disable/drop/modify .conf files.
Other sid:'s work perfectly fine except for this one. I grep'ed through the .conf files as a sanity check to make sure it wasn't mentioned anywhere else, but all instances of 2019401 are commented out except for the entry in disable.conf.
Is it possible it is hard coded somewhere or I'm just overlooking it somewhere?
Updated by Jason Ish over 4 years ago
This was probably a bad rule to use as an example. You'll see in that rule:
flowbits:set,ET.http.javaclient.vulnerable
So any rule that checks this flowbit will cause it to get re-enabled again to meet flowbit dependencies.
Updated by Victor Julien over 4 years ago
- Target version changed from 1.0.5 to TBD
Updated by Kenneth Kolano over 4 years ago
It's very unclear what's happening for a user when the flowbit re-enables manually disabled rules. This is also a problem for 1:2018959.
To disable these rules one apparently must purge the flowbits clause from the rules in addition to disabling them...
modify.conf
1:2018959 "flowbits:.*?;" ""
disable.conf
1:2018959
Updated by Jason Ish over 4 years ago
I have thought about adding a syntax to force a rule to be disabled, and never be re-enabled, but it could lead to users doing this, then never having an important rule trigger.
The next version of suricata-update will add "noalert" to rules enabled as part of meeting flowbit dependencies. So they will set their bits, but never alert. Does that resolve this issue?
The other option, supported today is to add these sids to your supressions configuration file.
Updated by Shivani Bhardwaj over 4 years ago
Hi John!
Did Jason's comment help you? Are we good to close this issue?
Updated by Shivani Bhardwaj about 4 years ago
- Status changed from New to Closed
Closing due to inactivity. Please feel free to open the issue again in case you see it. Thank you.
Updated by Kenneth Kolano about 4 years ago
This has come up again in #3511 3511