[Snort-devel] Re: [Snort-users] snort 1.8 changes - priorities & whatnot

Brian Caswell bmc at ...227...
Tue Apr 17 11:58:55 EDT 2001

Max Vision wrote:
> First off, great work on these improvements!  I have some constructive
> criticism of the current scheme but I also understand that you meant for
> this to be subject to change.

Wee.  I announce a feature, and get a long thought out response.  Neat :)

> Over the past week I have made a significant changes to arachNIDS in
> development which I hope to push into production in the next day or
> so.  One relevant improvement is the addition of the "priority" field.  I
> added this field so that arachNIDS could create a more intelligent
> signature export that would be sorted such that more detailed and specific
> rules would be listed first, and the more generic catch-all rules would be
> listed last.  I spent a good amount of thought on the problem, and came up
> with five levels of granularity that seem to work pretty well for
> prioritizing the rules.  The field is not meant to be included in the
> signature export, but is instead used by the database to sort the
> dynamically generated signatures during export.  I will detail this in a
> separate email when I push the updates.

Well, remember ... Marty was looking to change snort from being a first-exit
to last-exit engine once the silicon defense's new mattern matching code is
integrated.  Rule ordering will likely be made moot by that change.

> Since I'm talking about recent arachNIDS updates I should also mention that
> I have added the "TargetAffected" field, which allows for sorting based on
> which rules that affect your operating environment.  Other improvements
> include multiple sets of content and uricontent rules, grouping, complete
> concordance with BlackICE, etc.  All of these fields are populated.
> Back to the subject though... this new attack classification system that is
> mentioned, based on IDMEF from the IDWG of the IETF, has some issues.  Take
> the classic "phf attack" example.  In a signature that watches for the
> uricontent "phf", we can't really say that it is "attempted-recon".  The
> schema proposed/implemented should instead group the phf attack as one of
> the following:
>    attempted-user,Attempted User Privilege Gain,8
>    unsuccessful-user,Unsuccessful User Privilege Gain,7
>    successful-user,Successful User Privilege Gain,9
>    attempted-admin,Attempted Administrator Privilege Gain,10
>    successful-admin,Successful Administrator Privilege Gain,11
> Since this particular signature is only alerting on the attempt, and not the
> success or failure response, we can rule out several and reduce this to:
>    attempted-user,Attempted User Privilege Gain,8
>    attempted-admin,Attempted Administrator Privilege Gain,10
> But we cannot know which unless we know more about the target environment
> (in many cases the phf vulnerability would yield userid of the webserver,
> which is usually "nobody" or "www", but can also be root.)  But what if the
> server doesn't even have phf installed?  In such a case this probe might be
> misinterpreted to be attempted-recon ("is there a phf script there?") -
> though that would be incorrect classification of the vulnerability.  The
> attacker doesn't really care just whether phf is present, they care whether
> they can access it to gain privilege.  The pure act of knowing that phf is
> present is not, in and of itself, a vulnerability.  I didn't look through
> all of the rules listed in CVS, but most of the ones I saw had the wrong
> label (recon instead of access).

Yes.  We have to assume the usual systems.  Heck, Most systems don't give you
automaticly root shell if you connect to port 22, but some do.  We have to
draw the line somewhere.  I really needed this feature for my uses, so instead
of talking about it for months, I wrote it.  Remember the old addage... those
that write the code rule the world.  :)  (Translation : If you don't like it,
write a new one.)  Like I had said, the IDWG/IDMEF classifications is just an
example.  It is the only "standard" that I can find.  sp_priority can handle
any type of classification you want.  

> If there were a rule to specifically detect a "GET /cgi-bin/phf HTTP/1.0"
> (note the specific lack of exploit content after the phf uri), then it
> could be argued that the intrusion event is not the phf _attack_, but the
> phf _probe_, thus earning the label attempted-recon.  Maybe a content rule
> that specifically watches for "phf " (trailing space), or a negation rule
> would seal this.  A separate rule would then need to be made to detect the
> actual attack, which would earn a more severe attack classification, such
> as attempted-user or attempted-admin.

Correct.  This is where I am going towards.  Looking for "/phf" in the URI is
just a probe.  If we looked for arguements to phf (with stuff after a ? or the
content of a POST) then that is an attack.  I have already put the bug in
Marty's ear about having a varcontent rule field that would handle this.

   uricontent:"/phf"; varcontent:"?",class-if-fail,class-if-exists

