Re: threshold -- is it really deprecated?

[Joshua Kinard <kumba () gentoo org>]

On 01/20/2012 15:04, Russ Combs wrote:

> On Fri, Jan 20, 2012 at 1:45 PM, Joshua Kinard <kumba () gentoo org> wrote:
>
> > So, regarding the recent thread about the threshold keyword, I have to ask
> > if threshold is really deprecated.  As far as I can recall, it's been
> > marked
> > as such in the Snort manual since Snort-2.8.5.  The suggested replacement
> > is
> > detection_filter, but I don't feel that detection_filter actually replaces
> > threshold's capabilities.
>
> Yes - threshold is really deprecated, by VRT request.  When they get the
> rules updated, it will go.
>
> No - detection filter is not the suggested replacement.  event_filter
> replaces threshold.


Technically, event_filter does not "replace" threshold.  Although both do
the exact same thing, one is done in-rule and the other done out-of-rule,
technically making them two different approaches.  I find that having to
manage the list of filters out of rule to be an additional burden, whereas
within the rule, they are visible and up front.


> Not sure what you mean by "post-detection", but that is not how I think of
> it.  The rule won't fire until the detection_filter constraints are met, so
> I consider that part of detection.


In the Snort manual, detection_filter is listed in the "post-detection"
section, which suggests that its functionality is evaluated _after_ the
detection engine has run its course and events are tabulated for
post-processing (which is also where tag and other actions take place).
That's my use of the term.


> threshold was syntactically part of the rule but never implemented as
> such.  It was always what event_filter is now; there is no loss of
> functionality.  It sounds like what is lost is the ability to import
> event_filters along with rules, which is a tool chain issue, not a Snort
> issue.


Not following this logic somewhat.  A toolchain issue?  I see it as a Snort
issue because threshold, even if it is a shortcut for event_filter, acts as
an output suppressor, while detection_filter only provides output when the
number of events/alerts queued has reached a defined upper-limit in a given
time frame.  I propose that they both serve different purposes, therefore,
complement each other by giving a rule writer various options to control a
rule's output.

Should a rule writer be the one to dictate to the community how a rule
should behave?  Probably not.  I can see instances where receiving the full
brunt of 4,000 alerts a minute might be of value (such as feeding into a
SEIM for data mining or other such odd purposes).  But that needs to be
expressed in documentation or training and it should be up to the rule
writer to consider their target community when writing a rule.  Taking away
functionality because it *might* be abused isn't the correct way to go.

FYI, Eoin pointed me to a similar thread on snort-users on this same topic
from a few days ago.  I was not aware of it as I am only subbed to -devel.

-- 
Joshua Kinard
Gentoo/MIPS
kumba () gentoo org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!