[Snort-users] False positives with UDP Portscan PROTO255

Jeff Kell jeff-kell at ...6282...
Sat Mar 5 15:49:10 EST 2005

Mike Lieberman wrote:
> I have doubts about some of the messages I am getting from Snort (using 
> 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 Server 
> 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).


More information about the Snort-users mailing list