RE: False positives with UDP Portscan PROTO255

["Mike Lieberman" <Mike () netwright net>]

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 () utc edu] 
Sent: Saturday, March 05, 2005 4:48 PM
To: Mike Lieberman
Cc: snort-users () 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



-------------------------------------------------------
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.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users