[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
> 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
> > 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
> > 3 even though any traffic to this particular destination should be
> > 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
> > 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
> > more severe for the same event.
> You've hit upon a good point. Consider this for a moment: If you
> enough about how things work to 'notice' this, then wouldn't you also
> use the 'standard' rules as shipped? Wouldn't you as a snort-admin have
> the time to clean, prune and tweak the rulesets? If so, ordering them in
> 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.
alert tcp any any -> any any (whatever..., sid:1123; rev:4;)
(...will stay always disabled even when updated)
GMX - Die Kommunikationsplattform im Internet.
More information about the Snort-users