[Snort-devel] RFC Snort Rules Unique Identifier

James Hoagland hoagland at ...60...
Tue Apr 17 15:55:34 EDT 2001


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).

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

>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. :)

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




More information about the Snort-devel mailing list