[Snort-users] False positives with UDP Portscan PROTO255

Mike Lieberman Mike at ...12324...
Sat Mar 5 16:11:01 EST 2005


Jeff,

	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 more
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 the
likelihood that I would catch the 'true' one? 

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

Mike

-----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 (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 
host.

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).

Jeff





More information about the Snort-users mailing list