DNS server behind a firewall

Hello everybody,

I am sure my question is a frequently asked one but surprisingly
I have found contradictory answers to it. Thus I would like
to clarify the situation.

I have a DNS server behind a router/firewall. The server acts
as a primary DNS server for the LAN boxes. There are a number
(two or three) of trusted `upper level' DNS servers. Do I
understand correctly that I should allow the following incoming
packets addressed to our DNS server:

1. All (NEW,ESTABLISHED) udp packets from ports 1024: to port 53
2. All tcp packets from ports 1024: to port 53 if they originate
from trusted DNS servers
3. All udp packets from port 53 to port 53 if they originate
from trusted DNS servers.

Should rules for packets outgoing from our DNS server look the
same way (just `reversed') or there is something special?
Regards,
Mikhail

muxaul@lenta.ru writes:

> I am sure my question is a frequently asked one but surprisingly
> I have found contradictory answers to it. Thus I would like
> to clarify the situation.
>
> I have a DNS server behind a router/firewall. The server acts
> as a primary DNS server for the LAN boxes. There are a number
> (two or three) of trusted `upper level' DNS servers. Do I
> understand correctly that I should allow the following incoming
> packets addressed to our DNS server:
>
> 1. All (NEW,ESTABLISHED) udp packets from ports 1024: to port 53
> 2. All tcp packets from ports 1024: to port 53 if they originate
> from trusted DNS servers
> 3. All udp packets from port 53 to port 53 if they originate
> from trusted DNS servers.

Aaaaargh!!

There is nothing significant about ports 1024:, so stop right there. And
53<->53 is a completely bogus design as well.

It's really quite simple:

client
incoming
packets match ESTABLISHED,RELATED, so deal with them along with any other
returning-things-I've-asked-for section (one rule will do everything)

client
outgoing
just let them out, or if you're being fascist, open 53/udp in the OUTPUT
chain with rate-limiting.

server
incoming
53/udp open to the big bad world
53/tcp open to your secondary nameservers only

server
outgoing
just let everything out, or if you're being fascist, the source-port will
be 53, or you could probably use ESTABLISHED,RELATED again in the OUTPUT
chain.

Start from <http://spodzone.org.uk/packages/secure/iptables.sh>, and
imagine these two lines extra immediately after the `22' line:

| #Open ports
| iptables -A block -p tcp --destination-port 22 -j ACCEPT
|
| iptables -A block -p udp --destination-port 53 -j ACCEPT
| iptables -A block -p tcp --destination-port 53 -j dnsslaves

To reiterate, there is nothing magic about ports either side of 1024 when
they appear as the source-port. Let them in regardless of where they come
from - that's why it's a DNS server you're running, it's defined by 53 tcp
and udp at the server end, that's all.
The state module will take care of handling returns more securely than any
mere port-range combination, simply because of how it works (when it sees
an outgoing packet, log it, then if a return comes back matching ip#s and
ports and within a timeout interval, accept it).

HTH,

~Tim
--
08:48:15 up 114 days, 17:28, 0 users, load average: 0.06, 0.05, 0.06
piglet@stirfried.vegetable.org.uk |There's a lighthouse, Shining in the black,
http://spodzone.org.uk/cesspit/ |A lighthouse, Standing in the dark

Tim Haynes wrote:
> muxaul@lenta.ru writes:
> > I have a DNS server behind a router/firewall.
[snip]
> There is nothing significant about ports 1024:, so stop right there.
And
> 53<->53 is a completely bogus design as well.
>
> It's really quite simple:
[snip]
> client
> outgoing
> just let them out, or if you're being fascist, open 53/udp in the
OUTPUT
> chain with rate-limiting.
[snip]
> server
> outgoing
> just let everything out, or if you're being fascist, the source-port
will
> be 53, or you could probably use ESTABLISHED,RELATED again in the
OUTPUT
> chain.

Thanks a lot for the reply!

Still, if I understand you properly, my `fascist' rules are correct
in the sense that there _may_ be special rules for communication with
trusted DNS servers 53<-->53 (udp). Right?

Regards,
Mikhail

muxaul@lenta.ru writes:

[snip]
>> just let everything out, or if you're being fascist, the source-port
> will
>> be 53, or you could probably use ESTABLISHED,RELATED again in the
> OUTPUT
>> chain.
>
> Thanks a lot for the reply!
>
> Still, if I understand you properly, my `fascist' rules are correct
> in the sense that there _may_ be special rules for communication with
> trusted DNS servers 53<-->53 (udp). Right?

