Snort alerting on deselected category
-
2.9.4.6 pkg v. 2.6.0
Today Snort alerted and blocked on a "ET POLICY Vulnerable Java Version 1.7.x Detected" rule. This would be a valid hit if I had the ET POLICY category selected, but I don't.
I had selected ET POLICY at one point, to see what the actual rules were. However, it has been deselected for a long time and there have been numerous Snort service restarts since.
So, the question is … Why is Snort still alerting on categories that have been selected, then deselected, and Snort service restarted?
Here are some screen shots. Please let me know if there is anything else I can provide.
 -
2.9.4.6 pkg v. 2.6.0
Today Snort alerted and blocked on a "ET POLICY Vulnerable Java Version 1.7.x Detected" rule. This would be a valid hit if I had the ET POLICY category selected, but I don't.
I had selected ET POLICY at one point, to see what the actual rules were. However, it has been deselected for a long time and there have been numerous Snort service restarts since.
So, the question is … Why is Snort still alerting on categories that have been selected, then deselected, and Snort service restarted?
Here are some screen shots. Please let me know if there is anything else I can provide.
That obviously should not be happening. First up, try clicking the SAVE button on the Categories tab for the affected interface. Then stop and start Snort. Also make sure that this rule is not "forced enabled". If you do not want any "forced enabled" rules, then on the Rules tab click the X icon labeled "Remove all Enable/Disable changes in all Categories".
If that doesn't do the trick, post back and we can try some other steps.
Bill
-
I can confirm this. I see the exact same behavior. ET Policy is not enabled, but I'm getting those Java policy alerts. I did have ET Policy enabled previously.
-
I tried a couple of different ways to clear this …
Method 1:
- Clicked the SAVE button on the Categories tab for the affected interface.
- Stop and start Snort.
Still alerting.
Method 2:
- Enabled the offending ET POLICY Category; saved; stop/start Snort
- Disabled the offending ET POLICY Category; saved; stop/start Snort
Still Alerting.
Method 3:
- Enabled the offending ET POLICY Category; saved; stop/start Snort
- Disabled only the "ET POLICY Vulnerable Java Version 1.7.x Detected" rule that was being triggered.
- Disabled the offending ET POLICY Category; saved; stop/start Snort
No longer alerting.
–--
When I enabled the ET POLICY Category, there was a flood of other alerts (Dropbox, etc.). So, the entire category was not misbehaving. Appears to be just this one rule.
I'm not sure how to determine if one specific rule is "forced enabled".
If there is anything you would like me to try, in order to understand this further, I can reproduce it. If not, I'll just go ahead and upgrade java!!! :D
Thanks, Bill.
-
After I thought about this some more, it occurred to me what is likely going on. The auto-flowbit resolution logic (assuming you have it enabled; which is the default) will enable rules required to set flowbits that are checked by any of your enabled rules. So my guess is one of your selected rules checks a flowbit related to Java. The corresponding "set flowbit" rules have to be enabled and included in the enforcing rules in order for the flowbit checking rule to fire.
By you going in and manually disabling that one particular rule (force disabled), then the flowbit logic will not reactivate it even if other flowbit checking rules are dependent on it. The flowbit logic honors manually disabled rules and does not automatically reactivate them.
Here's what you can do to validate my theory. Turn the rule back on in the original file. Then save the changes to generate a fresh set of enforcing rules and flowbit rules. Now go to the CATEGORIES tab and click the button to view Flowbit Rules. I bet you will find the offending rule in the list someplace. You can click the column headers to sort on that field. Sorting by SID will make it easier to find. There will be a plus (+) icon beside the SID. Click that icon to automatically add a Suppress List entry for that rule. This way the rule will still fire to set the flowbit, but it will not alert in the logs. Suppressing undesired flowbit rule alerts is the preferred way of doing things, because those rules still need to function and set their corresponding flowbits or else other rules that come along and check for those set flowbits won't trigger properly. If flowbits are a mystery to you (and they were to me initially), you can Google the phrase "snort flowbits" and find some links to great explanations of what they are all about. The Snort VRT folks are really good about adding the keyword "noalert" to all of their "set flowbit" rules. This lets the rule set the flowbit without generating an alert. The Emerging Threats rules, on the other hand, seem to only randomly include the "noalert" keyword.
Bill
-
Here's what you can do to validate my theory. Turn the rule back on in the original file. Then save the changes to generate a fresh set of enforcing rules and flowbit rules. Now go to the CATEGORIES tab and click the button to view Flowbit Rules. I bet you will find the offending rule in the list someplace.
Theory is correct! :)
I ran through it a couple of times. It wasn't until after the second cup of coffee that I realized that a rule will only appear in Auto Flowbit Rules if the entire category is not enabled. Hence the auto enable part … duh!
The ET java version rules do not have the 'noalert' keyword. The fact that a rule the user did not explicitly enable themselves would fire and generate a blocking action was not expected.
Feature Enhancement Suggestion: Instead of having the Auto [enable] Flowbit Rules listed via a button under 'Categories' tab, would it be possible to have them listed on the 'Rules' tab via another selection in the drop-down under Available Rule Categories. In the current interface, the user is able to view all the enabled rules in one place, except the auto-enabled ones.
Thanks
-
Feature Enhancement Suggestion: Instead of having the Auto [enable] Flowbit Rules listed via a button under 'Categories' tab, would it be possible to have them listed on the 'Rules' tab via another selection in the drop-down under Available Rule Categories. In the current interface, the user is able to view all the enabled rules in one place, except the auto-enabled ones.
Thanks
That's a good idea. Off the top of my head I see no issues with doing this. I think the View button should remain as well, but adding the list of auto-flowbit rules as a selection in the dropdown is a good suggestion. Look for it in the next big 3.0 update I hope to have ready in November.
Bill
-
One important point to remember, though – you should generally not disable any auto-flowbit rules. You should instead add them to the Suppress List if you want to prevent alerts and possible blocks triggered by them.
The auto-flowbit rules serve an important function in keeeping your other enabled rules working as expected. With critical auto-flowbit rules disabled, some of your enabled rules might never fire.
So the correct place to handle unwanted flowbit rule alerts is via that View button on the CATEGORIES tab that takes you to the page where you can auto-add Suppress Entries for those flowbit rules that do not already have the "noalerts" option specified by the rule author.
Bill
-
Feature Enhancement Suggestion: Instead of having the Auto [enable] Flowbit Rules listed via a button under 'Categories' tab, would it be possible to have them listed on the 'Rules' tab via another selection in the drop-down under Available Rule Categories. In the current interface, the user is able to view all the enabled rules in one place, except the auto-enabled ones.
Thanks
That's a good idea. Off the top of my head I see no issues with doing this. I think the View button should remain as well, but adding the list of auto-flowbit rules as a selection in the dropdown is a good suggestion. Look for it in the next big 3.0 update I hope to have ready in November.
Bill
This actually turned out to be much easier to implement than I thought. I had some time, so I added it to the current Pull Request for the 2.6.1 update that is awaiting approval. So when the current Snort package v2.6.1 update is approved and merged, this feature will be a part of it.
Bill
-
Wow … Thanks much!
