Re: threshold deprecation and event_filter

[Eoin Miller <eoin.miller () trojanedbinaries com>]

On 1/11/2012 5:14 PM, Steven Sturges wrote:
> Hi Eoin--
>
> The main issue stems from the fact that using threshold within rules
> wasn't working the way the rule writers were thinking it did.  Hence
> the distinction now between the two different types of filters.  To
> spell it out so everyone has the context:
>
> -- detection_filter
>    This is part of evaluating a rule and the rate therein is required
>    for the rule to match and the action taken (alert, drop, etc).
>
> -- event_filter
>    This is done after the rule matches and the rule action action is
>    taken.  It is basically suppressing output.
>
> When we did this, we went with the philosophy that the guts of the rule
> should be limited to how the rule is detecting things -- not how to
> handle the output.
>
> If output suppression is included in a rule, a rule writer can
> effectively dictate to a user how and when alerts for that rule is
> output.  That isn't the best for everyone, especially those who don't
> write their own rules.

This I don't agree with. The fact that there are src/dst ip/port,
content and all the other options that make up a rule allow the rule
writer to dictate to a user how and when alerts are generated. Why is
threshold somehow different in this respect?

Threshold is used quite frequently by rule writers to limit extremely
chatty rules that would otherwise probably just be disabled by the end
user right off the bat due to the frequency of the alerting output. You
see an out of date Java client making HTTP requests on your network,
probably only want to record 1 of those alerts per hour to let you know
about the box being out of patch for POLICY reasons. Anything more than
that is just a massive amount of alerting data that is not going to be
helpful to the person running the rule. Without the ability to control
this a single host goes from 24 alerts a day to over 5,000 a day easy in
real world scenarios.

The end user doesn't need to be told they are out of patch 5,000 times a
day, they got it the first 24 times. Nor should the end user have to
tweak and tune all the rules that use this functionality, that is just
overhead that has already been handled by the community that has been
running and tweaking the rules.

> We also wanted to make sure that existing rules were updated to use the
> correct keywords and eliminate the situation of rules that weren't
> operating as expected.  There should have been warnings provided at
> Snort's initialization that the in-rule threshold keyword was going to
> be deprecated since the split.

There is a warning during startup, but the warning only occurs on the
first rule in the list you are loading that contains the threshold
keyword. All subsequent rules do not produce a warning.

> In the end, this gives an overall better solution with the combination
> of the Snort updates, correctly operating rules, and customizable
> output suppression.
>
> -steve

I don't get the overriding need to remove the functionality offered by
deprecated threshold within a rule and replace it with event_filter
being only accessible through a conf file. This then requires rule
management software and rule writers/project owners to create separate
supplemental configuration files that must also be included/updated
every time there is a rule update.

It would seem to be much easier (from a rule writer and end user
perspective) if rules were still able to access and control the
functionality of event_filter and detection_filter from within the rule
as they are with the deprecated threshold. If Snort could read and parse
detection_filter and event_filter from within the rules and load them
during startup, that would not require the extra configuration
management overhead.

-- Eoin


------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!