[Snort-users] false positive generator

Bob Walder bwalder at ...1926...
Wed Feb 11 05:41:02 EST 2004


Hi,

Don't get me wrong, I am all for these stateless attack tools - they
serve their purpose. I just thought that if you were trying to populate
a database with "real" attacks they might not be the best way to do it -
I misunderstood your intentions - sorry.

If you are looking to verify maximum insert rates, etc, you could still
use real exploit traffic, captured with tcpdump and replayed under
script control via tcpreplay - probably more controllable than
Stick/Snot/Sneeze and no need to invest in fancy tools.

Regards,

Bob 


>> -----Original Message-----
>> From: snort-users-admin at lists.sourceforge.net 
>> [mailto:snort-users-admin at lists.sourceforge.net] On Behalf 
>> Of Dirk Geschke
>> Sent: 11 February 2004 13:07
>> To: bwalder at ...1926...
>> Cc: 'Dirk Geschke'; 'Matt Kettler'; 'Peggy Kam'; 
>> snort-users at lists.sourceforge.net; Dirk_Geschke at ...1344...
>> Subject: Re: [Snort-users] false positive generator 
>> 
>> 
>> 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 at lists.sourceforge.net
>> Go to this URL to change user options or unsubscribe: 
>> >> https://lists.sourceforge.net/lists/listinfo/sno>> rt-users
>> 
>> 
>> Snort-users list archive: 
>> http://www.geocrawler.com/redir-sf.php3?list=ort-users
>> 






More information about the Snort-users mailing list