[Snort-devel] RFC Snort Rules Unique Identifier
hailjt at ...189...
Tue Apr 17 23:12:56 EDT 2001
> Hello Jed and all,
> >A severe limitation in any large scale deployment of Snort is the lack of
> >mechanism of uniquely identifying each rule in the rules database. As
> >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
> >unique id and the REV being the revision of that particular rule. I
> >the UID and REV to each be a nonnegative integer. So a snort rule would
> > 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).
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
> >I am suggesting a REV field so that a modified rule need not be given a
> >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
> >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.
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,
> >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.
> >becomes much easier to do automatic rules updating. It becomes easy to
> >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
> >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
> >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 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
More information about the Snort-devel