[Snort-devel] RFC Snort Rules Unique Identifier
hoagland at ...60...
Tue Apr 17 15:55:34 EDT 2001
Hello Jed and all,
>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
>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
> alert tcp $HOME -> $EXTERNAL (msg:"Some silly rule"; UID:212; REV:2;
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.
>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.
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.
>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 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