[Snort-users] false positive generator

Bob Walder bwalder at ...1926...
Wed Feb 11 03:08:01 EST 2004


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.

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.

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.

Regards,

Bob Walder
Director
The NSS Group




>> -----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 10:39
>> To: Matt Kettler
>> Cc: Peggy Kam; snort-users at lists.sourceforge.net; 
>> Dirk_Geschke at ...1344...
>> Subject: Re: [Snort-users] false positive generator 
>> 
>> 
>> Hi Matt,
>> 
>> I think you misses something...
>> 
>> > Well, if anyone knows something that's a false positive, 
>> let the snort
>> > developers know so they can fix it ASAP.
>> 
>> Yes, that's true. But not all false positives can be eleminated.
>> 
>> How about UDP rules searching for a special content in the payload?
>> 
>> > Are you really trying to generate _false_ positives, or 
>> just generate
>> > alerts? Not all alerts require an actual overflow to occur..
>> 
>> The idea is to create alerts which are recognized by the 
>> sensor but do not belong to a real attack. This is of course 
>> useful for debugging/testing/benchmarking. Think about a 
>> tool like ACID, it won't make fun to develop a new one if 
>> you have only one kind of alerts in the database...
>> 
>> > A nessus safe-mode scan should fire off at least a few alerts, 
>> > although
>> > I'll admit I haven't tried it recently.
>> 
>> Yes, but this are only a few. And you can't really test all rules.
>> 
>> A false positive generator like "fpg" tries to build for 
>> every rule an appropiate network packet that should raise 
>> the rule to generate an alert. This alert should then be 
>> found in the logs or mucht better in the database. Since you 
>> know how the packet was built you should be able to verify 
>> that the alert information in the database are correct or not. 
>> 
>> How will you do this with only sniffing on real attacks? You 
>> must have a tcpdump running parallel to snort to see if the 
>> alerts are relatedt to the original network packet?
>> 
>> So finally: False positive generators are very useful under 
>> certain circumstances.
>> 
>> 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=snort-users
>> 






More information about the Snort-users mailing list