Re: [Snort-users] threshold -- is it really deprecated?

[Martin Roesch <roesch () sourcefire com>]

Personally I'd prefer to see the rule structure revisited.  The current
melange of selectors, detection and metadata information in a rule that
depends on the author for structure is pretty suboptimal (and entirely my
fault, lack of foresight you know).

Something like

rule {
    metadata { msg, sid/rev, ... }
    selector { flowbits, protocol, ip range, ... }
    detect { content, regex, ... }
    action { alert, log, block, set flowbit, ... }
}

would be great.  If we did that and built in a nice macro system then it'd
be easy to setup easily tweaked external configuration options for outcomes
or notifications or whatever.  The pain in the butt is that we've got 13
years of rules built on the old system.  Maybe a new keyword to
differentiate the new layout to the rule parser?  Hm... ngrule anyone?  :)

My $0.02 as the person who originally built it (suboptimally). :)


Marty


On Mon, Jan 23, 2012 at 4:20 PM, Jason Brvenik <jasonb () sourcefire com>wrote:

> On Mon, Jan 23, 2012 at 3:54 PM, Joshua Kinard <kumba () gentoo org> wrote:
> > On 01/23/2012 11:36, Jason Brvenik wrote:
> >
> > > Now that the thread has had expression time I'd like to add my $.02
> > >
> > > I don't believe ANYTHING should be in the rule that is not DIRECTLY
> > > detection related. All information that isn't detection related should
> > > be external to the rule and modifiable without risking changing the
> > > detection content.
> > >
> > > This means that IMHO msg: class: metadata: threshold: etc should all
> > > get externalized. The potential for human error and likelihood of edit
> > > collision should be minimized, not maximized.
> >
> >
> > 'msg' is to provide the human-readable description of the rule.  If that
> > were to be externalized, then how would you link a rule to said external
> > definition?  We all know that SID + GID + Rev is the defacto unique
> > identifier for a rule.  Requiring someone to go and look that
> combination up
> > in a separate file to match it to the message and other non-detection
> > options just adds to the overhead needed to manage a ruleset.
>
> Does it? The way I see it it makes management of the rules set a lot
> easier and lowers the bar of entry. Instead of this arcane file all
> jumbled up and parsed through by perl to parse rules to get some
> semblance if a configuration all I have to edit is a "state" file with
> the gid:sid:rev and state
>
> If I want to turn on 1:234:5 and have it block I just modify rule.state to
> have
>
> "1:234:5 block, alert" #block and notify through an alert
>
> instead of my monolithic and arcane pulled pork configuration
>
> If I want the message for the event to be a bit more relevant to my
> helpdesk I also modify the msg in rule.msg
>
> "1:234:* VIRUS DETECTION - SOME NORMAL MESSAGE"
>
> If I want to take the disable a rule where the default is on I just
> make my rule.state have
> "1:234:* disabled, notify" #override
>
> > IMHO, it's not the *sole* job of software developers to implement
> mechanisms
> > to protect users from their own mistakes.  Some effort should be made so
> > that users get it right most of the time, but at some point, you have to
> let
> > them fend for themselves.  They'll either figure it out or get eaten by
> a grue.
>
> Ease of use drives adoption and I think that we can agree that we all
> want more security driven into networks to help with the larger goal
> of peace and tranquility. It should be the goal of every effort
> (limited by reality of course) that the tools we produce are as easy
> to use as possible without diluting the purpose of them.
>
> > Combine a text-based ruleset with a RCS like git, and you can solve a
> > majority of human-error problems, especially if you have multiple eyes
> > reviewing the ruleset (and the RCS history).
>
> Solving one problem by creating another tool chain dependency, isn't
> that a clear indication of a problem with rules as they stand?
>
> > Better documentation also
> > helps, which is why I've been quite pedantic about the Snort manual in
> the
> > past (like the patch to revise the 'pcre' example I sent in a while ago).
>
> I couldn't agree more.
>
>
> > --
> > 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
>
>
>
> --
> Regards,
>
> Jason.
>
>
> ------------------------------------------------------------------------------
> 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!



-- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Agile Security for the Real World - http://www.sourcefire.com
Snort: Open Source IPS - http://www.snort.org

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