[Snort-users] False positives with UDP Portscan PROTO255
Mike at ...12324...
Sat Mar 5 16:11:01 EST 2005
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.
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
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