RE: Generating Traffic to Stress Test IDS

From: Matt.Carpenter@alticor.com
Date: 01/25/02 

To: <kenpohniman@yahoo.com>
From: Matt.Carpenter@alticor.com
Date: Fri, 25 Jan 2002 11:05:09 -0500

"Totally useless" is a steep term, indeed much steeper than what you want.
If you drop 1 packet out of 100, you have a 99% chance of catching the
bad-stuff. But what if that one packet IS the bad one. I would definitely
scale my boxes and software to attempt 100% scanning, if only to get the
absolute best.

Enter Reality:
At present date, a lot of bad traffic is automated and recurring, meaning
that depending on the patterns you're supposed to be seeing you may be able
to see most of them even dropping a few packets. Have you ever played
russian roulette? You want to have the least amount of bullets possible in
a gun with the most chambers possible... it's even nicer if there's no
bullet. You choose. :)

If you can't get a box big enough with software capable of handling 100%,
you may be able to better your chances by putting multiple boxes looking at
the same wire. This is where SNORT's value goes beyond simply being able
to handle more traffic than others, and you save on licensing. If you are
looking at SNORT, let me encourage you all to look into DEMARC, a web GUI
for managing multiple SNORT boxes.

If you need any help with DEMARC/SNORT, there are many willing to help.
Consider me one.

Thanks,
Matt

                                                                                                                   
                    "Ken
                    Pohniman" To: <Matt.Carpenter@alticor.com>, <cgrout@chrisgrout.com>
                    <kenpohniman@ cc: "'Chad Gough'" <chad131@yahoo.com>,
                    yahoo.com> <focus-ids@lists.securityfocus.com>
                                         Subject: RE: Generating Traffic to Stress Test IDS
                    01/25/2002
                    09:04 AM
                    Please
                    respond to
                    kenpohniman
                                                                                                                   
                                                                                                                   

Seems that at 60Mbps throughput, the NIDS packet drop rate is about 50%. My
questions is - at what drop rate can an IDS afford to experience before
becoming totally 'useless'? Can the IDS still detect a particular attack if
it drops just 1 of the packet? This is my biggest question actually.
Thanks!

-Ken

-----Original Message-----
From: Matt.Carpenter@alticor.com [mailto:Matt.Carpenter@alticor.com]
Sent: Friday, January 25, 2002 9:46 PM
To: cgrout@chrisgrout.com
Cc: 'Chad Gough'; focus-ids@lists.securityfocus.com;
kenpohniman@yahoo.com
Subject: RE: Generating Traffic to Stress Test IDS

>I'm sure that this is something that needs to be implemented by the
>vendor. For Snort, if you daemonized it, do a 'kill -USR1 pid' and it
>will dump stats to syslog. If not damonized, it will dump stats to the
>console. As for NFR, I know it does also send alerts anytime it begins to

>drop packets.
>
>Also keep in mind, it also REALLY depends on how many filters/signatures
>you are running. Vendor "A" may state one thing, but forget to mention
>that its barely running any filters at all.
>
>At 07:53 AM 1/25/2002 +0800, Ken Pohniman wrote:
>> From what I understand, a NIDS can typically handle up to 40Mbps of
traffic
>>at any one time before starting to drop packets aggresively. An IDS
>>Balancer, like that from TopLayer Networks, will be required, especially
if
>>you're talking about a GE network.
>>
>>Btw, regardless of what tool you use, does anyone knows how to check what
is
>>the packet drop rate on the IDS?
>>
>>Thanks!

Agreed. Most NT-based NIDS canNOT handle 40MB. The OS can't hardly handle
it. The "up-to" part is key.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Relevant Pages

  • RE: Intrusion Prevention requirements document
    ... The tools consider one interface as "client" and other ... Packet 1 is first sent out on client interface. ... > my previous company was Blade Software where I developed IDS Informer ... Up to 75% of cyber attacks are launched on shopping carts, ...
    (Pen-Test)
  • RE: Intrusion Prevention requirements document
    ... The tools consider one interface as "client" and other ... Packet 1 is first sent out on client interface. ... > The product uses two network cards and so the library of over 700 ... > my previous company was Blade Software where I developed IDS Informer ...
    (Focus-IDS)
  • RE: Value of "richer" signatures?
    ... Is it that much faster to do "protocol parsing" than ... > Here's an example of how the newer IDS signatures help ... > Let's say you are using a simple packet grepping IDS ...
    (Focus-IDS)
  • Re: Snort + (OpenBSD or Linux)
    ... Snort + (OpenBSD or Linux) ... many of them begin way before the IDS application even receives a single ... From there your NIC has to make interrupt requests to get more ... your OS for example) and then your application having to copy the packet ...
    (Focus-IDS)
  • Re: Signature vs. Protocol Analysis
    ... sigs of some sort to pass on useful information to the IDS operators. ... you've got the string matcher packet grepping folks. ... So which is more effective at "detection rates?" ...
    (Focus-IDS)