Re: false positive generator

[Dirk Geschke <Dirk_Geschke () genua de>]

Hi Bob,

> Perhaps I am missing something, but why do you want to generate false
> positives exactly? Unless you are attempting to demonstrate how a sensor
> handles (or does not handle) false positives (i.e. in this case, I think
> you are really talking about stateless attacks, ones where the 3-way
> handshake has not occurred and only payload is being sent) then tools
> like Stick/Sneeze/Snot are not much use to you. You can check out our
> IDS/IPS reports at www.nss.co.uk/ids if you want to see how sensors
> handle stateless attacks and other types of false positives.

maybe someone will do his own tests on stateless attacks? 
There is of course one valid point to test a sensor. If you
see how it works with stateless attacks you can verify how
the sensor works with a high attack rate. Think of the behaviour
of the output plugins, do they work well on high load?

Does snort start to drop packages on this scenario?

Yes, of course, you don't get a result for real attacks where
the 3-way-handshake must be successfully applied.

> Try using real attack traffic replayed using TCPREPLAY, or a tool like
> Blade IDS Informer/Firewall Informer which does the same thing but all
> wrapped up in a nice GUI and with plenty of pre-defined attacks
> included. That way, you will see some "real" attacks appearing in your
> database.

Yeah, but if you don't have such tools/packets for this tests
and you want to create a very high attack rate to see if the
database is able to handle it?

How about stateless UDP attacks? They are still possible.
So if you are able to generate a high load of UDP alerts
then it would be likely that snort won't recognize the
real TCP attack due to dropping some packets so that he
won't see the established connection.

I think these are all valid points which would justify to
work with such false positive generator.

> Be aware that not ALL the test cases included with the Blade software
> are good - we tend to use real exploit traffic or test cases we have
> generated in house to ensure complete control, but IDS/Firewall Informer
> make the replay easy.

Not everyone has this kind of environment for tests...

For my environment I was simply testing if FLoP is able to
work with a very high rate on alerts which should all be saved
in a database. So every database has limitations on the INSERT
rate which is usually much slower than the possible alert 
generating of snort.

Think of a databas able to insert about 200 alerts per second
and an alert rate of 2000 packets per second. 

Is it possible to store all alerts in the database? Or are some
lost? Or does snort drop packets due to a slow output plugin?

All these questions can be answered with some tools like the
"fpg" program. And that was the idea why I wrote it.

I think you may now see why this kind of alert generators
may be useful...

Best regards

Dirk



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users