[Snort-sigs] Reporting false positive for Snort rule

Josh.Sakofsky at ...1573... Josh.Sakofsky at ...1573...
Tue Feb 24 08:16:01 EST 2004

just a thought, but if these are internal servers triggering this alert, 
you might want to fine tune your $EXTERNAL_NET variable...
it can really limit the amount of false positives....

"Dan Thorson" <dan.thorson at ...2264...> 
Sent by: snort-sigs-admin at lists.sourceforge.net
02/20/2004 04:28 PM

<snort-sigs at lists.sourceforge.net>
<dan.thorson at ...2264...>
[Snort-sigs] Reporting false positive for Snort rule

# This is a template for submitting snort signature descriptions to
# the snort.org website
# Ensure that your descriptions are your own
# and not the work of others.  References in the rules themselves
# should be used for linking to other's work. 
# If you are unsure of some part of a rule, use that as a commentary
# and someone else perhaps will be able to fix it.
# $Id$

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"BAD-TRAFFIC data in TCP 
SYN packet"; flags:S,12; dsize:>6; 
reference:url,www.cert.org/incident_notes/IN-99-07.html; sid:526; 
classtype:misc-activity; rev:6;)

Reporting a potential false positive

Detailed Information:

Affected Systems:

Attack Scenarios:

Ease of Attack:

False Positives:
I am seeing a significant # of hits on this rule, always from a NetWare 
server running "DS Expert", sending to another NetWare server (being 
monitored by DSExpert).  This may be due to DSExpert being an older copy, 
but thought you'd want to know.  Here's the TCP data.  Destination port is 
always 524, with SYN set.
000 : 74 4E 63 50 00 00 00 0F 11 11 00 FF 00 FF 00      tNcP...........

False Negatives:

Corrective Action:


Additional References
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20040224/54a87caa/attachment.html>

More information about the Snort-sigs mailing list