Re: a novice question. -reply

[Mark.Teicher () predictive com (Mark.Teicher () predictive com)]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
Each IDS system that has been mentioned has shortcomings.  Dragon is 
vastly different from ISS RealSecure.  Dragon has other issues that far 
beyond some of the nuances that ISS RealSecure has.  The current version 
of Dragon still needs drastic improvement in order to even make a dent in 
the IDS market segment. Dragon still requires a high level of TCP/IP 
expertise and other skills not commonly known by monitor monkeys.  So 
comparing Dragon to ISS RealSecure is like apples to oranges.  :)

/mark

Jackie Chan <blue0ne () igloo org>
Sent by: owner-ids () uow edu au
03/25/00 12:45 PM

 
        To:     Stuart Staniford-Chen <stuart () SiliconDefense com>
        cc:     ids () uow edu au
        Subject:        Re: IDS: a novice question.

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
Stuart,
        Ouch!  Well clearly there are folks that are still searching for
this vulnerability, ( I know I am anytime I run a pen test).  Perhaps I
should have picked a better example, such as kerberos attacks on an
infrastructure that does not utilize it.

Yo bring up a good point however about utilization.  I for one used this
technique of turning off signatures that were extremely outlandish when
the engine was RealSecure.  I truly hope an ISS rep can respond to this as
I am not sure why, but the CPU load on a Soalris X86 was all but sucked
dry by the realsecure process.  This lead me to believe that perhaps it
really was eating up all reseources keeping up with the load I was dolling
out to it.  However when and IDS such as Dragon was run, its TOP listing
showed that it was not eating up even half of the resources that
realsecure was.  This of course could be caused by several reasons that I,
someone who has no access to the inner workings of the realsecure engine,
am not aware of.

Stuart, thanks for check :)  Although the reason I am still pro "IDS
optimization through Policy clarification" is probably due to my days
programming on the 8-bit 6502.  I agree however that it is much more an
operating opinion than an operating fact.

Cheers,

blue0ne

On Sat, 25 Mar 2000, Stuart Staniford-Chen wrote:

> Jackie Chan wrote:
>
> > for all signatures to be aware of any attack, my position is that if I
> > turn off for instance PHF attack, knowing that my network does not 
contain
> > such an old exploit, that I will optimize the IDS.  If in the event 
that
> > someone has placed a vulnerable (and extrememly old) version of apache 
on
> > my network, it is logical to assume that you will pick up either pre
> > attack probes as well as other attack signatures associated with this
> > attacker.  It is highley unlikely that 1. someone decides to place an 
old
> > version of apache web server on the network, and 2. an attacker would 
look
> > only for that one particular exploit wihtout first probing around or
> > attacking other resources as well.  For those planets to be aligned it
> > takes one heck of an odd probability, a risk that I am ready to assume 
to
> > allow optimization of an IDS.
>
> I really hate to do this to you, but your example was an unlucky one :-)
> :-) The following was posted by Ed Padin to the
> "incidents () securityfocus com" mailing list yesterday.
>
> > I got this one also and wrote to Gunnar.Pfeil () RZ Uni-Jena DE as listed 
in
> > the ripe.net whois listing. They actually responded and told me that 
they
> > were investigating it.
> >
> >
> > > -----Original Message-----
> > > From: Matthew S. Hallacy [mailto:mhallacy () MERCURY XTRATYME COM]
> > > Sent: Wednesday, March 22, 2000 10:41 PM
> > > To: INCIDENTS () SECURITYFOCUS COM
> > > Subject: Re: Scans from udel.edu and tue.nl
> > >
> > >
> > > [largish snip]
> > > > It's likely that other readers have seen these problems as well.
> > >
> > > Yes actually, all of our webservers (on different /24's, i might add)
> > > recieved this scan:
> > >
> > > fsuj83.rz.uni-jena.de - - [16/Mar/2000:20:10:56 -0600] "POST
> > > /cgi-bin/phf?Qname=x%0a/bin/sh+-s%0a HTTP/1.0" 404 205
> > >
> > > of course, it wasnt there, but it still set off a few alarms =)
>
> By turning off that signature, you'd have missed that scan, and thus not
> been able to report it to the folks at the other end who turned out to
> be responsive.
>
> If in a particular deployment the NIDS is cpu bound (sometimes they are,
> sometimes they aren't) then it may be necessary as you say to turn off
> some signatures so the IDS can keep up.  But some IDS's are better than
> others at searching signatures efficiently in parallel as far as
> possible, so how much difference it makes to the IDS performance is
> likely to vary.
>
> In general, it seems to me that it's not very efficient for a NIDS to
> search all the signatures linearly.  Hopefully, any vendors that do that
> are moving away from that algorithm.  It's more efficient to use some
> kind of prefix dictionary search.
> Eg if "/cgi-bin/phf" and "/cgi-bin/count.cgi" are both in the signature
> set for a string matching type IDS, then the sensor should only be
> matching once on the "/cgibin/" portion, and bothering to check the
> "phf" and "count.cgi" parts only if the earlier part of the signature
> already matched.  (I'm simplifying all the issues of /./, % codes etc
> that have to be dealt with in practice).  That means that generally
> doubling the number of signatures should much less than double the cpu
> cost of signature checking.  And matching the individual pieces should
> be done with some efficient algorithm like Boyer-Moore.
>
> Do folks that like to turn off a lot of signatures measure the resulting
> CPU performance gain (with top or whatever) to make sure it's really
> making an important difference?
>
> My own experience with several NIDS's is that false alarms that occur
> because innocent traffic happens to match the signature spuriously are a
> much bigger problem than real attacks that are misaimed at a
> non-vulnerable host/service.  (I don't have any quantitative evidence
> here, it's just my subjective experience - it would be nice if we had
> people doing statistical analysis about false alarm rates on particular
> signatures, but I don't think we're there yet).
>
> Stuart.
>
> --
> Stuart Staniford-Chen --- President --- Silicon Defense
>                    stuart () silicondefense com
> (707) 822-4588                     (707) 826-7571 (FAX)