|
Posted by Roger Abell [MVP] on May 20, 2006, 2:48 am
If you were Registered and logged in, you could reply and use other advanced thread options
In reviewing prior post I see I used term "interface" which is how it
is termed in the DNS management UI when in fact what should have
been said was "IP" since these "interfaces" are named by IP.
Thus similarly I used "multihomed" when this should have been
something like "virually multihomed" or "with multiple IPs"
The bottom line is that one needs to be able to use the DNS config
to disallow answering queries on the "interface" used for external
forwarders or outbound queries.
--
Roger
>> Hi,
>>
>> Is it considered a good security practice to not allow DCs making
>> direct DNS requests to Internet?
>>
>> I have read about different DNS responses attacks that can help an
>> attacker to take control of the DC via an incorrect DNS response
>> (buffer overflow etc.).
>>
>> Would it be more secure to use DNS forwarders?
>> If yes, where we should place them? Into DMZ?
>>
>> Thank you
>>
>
> This is not really a simply question to answer.
> On one hand having DCs well protected, not in any way on the edge,
> is a general, sane paractice. On the other hand "making requests"
> is not something that would expose anything more than would using
> a forwarder to make those requests. Now, if by "making requests"
> you also were meaning answering queries, then my response is
> emphatically that you should not allow queries from outside of your
> infrastructure.
> If your DC based DNS has a path to the internet for Tcp/Udp 53
> and is also configured not to answer on the interface providing that
> path then whether it makes request via a forwarder or by working the
> DNS servers involved in answering the query is mostly a matter of
> offloading work. However, if your infrastructure does not have that
> path to the internet isolated on an interface of the DC then you
> cannot configure the DNS service to not answer queries on that
> interface, which potentially (depending on firewall config and/or
> NAT config) could expose your internal zone information.
> Finally, IMO much depends on the size of the organization, and
> whether it makes sense to host one's own public DNS presence.
> If so, that normally means that you have a public DNS server,
> configured to not accept recursive queries, placed in the DMZ or
> a screened network with Ucp/Tcp 53 accessible to the world. Such
> a server would be a good choice for use as forwarder to the internal
> DC based DNS services IF it were not configured to reject recursive
> queries. If the public DNS presence is relatively static zone of not
> that many resource records it can make most sense to offload the
> hosting of that to a network provider. For reasons similar to those
> already used, the DNS of the network provider also often make a
> good choice as forwarders.
>
> Do you have any link or reference for what you mentioned as
>> I have read about different DNS responses attacks that can help an
>> attacker to take control of the DC via an incorrect DNS response
>> (buffer overflow etc.).
> since I have not really encountered what this might be speaking of.
>
> In all events, there are only a couple guiding principals.
> One is that as a best practice there is no need for, hence no reason
> for, the internal AD supporting zone(s) to be visible to the world.
> That just presents unneed exposure, which MIGHT mean unneeded,
> added risk - it does certainly give a means for external people to map
> key aspects of the internal infrastructure while their access is still
> only external and it also MAY give them a way to DoS the DNS service
> by recursive query saturation.
> An outcome from this is that a DC that is not multihomed cannot be
> configured to use external DNS servers (whether for direct working
> of queries or forwarding) and also keep the internal zones fully
> inaccessible (that is, cannot be so configured on the DC itself - such
> protection must be defined elsewhere - firewall, nat, proxy).
>
> --
> Roger Abell
> Microsoft MVP (Windows Server : Security)
>
>
| 
XML site map