RE: false positive generator

["Bob Walder" <bwalder () spamcop net>]

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 () lists sourceforge net 
> > [mailto:snort-users-admin () lists sourceforge net] On Behalf 
> > Of Dirk Geschke
> > Sent: 11 February 2004 13:07
> > To: bwalder () spamcop net
> > Cc: 'Dirk Geschke'; 'Matt Kettler'; 'Peggy Kam'; 
> > snort-users () lists sourceforge net; Dirk_Geschke () genua de
> > 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 () 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




-------------------------------------------------------
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