[Snort-users] False positives with UDP Portscan PROTO255

Orit Vidas orit at ...12437...
Tue Mar 8 11:59:14 EST 2005

Jeff and Mike,

I was wondering if you've had a chance to check out SFS (Securimine for
SFS is distributed as a freeware and is a baseline analysis tool
designed to detect anomalies and decrease the amount of false positives.

SFS enhances your ability to detect the real threats out of all the
security alerts generated by Snort. This is done without the need to
exclude ports or signatures, as the SFS analysis engine uses
sophisticated data mining algorithms to analyze the alerts and to
compare these alerts to the "normal" behavior of your site. 

The end result is a concise report that will reduce substantially the
number of groups to view and the numbers of alerts to inquire.

You can download SFS for FREE at http://www.securimine.com/download.html

You can read more about the technology at

Best regards,
Orit Vidas

-----Original Message-----
From: snort-users-admin at lists.sourceforge.net
[mailto:snort-users-admin at lists.sourceforge.net] On Behalf Of Mike
Sent: Saturday, March 05, 2005 4:10 PM
To: 'Jeff Kell'
Cc: snort-users at lists.sourceforge.net
Subject: RE: [Snort-users] False positives with UDP Portscan PROTO255


	Thanks for the reply.

	The black hats are without a doubt aware of this, but a portscan
that can't distinguish normal traffic from abnormal traffic is of no
value than no port scan at all, or worse yet it is less of a value as it
obscures other valuable messages.

	If I am getting 999 false positives to one true positive, what's
likelihood that I would catch the 'true' one? 

	With all respect to those who write and maintain the rules, I
find this rule helpful and will seek to exclude port 53. IMHO we need a
sophisticated tool in this regard. 


-----Original Message-----
From: Jeff Kell [mailto:jeff-kell at ...6282...] 
Sent: Saturday, March 05, 2005 4:48 PM
To: Mike Lieberman
Cc: snort-users at lists.sourceforge.net
Subject: Re: [Snort-users] False positives with UDP Portscan PROTO255

Mike Lieberman wrote:
> I have doubts about some of the messages I am getting from Snort
> rules for 2.3). For instance the following portscan message is from 
> ns1.sprintlink.net to ns1.netwright.net. We see DNS server to DNS
> traffic labeled as port scans. In the case below, unless Sprint's 
> primary name server ( as well as many others from [have]) has been 
> compromised, these 'portscans' would actually have to be something 
> related to BIND.

Any significant number of DNS queries within a short time (depending on 
your portscan settings) will do this because the traffic is 
connectionless.  Although you and I know these are query/response, the 
generic portscan preprocessor doesn't.

If you consider a number of queries to a given host (which can precisely

be the case if you have a 'cacheing-only' forwarding server on one side)

you have sequentially increasing source [ephemeral] ports querying the 
host on udp/53.  The replies look like a fixed source port (udp/53) 
going back to those sequentially increasing ephemeral ports on the same 

And that is the generic "definition" of a portscan -- a fixed source 
port sending traffic to differing ports on the same destination IP.

You could exclude source port 53 to eliminate these, but bear in mind 
that the black hats are a step ahead of you; a clever UDP port scan will

use source port 53, or other common incoming service port (which is 
typically allowed in a simple firewall ruleset).


SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
Snort-users mailing list
Snort-users at lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
Snort-users list archive:

More information about the Snort-users mailing list