[Snort-users] Meaning of priority?

carold at ...158... carold at ...158...
Fri Jul 5 10:37:07 EDT 2002


> On Fri, 5 Jul 2002 carold at ...158... wrote:
> 
> > RTFM says that "The priority tag assigns a severity level to rules."
> > However, could somebody explain what is the functional meaning? I have
> > verified that it is not *processing* priority.
> 
> It's simply a value _you_ as the admin of snort assign.  As an admin, you
> should tune your rules for your network.  Consider what's important to you
> and
> flag it as such.  Then edit classification.config to your needs.

So I read it that it is just for output processing and/or rule reviews.

> > Is it just a tag for the output processing? If yes, is it not illogical
> that
> > processing priority can contradict output priority, such as:
> >
> > alert tcp any any -> $mynet 80 (msg:"web access"; priority:3;)
> > alert tcp any any -> $secrethost any (msg:"nobody should go there";
> > priority:1);
> >
> > In the example above, web traffic to $secrethost will be logged as
> priority
> > 3 even though any traffic to this particular destination should be
> priority
> > 1.
> 
> Only if $secrethost was inside of $mynet.  :)
> 
> > Somebody could suggest that I can just swap the two rules and everything
> > will be fine. I would agree with this particular case but not in
> general.
> > Default snort rule blocks are arranged by topic (web, dns, etc.), not by
> > priority, so it is common that less severe rules might get triggered
> before
> > more severe for the same event.
> 
> You've hit upon a good point.  Consider this for a moment:  If you
> understand
> enough about how things work to 'notice' this, then wouldn't you also
> _not_
> use the 'standard' rules as shipped?  Wouldn't you as a snort-admin have
> taken
> the time to clean, prune and tweak the rulesets?  If so, ordering them in
> a
> more 'logical' fashion for your network and priorities would be a natural.
> Many folks who are running snort don't even consider this.  They just want
> something that 'works out of the box'.  :)

The trouble with completely customizing the ruleset will become apparent
when the admin tries to update/merge his custom set with new rules from an
updated default set. Very painful! I did it a few times I have no interest in
doing it again. Ultimately I have settled for adding machine-processed comment
tags to the default set but it is clearly a cludge. One of possible
architectural solutions would be to allow the user to enable/disable/override rules
outside of the ruleset itself. This way the updated default ruleset will stay
more or less customized for each specific user, regardless of revisions.
Example:

custom.conf:

    disable: 1123
    
default ruleset:

    alert tcp any any -> any any (whatever..., sid:1123; rev:4;)
    (...will stay always disabled even when updated)

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net





More information about the Snort-users mailing list