The other end could use whatever port it likes. That's why, when you're
running a server, you open the port wide open regardless of port.

I don't see that you can usefully add anything that caters for 53<->53 that
isn't already handled by one-sided wide-open or conntrack, however.

~Tim
--
A Celtic fire, a soul of white |piglet@stirfried.vegetable.org.uk
|http://spodzone.org.uk/cesspit

In article <1102681905.267124.320950@f14g2000cwb.googlegroups .com>, muxaul@lenta.ru wrote:
>
> Still, if I understand you properly, my `fascist' rules are correct
> in the sense that there _may_ be special rules for communication with
> trusted DNS servers 53<-->53 (udp). Right?

The client may use any port to connect, so you don't want to use that rule.
In fact using a random port on the client side is used by some DNS clients
to make blind spoofing attacks harder.

Bruno Wolff III wrote:

> In article <1102681905.267124.320950@f14g2000cwb.googlegroups .com>, muxaul@lenta.ru wrote:
>
>>Still, if I understand you properly, my `fascist' rules are correct
>>in the sense that there _may_ be special rules for communication with
>>trusted DNS servers 53<-->53 (udp). Right?
>
>
> The client may use any port to connect, so you don't want to use that rule.
> In fact using a random port on the client side is used by some DNS clients
> to make blind spoofing attacks harder.
The client may use whatever port it has free to initiate connection, but
the RFC for DNS requires that is arrive on port 53. Therefore the rule
is good as it stands 53 <-> 53.\

High ports are not the concern of _your_ firewall host *or* _your_ dns
host. Further, bind can be configured to restrict its communictions to
53 and not get into a creative port war with the likes of Microsucks
boxen. ;-)

--
"Never have so many understood so little about so much."
-- James Burke

In article <jaPvd.4833$Sq.2775@fed1read01>, Gregory W Zill wrote:
> The client may use whatever port it has free to initiate connection, but
> the RFC for DNS requires that is arrive on port 53. Therefore the rule
> is good as it stands 53 <-> 53.\

The above appears to be a contradiction, though perhaps I am misunderstanding
what 53 <-> 53 is supposed to mean. I assumed it meant the ports on both
sides of the connection are 53.

Thanks a lot for the replies!

Typical records in syslog look this way (udp, 53<->53):

kernel: IN=eth0 OUT=eth1 SRC=194.67.81.64 DST=MY_SERVER LEN=72
TOS=0x00 PREC=0x00 TTL=61 ID=2665 PROTO=UDP SPT=53 DPT=53 LEN=52

or this way (tcp):

kernel: IN=eth0 OUT=eth1 SRC=194.67.160.3 DST=MY_SERVER LEN=44
TOS=0x00 PREC=0x00 TTL=59 ID=48041 DF PROTO=TCP SPT=58162 DPT=53
WINDOW=65535 RES=0x00 SYN URGP=0

The rules I described in the first posting permit
these types of connections to a few trusted DNS servers only.
Thus my question can be put this way: is it necessary to ACCEPT
such connections from all possible hosts/DNS servers in the world
or does it suffice to ACCEPT them from a couple of trusted
upper level DNS servers? Actually, once I have called to the
maintainers of a DNS server that was trying to establish TCP connects
with our server and asked them _why_. They did _not_ give me a
definite answer. Still the majority of connection attempts are
of type udp, port 53<->53.

Regards,
Mikhail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQBBwwdZ+gVZmutkHqERAr/RAKCGH8bvQVJSZrV7xnWnC9ypF7aLhQCg04i3
lFpKlJfbQD6xKXf+ggRmNF0=
=q4+t
-----END PGP SIGNATURE-----

Bruno Wolff III wrote:
> In article <jaPvd.4833$Sq.2775@fed1read01>, Gregory W Zill wrote:
>
>>The client may use whatever port it has free to initiate connection, but
>>the RFC for DNS requires that is arrive on port 53. Therefore the rule
>>is good as it stands 53 <-> 53.\
>
>
> The above appears to be a contradiction, though perhaps I am misunderstanding
> what 53 <-> 53 is supposed to mean. I assumed it meant the ports on both
> sides of the connection are 53.
No contradiction. A hardware firewall is in place between two network
interfaces. The abbreviated rule or equation shown indicates that one
(outside-facing) interface deals with the port on the left of the
equation and the second (internal-facing) interface deals with the port
on the right side of the equation. What port the client decides to
initiate is not part of the equation, or the interfaces involved in
setting up the firewall. This represents notation used by firewall admins.

--
"Never have so many understood so little about so much."
-- James Burke