[Snort-devel] RFC Snort Rules Unique Identifier

Jed Haile hailjt at ...378...
Tue Apr 17 11:42:03 EDT 2001


Lots has been going on in refining the rules base, and it has been great.
Especially the priorities stuff.  I still have an itch that needs scratched. It
would be very nice for every snort rule to have a unique identifier and a
revision number, much the same as Solaris and some other systems manage their
patches.  So I have been doing some thinking on how we can hanlde this.  I
submit the following RFC for your consideration.  Once some consensus has been
reached, I will be happy to make the necessary changes and submit the patches.

hailjt at ...189...

Request for comment: Snort Rules Unique Identifier

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
evolve and are added/deleted a great amount of confusion can result over
duplicated rules, added rules, deleted rules, revised rules etc.  It is
troublesome to index a database against the msg portion of snort alerts and it
seriously kills performance.  This is an annoyance when managing a couple of
sensors, but it rapidly becomes critical when managing a large number of
distributed sensors which report to a central database.  Finding and removing
duplicate/obsolete rules is burdensome, automated updating of rules is
unreliable, and good configuration management is impossible.  Snort is in need
of a centrally managed unique identification system for its rules database if
it is to be successfully deployed and managed across a large enterprise. I
realize that the whitehats ID and CVE ID has been added to the rules base, as
well as the priorities and whatnot, but none of these provide a unique one to
one mapping to the snort rules space. 

Now that I'm off my soapbox I would like to propose the following:
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 am suggesting a REV field so that a modified rule need not be given a new
UID but rather have its REV incremented.

Add two new fields to the appropriate table in the snort database for the UID
and  REV. The UID would be easily indexed as it is an integer. I am suggesting
separate fields for the UID and REV so it is easy to write queries for any
revision of a specific rule or vise versa.

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.

Somebody needs to centrally manage the UID space. Jim? Brian? Max? UID's 0-999
could be reserved for local homebrewed rules, so no rule in the snort.org
database would be given an id out of this range. UID's 1000-9999 could belong
to snort.org. UID's 10000-19999 could belong to Arachnids. And similar ranges
could be farmed out to other folks who wish to make rules available outside the
snort.org database.

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

More information about the Snort-devel mailing list