Snort mailing list archives

Re: Meaning of priority?


From: carold () gmx net
Date: Fri, 5 Jul 2002 19:36:36 +0200 (MEST)

On Fri, 5 Jul 2002 carold () gmx net 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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users


Current thread: