[Snort-devel] RFC Snort Rules Unique Identifier
hailjt at ...189...
Tue Apr 17 23:33:22 EDT 2001
> > CHANGES TO ALERT FORMAT:
> > The revised snort alert would look like
> > [**] UID: #### REV: #### Message [**] blah blah blah...
> > MANAGEMENT OF UID SPACE:
> > Somebody needs to centrally manage the UID space. Jim? Brian? Max? UID's
> > could be reserved for local homebrewed rules, so no rule in the
> > database would be given an id out of this range. UID's 1000-9999 could
> > to snort.org. UID's 10000-19999 could belong to Arachnids. And similar
> > could be farmed out to other folks who wish to make rules available
> > snort.org database.
> heh.. obviously it makes sense (at least to me), althrough having uid and
rev fields sounds
> like an overkill, maybe something like: ruleID: [id].[rev] would be
Could be. Much like Jim's suggestion regarding the alert format. As much as
anything I was striving for clarity, and I think it is critical that we keep
track of rule revisions. It becomes very confusing to look back at a 3 month
old alert and then ask "Now which Bind Overflow rule was that?"
> As for rulemanagement, there are quite some overlapping rules in
> with snort rulebase, the one which comes from snort.org and arachnids,
> really make sense to split the ruleID space between the 'rule vendors' so
> say? Maybe would be enough to have some central ruleID-tracking mechanism
> :*)) so when new rule is about to be submitted new rule ID should be
I like this idea, then it takes less time for someone to maintain the rule
space. If such a service were provided such that Max and others could go
there to grab an id with a minimum of hassle, that would be a good thing. It
would be really nice to hear what you think here Max! Also, who is going to
write this CGI in an, *ahem*, secure fashion? If somebody is dieing to do
this speak up. Otherwise I'll take a stab at it. Haven't checked lately, is
snort.org on *nix/apache yet??
> just $.02
Thanks, don't sell yerself short!
More information about the Snort-devel