Re: Using detection_filter instead of threshold

[Jason Brvenik <jasonb () sourcefire com>]

/me talking

On Wed, Oct 27, 2010 at 4:50 PM, Matthew Jonkman
<jonkman () emergingthreatspro com> wrote:
> Comments below still apply, but I misread that threshold was going to be disallowed in a rule in the next release, 
> whereas it actually says event_filter will be disallowed. My Bad.
>
> But still, if this is open software, I suspect the majority of users want to keep thresholding within a rule. Having 
> the option to do it in both places I think is good. Because we distribute a lot of rules that need a threshold built 
> in. Doing that in a separate file is difficult, because as mentioned, no one wants to have to look at a separate file 
> for EVERY rule they look at to see if it's listed there by sid. It's just a huge opportunity to introduce human error 
> in the analysis process.

I see it as more of an opportunity for human error when it is in the
rule. Thresholds need to be twiddled and twiddling often results in
mistakes. No point in exposing the rule to twiddling and the resulting
mistakes just because there is a threshold.

Regarding separate files, you don't have to have it in a separate
file, you could include it right below a rule in the rule file itself,
snort cares not. Separating it allows you to manage the thresholds
without mucking about with the rules files themselves or colliding
different configuration trees but what ever floats your boat will work
just fine.

IMHO and in a perfect world, because of the twiddle factor, anything
not strictly related to detecting the exploitation of the
vulnerability _should_ be removed from the rule entirely.

> Can we see where this is going on the dev roadmap? When will threshold go away? How can we keep it? Can we get 
> event_filter and such allowed within the rule itself if threshold is going away?
>
> And why'd we change anyway?
>
> Matt
>
> On Oct 27, 2010, at 2:03 PM, Matthew Jonkman wrote:
>
> > Is this 2.9.0?
> >
> > I also vote to keep it in the rule. It's a major pain in the ass to have to look at your threshold.conf EVERY time 
> > you look at a rule, or you'll not know why you only got x number of hits. Or you'll not know that the events 
> > continue but are being suppressed.

If you look at the problem it is really because of busted analysis
tools. I vote to disallow it, it is a major fail to think something is
working properly at detecting what you intended only to later discover
someone screwed up the content in the last threshold modification.
The tools need to be updated to be aware of these and the multitude of
other useful capabilities so that the users and analysts don't _have_
to look it up; they shouldn't _have_ to be savants to remember every
little detail.

It should be presented to them cleanly and in an understandable
manner, not retrieved so they can understand what happened.

> > I don't recall any community input saying we wanted it changed... nor any sound reasoning why it should change. Did 
> > I miss those discussions and conversation? This is open software after all. No?

The beauty of open software is that the community is free to do these
things and any other things any time they desire to. It is open, feel
free to patch it up, redistribute under the GPL, etc. I'm sure that a
patch allowing it in the rule wouldn't be that difficult to produce if
your operational needs are such.

> > Matt
> >
> >
> > On Oct 27, 2010, at 1:13 PM, Eric L. Howard wrote:
> >
> > > On Wed, Oct 27, 2010 at 12:47 PM, L0rd Ch0de1m0rt
> > > <l0rdch0de1m0rt () gmail com> wrote:
> > > > Thanks.  Is there any way to do it in the rule itself like back in the
> > > > salad days?
> > >
> > > Nope.
> > >
> > > DEPRECATED ITEMS
> > > ================
> > >
> > > * detection_filter replaces the existing in-rule threshold, which is now
> > > obsolete.  Furthermore, the existing threshold when used within a rule was
> > > not part of the detection process; it was equivalent to a standalone
> > > threshold.  To retain the functionality of existing in-rule thresholds,
> > > reformat them as standalone event_filters (see below).
> > >
> > > * event_filter replaces the existing standalone threshold, which is now
> > > deprecated.  Furthermore, even though event_filter is an alias for threshold,
> > > which is allowed to appear in a rule (although that use is now also
> > > deprecated), event_filter will not be allowed in a rule.  Such use will
> > > result in a fatal error during initialization.
> > >
> > > ~elh
> > >
> > > ------------------------------------------------------------------------------
> > > Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> > > Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> > > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> > > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> > > http://p.sf.net/sfu/nokia-dev2dev
> > > _______________________________________________
> > > Snort-sigs mailing list
> > > Snort-sigs () lists sourceforge net
> > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >
> >
> > ----------------------------------------------------
> > Matthew Jonkman
> > Emergingthreats.net
> > Emerging Threats Pro
> > Open Information Security Foundation (OISF)
> > Phone 765-807-8630
> > Fax 312-264-0205
> > http://www.emergingthreatspro.com
> > http://www.openinfosecfoundation.org
> > ----------------------------------------------------
> >
> > PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
> ----------------------------------------------------
> Matthew Jonkman
> Emergingthreats.net
> Emerging Threats Pro
> Open Information Security Foundation (OISF)
> Phone 765-807-8630
> Fax 312-264-0205
> http://www.emergingthreatspro.com
> http://www.openinfosecfoundation.org
> ----------------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs



-- 
Regards,

Jason.

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs