[Snort-users] false positive generator
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
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.
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
>> 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:
More information about the Snort-users