[Snort-devel] RFC Snort Rules Unique Identifier

Jed Haile hailjt at ...189...
Tue Apr 17 23:12:56 EDT 2001


Thanks Jim,


> Hello Jed and all,
>
> ><soapbox>
> >A severe limitation in any large scale deployment of Snort is the lack of
a
> >mechanism of uniquely identifying each rule in the rules database.  As
rules
> >[snip]
> ></soapbox>
>
> Agreed.
>
> >Now that I'm off my soapbox I would like to propose the following:
> >CHANGES TO RULES LANGUAGE:
> >Add two new required fields to each rule:  UID and REV.  The UID being
the
> >unique id and the REV being the revision of that particular rule. I
envision
> >the UID and REV to each be a nonnegative integer. So a snort rule would
look
> >like:
> >  alert tcp $HOME -> $EXTERNAL (msg:"Some silly rule"; UID:212; REV:2;
> >content:"whatever";)
>
> I'm hesitant about making these mandatory.  It might not suit
> everyone's taste and it breaks backward compatability (i.e., old rule
> sets will no longer work).    I also think UID and REV should be
> lower case (leave the all caps for variable names and avoid shouting).
>

That would be the unix way... CAPS were mostly for emphasis. I was thinking
about mandatory, because the problem isn't really fixed if everybody doesn't
play along.

> >I am suggesting a REV field so that a modified rule need not be given a
new
> >UID but rather have its REV incremented.
>
> Sounds good.
>
> >CHANGES TO ALERT FORMAT:
> >The revised snort alert would look like
> >[**] UID: #### REV: ####  Message [**]  blah blah blah...
> >I suggest putting the UID and REV into the message block as it would be
least
> >likely to break everybody's homegrown alert parsers.  It also provides a
> >convienient way to write a regexp to parse by UID if desired.
>
> I think that this is too verbose for the start of the alert.  How
> about one of these:
>
> 1) [**] ##.## Message [**]  blah blah blah...   (first ## is the uid
> and the second ## is the revision)
> 2) [**] ##:## Message [**]  blah blah blah...
> 3) [**] Message (##.##) [**]  blah blah blah...
> 4) [**] Message (rule ##:##) [**]  blah blah blah...
> 5) Leave the message alone and add the following to the bottom of the
> full alert message "[Rule uid: ##, revision: ##]".  Maybe the fast
> alert and syslog format would use one of the above; not sure.  Those
> formats leave out alot of information anyways, e.g. protocol (TCP vs.
> UDP).
>
> Which do people prefer?  I think I'd be happy with any of those.
>
> I think SnortSnarf would be able to handle any of those without
> modification until it decides to take advantage of that information.
> It only looks at the first 4 lines of full alert formatted messages
> and treats the message as an arbitrary string.
>

I had considered option #1 previously:
 [**] ##.## Message [**]  blah blah blah...
This would work well for my situation and it does cut down on the verbosity.
I also like the idea of leaving fast alerts and syslogs alone and putting
[Rule uid: ##, revision: ##] into the full alert, although it might be
somewhat more troublesome to parse and it is needlessly verbose.

> >OTHER THOUGHTS:
> >This would make support much easier for the folks on the mailing list,
for
> >Silicone Defense's commercial support efforts, etc. If a user is having
> >trouble with a rule it could be precisely identified by its UID and REV.
It
> >becomes much easier to do automatic rules updating. It becomes easy to
see how
> >a rule has evolved over time by tracking its REV number. It will make the
> >entire snort rules process seem much more sane and accountable to the
outside
> >observer who is unfamiliar with the open source way. It will make real
> >configuration management much more simple. And it will help me solve a
problem
> >that has been driving me crazy. ;-)
>
> Agreed it might make support easier.
>
> BTW, _Silicon_ Defense is the company doing Snort Support.
> _Silicone_ Defense is our sister company that has carved out a
> pleasant niche in the bodyguard business. :)
>

DOH!  That must be my favorite typo.  Wonder where my mind is?

> Just my 2c.
>
> Kind regards from sunny Davis California,
>
>    Jim
> --
> |*   Jim Hoagland, Associate Researcher, Silicon Defense    *|
> |*               hoagland at ...60...                *|
> |*              http://www.silicondefense.com/              *|
> |*      Silicon Defense - Technical Support for Snort       *|
> |*  Voice: (530) 756-7317              Fax: (530) 756-7297  *|
>
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/snort-devel





More information about the Snort-devel mailing list