Subject: resolvers using non-ephemeral ports

From: [email-masked]
Date: Thu, 11 Jan 2001 10:50:04 -0800

>From scanning firewall logs, I've noticed that some dns
resolvers (or attackers) are using ports below 1024 when
talking to a dns server. I've seen packets coming from
ports 646, 665, 727, 737, 744, 904, and 960. These are
a very small percentage of total dns queries however.

This issue is important to me because I teach both dns
and firewall courses. Normally, I would suggest to students
that they block all ports below 1024 (except 53) for packets
sent to the dns server. Now, this data makes me wonder if
we're turning away good guys or bad guys.

What's the official position on resolvers and ephemeral ports?

Ed Sawicki

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 11 Jan 2001 11:36:09 -0800

> What's the official position on resolvers and ephemeral ports?

RFC 1035 is the only almost-explicit discussion on it:

4.2.1. Messages sent using UDP user [sic] server port 53 (decimal).
4.2.2. Messages sent over TCP connections use server port 53 (decimal).

The Very Strict Reading of the complete clauses comes out as "resolvers
should use port 53 as their source port for queries." It isn't a MUST
(it's really only interpreted as a SHOULD by a Very Strict Reading) and
most resolvers use port numbers above 1023 for queries. A lot of servers
still use port 53 as the source port though.

If you want to be precise with your firewall rules, you could block any
traffic which is going to port 53 on your DNS server(s) which is not
coming from port 53 or one of the ports above 1023. Nobody should use any
ports below 1024 (other than port 53) as the source port for queries.

FWIW, the range of ephemereal port numbers was changed a while back. IANA
says (http://www.isi.edu/in-notes/iana/assignments/port-numbers):

The port numbers are divided into three ranges: the Well Known Ports, the
Registered Ports, and the Dynamic and/or Private Ports.

 The System (Well-Known) Ports are those from 0 through 1023.

 The User (Registered) Ports are those from 1024 through 49151.

 The Dynamic and/or Private Ports are those from 49152 through 65535.

An "ephemeral port number" is now technically considered to be one of the
dynamic port numbers in the range of 49152 through 65535. This doesn't
reflect popular usage.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Jim Reid <[email-masked]>
Date: Thu, 11 Jan 2001 11:47:47 -0800

>>>>> "ed" == ed  <[email-masked]> writes:

    ed> This issue is important to me because I teach both dns and
    ed> firewall courses. Normally, I would suggest to students that
    ed> they block all ports below 1024 (except 53) for packets sent
    ed> to the dns server. Now, this data makes me wonder if we're
    ed> turning away good guys or bad guys.

    ed> What's the official position on resolvers and ephemeral ports?

I don't think there is one. AFAIK, there's nothing in the RFCs
indicating what source ports must or must not be used when sending
queries. So probably all ports should be allowed to send stuff to port
53. BIND 8 and 9 will use a random, unprivileged port by default, but
who knows what other implementations do (by accident or design)? The
concept of privileged ports is pretty much UNIX-specific so all bets
will be off for other OSes anyway. Ephemeral ports probably vary by
platform too. And what if a privileged UNIX application uses a port
number less than 1024 to query the name server? Or how about the folk
who explicitly set up their name servers to use a fixed, privileged
port for outgoing queries and let that traffic through the firewall?

---

From: [email-masked]
Date: Thu, 11 Jan 2001 13:13:26 -0800

On 11 Jan 2001, at 11:47, Jim Reid wrote:

> I don't think there is one. 
<snip>
> And what if a privileged UNIX application uses a port
> number less than 1024 to query the name server?

This is a compelling argument. You've convinced me. We
simply cannot filter dns packets on the source port.

Thanks,

Ed

---

From: [email-masked]
Date: Fri, 12 Jan 2001 10:32:49 +1100

> simply cannot filter dns packets on the source port.

	The nameserver it self has a short list of ports to silently
	reject queries from.  i.e. don't send a query from echo.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Jan 2001 22:48:50 -0000

130.235.188.122, for example, is a BIND 8.2.2-P3 cache configured to
send queries to servers from port 54.

On the other hand, my cache refuses to answer packets from clients on
low ports other than 53. There haven't been any reports of problems.

I use a random port number between 1025 and 65535 for each outgoing
query. I recommend the same strategy for all clients and caches: it
makes DNS packet forgeries much more difficult.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Jan 2001 20:20:06 -0000

[email-masked] writes:
> don't send a query from echo.

That's a pointless restriction. Forging a DNS packet from an echo server
is no worse than forging a DNS packet from a DNS server.

Neither situation creates a loop as long as servers (1) always set the
response bit in their outgoing packets and (2) never respond to incoming
packets with the response bit set.

Of course, cross-protocol loops are still theoretically possible. The
real problem is that UDP doesn't distinguish clients from servers. One
workaround is to design protocols so that outgoing packets are always
after incoming packets in lexicographic order.

---Dan