Re: Using detection_filter instead of threshold

[Jason Brvenik <jasonb () sourcefire com>]

No, I was referring to adding the new stuff to the rules if your operational
needs dictate, threshold already exists as it did before.
On Oct 27, 2010 8:12 PM, "infosec posts" <infosec.posts () gmail com> wrote:
> > 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.
>
> This is interesting and potentially helpful (although undocumented as
> far as I can tell). I think it's going to mess with my current
> management tools and scripts to have non-commented lines that aren't
> rules in my rules files, though, so I'm probably left tweaking my
> tools and processes to manage and deploy a new configuration file
> across my sensors.
>
> I guess I can understand the purpose and intent behind event_filter,
> but I'm not clear on "why" for the forced removal of in-rule
> thresholds. It doesn't seem reasonable to me to force people into new
> features/configurations just because they're there, and then say,
> "write a patch to fix it yourself" in response to constructive
> criticism. I'm not a software dev, though; just a guy who now has
> some extra work to do on his rulesets because of this decision.
>
>
>
> On Wed, Oct 27, 2010 at 5:39 PM, Jason Brvenik <jasonb () sourcefire com>
wrote:
> > /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
------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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