Rules I don't have enabled are alerting/blocking
-
I recently enabled the ET Malware Ruleset. Immediately after, I noticed a couple of devices get blocked due to an ET Chat rule firing. I verified this rule belongs in that rule set, but I do not have these rules selected or enabled. What am I doing wrong?
-
Need some more details. Specifically, what ET Chat rule fired? I need to know the SID of the rule that triggered and blocked. Snort can't block on a rule that is not enabled. So either you enabled the rule and did not realize it, or it is remotely possible that the automatic flowbits dependency check enabled some other rules. But I would say that is generally unlikely for ET Chat rules.
-
These are some of the ones I see as active rules.
BUT, I do see them in the Auto Flowbit Rules. So they got enabled recently some how. Possibly by enabling the ET Malware? I'm not exactly sure where the Auto Flowbit rules come from.
-
Go do some Google research on flowbits in Snort (and Suricata uses them as well). They are the mechanism that allows a sort of primitive "state engine" to be created by rules so that some additional logic can be applied,
Here is an example I have used in the past to explain what flowbit rules are all about. Suppose there is a given exploit that comes down only in PDF files. Rules would detect the exploit code by doing pattern matching on the content of packets. So when a rule saw the matching content in a packet (or several packets if the exploit payload is large), then it triggers. But a pattern is simply a collection of bits either turned on or turned off. In this example, the pattern is only malicious when it is contained within a PDF file. It would certainly be possible for other types of files to by sheer chance contain the same pattern. One possibility might be a simple GIF image. So how can the rule know what type of file is being downloaded so that it can only trigger when it detects the pattern in a PDF?
This is where flowbits come in. You have flowbit rules that sense different types of activity (PDF file download, Chat session opening, etc.). These rules then set bit flags that other rules can later examine to see what's happening. When you have rules that check certain flowbits before alerting, and those flowbit rules are not enabled, then the "checking rule" will never fire because its flowbit logic check will fail. Consider my earlier example of the PDF file download. If the flowbit that says "PDF download in progress" is not set, then my malicious payload detection rule won't fire because it will check the "PDF download" flowbit before firing. So the idea behind auto-flowbit rules is that the Snort GUI application will determine what flowbit rules are required by the active rules you have selected, and then it will make sure those flowbit rules are activated. Any rules it automatically enabled will be listed in the Auto-Flowbits category on the RULES tab.
The Snort Subscriber Rules always tag their flowbits rules with the "no-alert" keyword so that the rule fires and sets the appropriate flowbit, but it does not generate an actual alert. The Emerging Threats folks for some reason fail to do that. They do not put the "no-alert" keyword in their flowbit rules. Thus their flowbit rules will trigger actual alerts as well. That is why you are getting the block from that ET-Chat rule that is listed in the Auto-Flowbits category. Your best course of action with those ET-Chat rules that got sucked in by the auto-flowbits logic is to suppress them by GID:SID. That will prevent the actual alert and thus the block, but it won't prevent them from setting the appropriate flowbits.
