Home page logo
/

snort logo Snort mailing list archives

Re: Using detection_filter instead of threshold
From: infosec posts <infosec.posts () gmail com>
Date: Wed, 27 Oct 2010 20:06:19 -0500

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


  By Date           By Thread  

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