Enabling etpro-exploit.rules causes rules in other non-active categories to become enabled in Suricata...
-
I was having trouble with block rules triggering for categories I didn't have chosen and finally narrowed it down to etpro-exploit.rules.
If I enable that category, rules from etpro-info.rules and etpro-policy.rules become active. Any idea what could be going wrong there?
I double checked some of the SIDs to see if maybe they exist in multiple rule files, but they don't.
-
@tantamount said in Enabling etpro-exploit.rules causes rules in other non-active categories to become enabled in Suricata...:
I was having trouble with block rules triggering for categories I didn't have chosen and finally narrowed it down to etpro-exploit.rules.
If I enable that category, rules from etpro-info.rules and etpro-policy.rules become active. Any idea what could be going wrong there?
I double checked some of the SIDs to see if maybe they exist in multiple rule files, but they don't.
You are likely seeing the results of automatic flowbit resolution. Flowbits are used in Snort and Suricata to maintain "state" across a series of packets for a given flow. Google "flowbits in Snort" to find some tutorials. The short explanation is that flowbits are types of bit flags that one rule can set and other rules triggering on the same flow can read. Here is my favorite example of how flowbits are used.
Suppose I write a rule that is looking for a particular bit pattern in a PDF. That bit pattern in a PDF means the file contains a malicious payload. However, that same bit pattern in say a GIF file is harmless. So how can I keep my rule from "false positive" triggering on the harmless GIF content but still trigger on the malicious PDF content? I need a rule to set a bit flag whenever the IDS/IPS engine sees certain file types at the beginning of a flow. Then my other rule looking for the malicous content can read the bit flag before alerting on a packet to see if a PDF transfer is happening within the current flow. So you will find these "file type" rules in the Snort and ET collections and these rules will have the operators "set", "unset" or "toggle" followed by a flowbit name. The dependent rule that looks at flowbit tags will have the operators "isset" or isnotset".
If the required flowbit setting rule is not enabled, then the dependent rules that read that flowbit can't work. Why is this? Well, that hypothetical rule scanning the packets in a flow for the malicious payload would first check the flowbit flag that says "PDF download detected". If that flag is not set, then the rule looking for the malicious content won't fire. So no protection for you from that malicious PDF file. However, if the rule that sets the "PDF download in progress" flag is present and fires, then the subsequent rule that detects the malicious PDF payload can work properly. Hence the auto-flowbit resolution feature that enables rules needed for flowbits to work. That logic walks through all of your enabled rules and looks for those rules containing the "isset" or "isnotset" flowbit operators followed by a flowbit name. The logic then makes sure that at least one rule containing a "set", "unset" or "toggle" flowbit operator with the same flowbit name is enabled. It will auto-enable rules as required to achieve this. If you absolutely don't want alerts from certain flowbit rules, I recommend you suppress those alerts and not disable the rule. If you disable the flowbit rule you can shoot yourself in the foot as without the "flowbit set" rule being active any rules that check for that flowbit before triggering won't ever trigger.
Auto-enabled flowbit rules are almost never a problem in the Snort Subscriber Rules set because pretty much every Snort rule that contains a "set", "unset" or "toggle" flowbit action also includes the operator "noalert". So this lets that rule toggle a flowbit flag without generating an alert. For some reason unknown to me, the Emerging Threats rules that set, unset or toggle flowbits almost alway lack the "noalert" operator. So those rules will toggle the flowbit flag but also still generate alerts. This is likely what you are seeing. In your specific case, I suggest using the "add to suppress list" option on the ALERTS tab to suppress the alerts from those auto-enabled flowbits rules (the ones you say are coming from categories you have not explicitly enabled).
-
If this is in reference to SID 2018959 that we were discussing the other day, then you might want to view the comments here:
https://doc.emergingthreats.net/bin/view/Main/2018959 the commenter has a theory.
That rule also sets a flowbit, so if an enabled rule is using ET.http.binary, Bill's explanation seems more likely.
cat suricata.rules | grep "isset,ET.http.binary" | sed -n -re 's/.*(ET [^ ]*) .*(sid:[[:digit:]]+);.*/\2 - \1/p'gives:
sid:2018103 - ET CURRENT_EVENTS sid:2018104 - ET CURRENT_EVENTS sid:2025195 - ET EXPLOIT sid:2025196 - ET EXPLOIT sid:2015744 - ET INFO sid:2015745 - ET INFO sid:2015965 - ET INFO sid:2018087 - ET INFO sid:2018748 - ET TROJAN sid:2023741 - ET TROJAN sid:2019421 - ET WEB_CLIENTSo it looks like rules in eg emerging-exploit might require this rule?
-
Yes, @boobletins is correct. That "isset,ET.http.binary" is a test for a flowbit variable named "ET.http.binary". You can generally tell from the flowbit's name what it is used for. In this case it is a safe bet this flowbit is a flag that indicates the current flow represents a binary download over HTTP is in progress.
So this operator, "isset", tests a condition that must evaluate to "true" in order for the rule to fire. That means that if the flowbit named is not present and is not "set", then the rule will not fire even if the packet's data matches every other parameter in the rule's signature.
So how does this flowbit get set then? There will be another rule that is watching the payload in the packets to see if the beginning of the flow has the hallmarks of a binary transfer over HTTP. So any time this watcher rule sees a flow that is starting a binary download over HTTP, it will create a flowbit named "ET.http.binary" and set that flowbit to "true". Other rules may then look for this flowbit when testing if all the conditions are necessary for them to trigger.
If you had disabled the rule that sets that flowbit, or worse, had not even enabled the category containing that rule, then the rule that checks that flowbit as a condition for firing would never fire. So you would lose the protection afforded by that rule even though you actually had it enabled. It just won't fire if that flowbit never gets set.
This is why you should never disable rules listed in the Auto-flowbits category on the RULES tab drop-down. It's also why you should always enable the option to auto-resolve flowbits. As I explained in an earlier post, the auto-resolve logic will find the rules that "set" any tested flowbits and enable those rules to be sure the flowbit is actually created when needed. I also pointed out in that earlier post that the Snort team puts the "noalert" operator in all of their rules that "set" flowbits. This way you don't get an alert just because a bit flag was set. The Emerging Threats rules lack this finesse for some reason.
-
To confirm this could he check flowbit-required.rules?
Do you know what happens in the case of rules like 2018959 where the same flowbit is both tested and set?
flowbits:isnotset,ET.http.binary; --- then later --- flowbits:set,ET.http.binary;
Is pulled pork (or whatever is being used) smart enough to know that if 2018959 is disabled and not used elsewhere it should stay that way?
-
@boobletins said in Enabling etpro-exploit.rules causes rules in other non-active categories to become enabled in Suricata...:
To confirm this could he check flowbit-required.rules?
Do you know what happens in the case of rules like 2018959 where the same flowbit is both tested and set?
flowbits:isnotset,ET.http.binary; --- then later --- flowbits:set,ET.http.binary;
Is pulled pork (or whatever is being used) smart enough to know that if 2018959 is disabled and not used elsewhere it should stay that way?
I have not looked at the full text of the rule you mention, but a rule author might use logic like that as a type of "if-then" statement. If not set, then set it; otherwise let it be. Use of flowbits is a totally arbitrary thing for rule authors. You can create as many as you like with whatever names you want, just so long as you don't duplicate the names.
Pulled Pork is not being used in the Snort or Suricata packages, but the code logic is the same. It will enable rules as necessary to be sure at least one "set" operator exists for any flowbit with a corresponding "isset" operator. Now, if an admin truly wants a rule to always be disabled, flowbits be damned, then when you force a rule state to disabled on the RULES tab (or by clicking the X icon on the ALERTS tab), then that rule is disabled. The user-forced actions are the last operations performed on the set of rules when compiling the list for an interface.
There is a Sticky Post here on the IDS/IPS sub-forum about how that works. You can also follow the program code in the file /usr/local/pkg/suricata/suricata.inc. Look for the function suricata_prepare_rule_files().
Edit: here is the Sticky Post I mentioned describing the rules building logic.
