Home page logo
/

snort logo Snort mailing list archives

Re: Using detection_filter instead of threshold
From: Jason Brvenik <jasonb () sourcefire com>
Date: Wed, 27 Oct 2010 21:27:08 -0400

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]