Roger
Sat May 20 16:42:34 CDT 2006
Bind has had a number of fixes or the recent years, say since MS DNS
started to be widely used, but W2k and later MS DNS has also had a
couple (fewer than Bind). There is no real way to project risks from
future discoveries of code weaknesses, and those issues would be
something to deal with whether using forwarder or not.
I place comments inline.
<boomboom999@yahoo.com> wrote in message
news:1148144155.914239.125400@i39g2000cwa.googlegroups.com...
> To make things clearer ...
>
> We have Active Directory with 5000 users, and every Domain Controller
> is a DNS server as well. To allow resolving external DNS adresses there
> are two options:
>
> 1. Open outbound TCP/UDP 53 connections from the domain controllers
> toward the Internet.
>
> 2. Use an intermediate forwarder DNS servers
>
Note that this also requires 1 above, as even the DMZ is "toward" the
internet.
>
>
> 1. Pros and Cons for a direct connection
>
> + Simplier solution
> + No additional hardware/software required
> + No risk of hijacking external DNS resolution by a hacker
>
Simpiler from one perspective (fewer servers involved).
Less simple from another - each DC either has this opened, or you
establish hierarch of DCs forwarding to the few that do.
No hijack risk for the non-existant DNS, but potentially at the cost
of moving that risk onto DCs.
> - If I open outbound UDP, I should also allow inbound UDP responses. As
> UDP is connectionless, there is no way for the firewall to make sure
> that inbound packets are related to the previous outbound packets. So,
> it is possible to send some corrupted UDP packets to the internal
> Domain Controllers and cause a DoS or take control of the Active
> Directory
>
Since DNS server can select to use TCP, even for query responses
(i.e. not just zone transfers) and will do so if the additional info to be
returned makes packet size too large for UDP.
Hence, actually open outbound UDP and TCP 53.
You comments on UDP show why if is risky if the DC's DNS does
accidently become configure to answer on the IP that routes outward.
If you use the DNS server node properties Interfaces tab to list only
the interfaces that are not routed out (i.e. for internal use only) then
the outward interface can still be used for outward queries to DNS
servers and/or forwarding. The DNS service will however not accept
inbound queries on that interface. This is necessary if you want to
protect the DNS from a query flood DoS attempt and if you want
to keep internal zones from being exposed.
> - There were vulnerabilities in BIND like this one
>
>
http://www.kb.cert.org/vuls/id/844360
>
> An incorrect DNS response can causer a buffer overflow on the internal
> server -> remote code execution -> phoning home -> taking control over
> the Active Directory
>
As said before, risks are risks.
You are only discussing where to move them.
> 2. Pros and Cons for a connection via forwarder
>
> Same points in reverse order.
>
> An additionnal Con point for the forwarder - if someone take control
> over the DNS forwarder (ISP's one or our own forwarder) it is possible
> to hijack and manipulate all the external DNS requests, redirect
> trafic, sniff it etc. So, if I go with forwarder, it would be necessary
> to put it into a separate DMZ that is not exposed to inbound
> connections.
>
If your traffic that routes to external IPs has info that you would
not want sniffed you have other issues to be addressed. There is
a chance that a successfully subverted DNS could be used for a
man in the middle, which, while a quite difficult thing to pull off,
is probably as large of a concern as use of traffic redirection for
sake of for sniffing.
> What would you recommend?
>
First, consider that you do not want just one forwarder, if using
forwarders, at least not if the DC DNS services are enslaved to
the forwarders for external resolution. That is, you do not want
to introduce a single point of failure.
Another omitted consideration is that with forwarders used the
holes punched in the perimeter are very precise - 53 to/from
only the forwarders' IPs. Without forwarders the permit is for
all IPs to/from only the DCs' externally routed IPs (not to/from
the DCs' IPs that are allowed to answer DNS queries).
If the forwarders are yours you must have them accept recursive
queries (requirement to act effectively as a forwarder). That in
turn exposes them to query flooding if they are exposed to
accept queries from more than just the DCs. If they are not
so exposed then they could not be used to support your public
DNS zone(s). Etc. Just clarifying the extra cost issues here,
as in an ideal setup they are dedicated to the role as forwarders
for the DCs.
One pro, at least to some, of use of a couple forwarders is that
there are only a couple of caches to snoop into in order to see
all external locations that have been accessed by name - instead
of having it spread over the sum of the DCs.
OK, so what way would I go? Well, there could be other
things specific to an environment, but in general I would spend
the money and have the DCs as well protected as I can - which
means using forwarders with a network config that allows only
one IP on the DC to route to/through the wall and so forcing its
use when sending to the forwarders. This reduces the size of
exposure through the wall (with forwarders' IPs only) for ports 53
and allows restricting DNS services from answering on that IP.