Re: Hybrid IDS

[Dragos Ruiu <dr () v-wave 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
HELP: Having problems... email questions to ids-owner () uow edu au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
-----------------------------------------------------------------------------
On Thu, 07 Sep 2000, John S Flowers wrote:
> In reference to the document - http://www.robertgraham.com/op-ed/jolt2

Yep, that was the claim that raised eyebrows... But I've read the claim
carefully now and see that it has a lot of err... wiggle room.

So let me ask a blunt question... How many packet per second with full 
alarming does the same "customized, >$4500" sensor do if I transmit dr's
IDS soloflex sequence at it: a continuous stream of  512 byte packets, 
each IP fragmented into four 128 byte fragments,  transmitted with the
fragments from every 10 second (since the rfc recommends 15 seconds of
buffering) window of packets interleaved (i.e. 1,1,1,... 2,2,2,....3,3,3,....) , 
and each containing a CGI query for something that should generate an
alarm, e.g. like requests for "cgi-bin/scripts/newdsn.exe" with the CGI request
encoded as "% coding" and front padded to 1K so that the packet is TCP
fragmented into two 4 fragment packets (8 frags total) and the newdsn.exe is
at the very end of the packet, with all packets addressed towards the IDS
machine, and each request is randomly spoofed to come from a different IP/mac
address. And for bonus points, how is performance affected when you interleave
64 different bad cgi requests and other attack patterns and alarm types 
in the packets?

That's a performance statistic I'll be impressed with - a real IDS drag 
race. Otherwise, my packet filter can probably _discard_ packets at 150Kpps 
too... And when the traffic sequence and sensor actions in the benchmark 
are similarly defined,  that's when I'll take note of and believe such packet
numbers...  Oh, and if you need a traffic generator for all that I can probably
cobble something up if you want to send it over for testing.  :-)

I'm not picking on NetworkICE here... this is an open challenge, if
there are any real security products out there that aren't hiding, afraid.... 
because I think most of the other released IDS junk on the market, that
vendors are BSing customers to fork over unreasonable amount of cash 
for, will suck even worse, or likely not even be able to handle analysis 
of the above traffic. I somehow think that only the "real" tier 1
IDSes like Dragon, NFR, and BlackICE are even in the running
here... the other stuff (I mean... really, $20K for 200 rules on a 
1U 300Mhz p5!) is all overpriced placebo toys that lull naive 
managers into a false sense of security because they've spent 
big money on a big name product from a big company.

I admit that this traffic sequence is a tough one, but I don't think
handling this is an unreasonable request to make of an IDS, because
there are real life traffic patterns that can approach this kind of
scenario.  I think it's a valid benchmark.  And if any IDS vendor 
would like me to test this feel free to send it on over... I'll try this
test on snort shortly and we'll see what I can get... and then I'll
be curious to see which vendors stand behind their product 
enough to publicize their performance on _this_ synthetic 
benchmark.

There, that post should put me on the IDS vendor troublemaker 
lists....   :-) So are there any _real_ IDSes out there?

cheers,
--dr

-- 
dursec.com ltd. / kyx.net - we're from the future
pgp fingerprint: 18C7 E37C 2F94 E251 F18E  B7DC 2B71 A73E D2E8 A56D 
pgp key: http://www.dursec.com/drkey.asc