[Snort-users] False positives with UDP Portscan PROTO255
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