Re: threshold -- is it really deprecated?

[Russ Combs <rcombs () sourcefire com>]

On Sat, Jan 21, 2012 at 1:52 AM, Joshua Kinard <kumba () gentoo org> wrote:

> 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.
>
> Sure.

> > 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.
>
> Ah, thanks for pointing that out.  I will correct the manual.
detection_filters are evaluated as the last rule option.  In other words,
if the rule would fire w/o a detection_filter, only then is the
detection_filter evaluated.  It is therefore most definitely part of
detection, and distinct from the other options in the post-detection
section.  They operate on rules that have fired whereas detection_filter
determines whether a rule will fire or not.

> > 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.

detection_filter is in the rule because it is part of detection but
event_filter is not.

I say it is a tool chain issue because if event_filters were downloaded
along with rules, we probably wouldn't be having this discussion.  And it
is definitely not a Snort issue because you get the exact same
functionality when you run Snort.


> 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.
>
> That isn't what happened here.  Thresholds were moved out of the rule to
avoid confusion.  And detection_filters and rate_filters are (were then)
new functionality.


> 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.
>
> I can only give you my viewpoint as a Snort developer.  I think VRT needs
to weigh in at this point.  My understanding is that they are experiencing
the same pain wrt thresholds/event_filters.

> --
> 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
------------------------------------------------------------------------------
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!