Then we can have even further grainularity based on if there was an actual
attack without the need for extra rules.

> That brings us to "impact", a field that I have intended to add for quite
> awhile, and will now do sooner rather than later (now that there is code
> support for reporting classification/priority in the default snort
> output).  I don't like the proposed settings offered in IDMEF (more on why
> below).  I was thinking of adding a field for "impact" and having the
> following options:
>    system integrity (executing code, shell access, etc)
>    confidentiality  (ability to read files/data)
>    accountability   (disabling logging, bouncing attacks, etc)
>    availability     (denial of service attacks)
>    intelligence     (information gathering/recon short of confidentiality)
> This needs work though, which is why I haven't implemented it yet.  For
> example, many DOS attacks might also be exploitable, violating system
> integrity.  Or vice versa, a failed exploit could be a DOS, such as an
> exploit run against a target the is not vulnerable to compromise, but does
> crash (xntpd, etc).  How can we judge whether the intention of the attacker
> was to crash the service, or exploit it?  I think this area desperately
> needs discussion and planning, and that the IDMEF list is the wrong level
> of granularity to use in classification of intrusion events. (but maybe I'm
> wrong, let's talk :)
> Discussion?
> Here is my nitpicking of the IDMEF classifications - I have added the
> number of occurrences that each is used so far in the Snort rules in CVS
> before each one:

Ok.  I've commented on your comments.  Feel free to comment on my comments of
your comments of my comments.  Any other comments? :)

> (2) not-suspicious,Not Suspicious Traffic,0
>    If an event is not suspicious, then why is your IDS alerting on it,
>    and how can the intrusion event even be considered an intrusion?

Many people alert on outgoing traceroutes.  Its not suspicious.   Happens all
the time.  But people still watch for it.

> (2) unknown,Unknown Traffic,1
>    I am in the hard-AI camp, I don't believe in "unknown". What is this? :)

What about oddball protocols?  Snort doesn't handle protocols it doesn't know
about.  In the future I see someone wanting to alert on any traffic that
doesn't seem "normal".

> (53) bad-unknown,Potentially Bad Traffic, 2
>    Here we go again with "unknown" - also, aren't all IDS events "bad"?

Well, seeing SSH traffic on a different port than 22 could be potentially
bad... but could be fine.

> (0) successful-recon-largescale,Large Scale Information Leak,5
>    This doesn't apply to a single intrusion event, this is a more broad
>    reporting function and should probably not be tied to a signature.

Number of hosts being scanned.  spp_portscan reports exactly those types of
alerts.  If someone does a large scale portscan, then thats a large scale
information leak.

> (53) attempted-dos,Attempted Denial of Service,6
> (0) successful-dos,Denial of Service,7
>    How are we supposed to differentiate these?

Right now?  Thats really hard.  If we incorporate application state, we might
be able to look for potential DOS triggers and then watch to see if that host
stops responding.  

> (78) attempted-user,Attempted User Privilege Gain,8
> (6) unsuccessful-user,Unsuccessful User Privilege Gain,7
> (0) successful-user,Successful User Privilege Gain,9
>    Ok.
> (99) attempted-admin,Attempted Administrator Privilege Gain,10
> (0) successful-admin,Successful Administrator Privilege Gain,11
>    Ok. Though, to be consistent, "unsuccessful-admin" is missing..

Well, unsuccessful-user does not technically exist in IDWG/IDMEF.  I added
that after the fact because I saw a number of potential uses.

> I don't understand why people would spend the enormous amounts of time and
> effort to effectively create duplicate work.  Each new signature that is
> added to those flat text file lists will soon (if not already) have a
> counterpart in arachNIDS - though the arachNIDS entry will actually be a
> rich/detailed description with packet captures and details about each
> aspect of the intrusion event, and the signature will be dynamically
> created from the information and exported along with hundreds of others (I
> do not enter or create signatures, they are synthesized from the component
> data).  Why not contribute to this process at a meaningful level by
> contributing full entries to the database, instead of doing all of this
> work in a text file that *is* going to end up obsolete/duplicate?  arachNIDS 
> is also likely to be the only place that people writing signatures will see 
> *credit* for our work.   What can I do to help make arachNIDS your first 
> stop when documenting/contributing new intrusion events? (aside from 
> documentation, which is on it's way, really :)

I have quite a bit more to talk about this, but I am late for a meeting. 
Since this is going to be a hot topic, I'll send this out now with a promise
of more to come.


More information about the Snort-devel mailing list