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

Martin Roesch roesch at ...48...
Tue Apr 17 12:27:08 EDT 2001


Brian Caswell wrote:
> 
[snip]
> 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.

Did I say that?  I think what I meant was that it would be selectable.
:)

[snip]
> > 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.

Yes.  The reason that this made it into the 1.8 code is because it was
implemented to a level that reduced my pain of adding it to a minimum. 
I think that the classification and priority system is flexible enough
where just about anyone can define things to their taste,
IDMEF/CIDF/whatever isn't automatically to everyone's tastes, and with
the system the way it's written we can be extremely flexible, yet fairly
simple.

He who gives me something to look at gets higher priority than someone
who gives me suggestions how I should write features that they 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.
> 
> Example
>    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.

Gack, that 'varcontent' thing is a cast iron bitch to write currently
and there's a good chance I won't get to it before 1.8...

> > 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?

The main issue I'd have with this scheme is there's no way to guage the
*real* impact without performing follow-on analysis.  For example, if a
buffer overflow fails its impact goes from "system integrity" (there has
been a buffer overflow) to "intelligence" (this buffer overflow doesn't
work against IP w.x.y.z).  Snort doesn't have this capability currently,
although we have been talking about it a bit for 2.0.

> > (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.

There's a whole class of things that people watch for that aren't
intrusions at all, look at Dragon's "Big Brother" feature set for things
that people may wish to watch their network for.

> > (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.

Where's my copy of NFR, I know I've got one around here someplace.... ;)

> > 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.

This is a political question.  All I'm going to say about it is that the
Snort project needs to be able to provide a vetted rule set for a
variety of users with special needs and while the current database is
suboptimal, we'll be seeing a lot of improvement shortly.

     -Marty


--
Martin Roesch
roesch at ...48...
http://www.snort.org




More information about the Snort-devel mailing list