Two weeks ago we took a look at what you need to do to prepare for a Windows DNS deployment, and how to blend Unix-based DNS with your Active Directory (AD) structure. This week we’re back to consider several threats you need to be aware of, and steps you need to take to protect your Windows-based DNS servers and network.
Footprinting, for instance, is a case where an attacker obtains information about your DNS zones and your network via zone transfer.
Zone transfers are preventable at the firewall and routers on the perimeter of your network. DNS client queries are transmitted on UDP port 53, and TCP port 53 is used for zone transfers. Zone transfers outside of the protected network (outside your firewall) via TCP port 53 should be avoided.
Most organizations have internet-facing systems with both internal and external DNS servers to service each zone. In this case, incoming UDP and TCP port 53 should be blocked at the internal and external firewall, and DMZ routers. Allow TCP port 53 only through the routers and firewall which connect the internal and external DNS servers. To resolve queries for external names made by internal hosts, the internal DNS servers should forward queries out to the external DNS servers. External DNS servers in front of the firewall should be configured with root hints pointing to the root servers for the Internet. External hosts should use only the external DNS servers for Internet name resolution.
Even though Windows Server 2003 DNS only performs zone transfers with servers that are listed in the zone’s Name Server (NS) resource records, you should still set your Windows DNS server to only allow zone transfers with specific IP addresses. Only allow reverse lookup zones to external DNS servers if necessary. Network Address Translation (NAT) (define) is a very good strategy to use on many networks and can be implemented on the DMZ where the DNS server is situated. NATing adds further protection from hackers and intruders as is obfuscates the issue by translating IP addresses to predetermined address ranges. Restricting zone transfers to only authorized or known servers also helps prevent the injection of unauthorized data into your DNS zone files by an attacker. If an attacker can’t capture your zone data from a zone transfer, he won’t be able to determine the makeup of your network and do ugly things such as spoofing IP addresses to make them appear to have come from an internal host.
(Click for a larger image)
Another option, and undoubtedly the one Microsoft would prefer you use, is to use only AD-integrated DNS zones, as opposed to Standard DNS zones. AD-integrated DNS servers will only participate in zone replication with other AD-integrated DNS servers. Also, all DNS servers hosting AD-integrated zones must be registered in AD before they’ll even be functional, and replication traffic between AD-integrated DNS servers is encrypted.
DNS Cache Poisoningis a situation in which an attacker is able to predict the DNS sequence numbers in a DNS conversation between server and client, and then insert bogus data into the data stream. This can be used by the attacker in a number of ways including redirecting a popular search engine to a pop-up ad site, or redirecting a user to a bogus bank website to gain access to account passwords.
Windows Server 2003 DNS servers use a secure response option that eliminates the addition of unrelated resource records that are included in a referral answer to the cache. Typically, a DNS server caches any names in referral answers, expediting the resolution of subsequent DNS queries. However, when the Secure Cache Against Pollution option is enabled, which it is by default on Windows 2003 DNS servers, the server can determine whether the referred name is polluting or insecure and discard it. The server determines whether to cache the name offered in the referral depending on whether it is part of the exact DNS domain tree for which the original name query was made. As an example, a query made for marketing.companysix.com with a referral answer of companyeight.netwould not be cached.
(Click for a larger image)
If you have BIND-based DNS servers in your environment, you should update to BIND 9, which helps alleviate some of the more commonly used methods of DNS cache poisoning. It doesn’t prevent them, however it does contain some improvements to the BIND protocol that make cache poisoning more difficult.
Denial of Service (DoS) attacks can occur when an attacker attempts to obstruct the availability of network services by flooding one or more DNS servers in the network with recursive queries or zone transfer requests. As a DNS server is flooded with queries, its resources will eventually reach their maximum and the DNS Server service will become unavailable. Blocking UDP and TCP port 53 at internal and external firewalls and DMZ routers should help alleviate this, as well as only allowing DNS-related traffic to and from authorized servers. There is a feature built into Windows 200x DNS called zone transfer metering. When a zone transfer occurs within the server, the server won’t allow another zone transfer to happen for a period of time, because it is possible that a denial of service attack could be perpetrated on the server by flooding it with requests for zone transfers and queries causing the to be locked and preventing it from being able to do updates or answer queries efficiently – or at all.
Client security and Dynamic updates: Dynamic updates are required for Active Directory-integrated zones. For highest protection, AD should be configured to allow secure dynamic updates or dynamic updates from DHCP instead of DNS clients wherever possible, to increase security of the DNS zone data. When using Secure Dynamic Updates, the DNS zone information is stored in Active Directory and thus is protected using Active Directory security features. When a zone has been configured as an Active Directory-integrated zone, Access Control List (ACL) entries can be used to specify which users, computers, and groups can make changes to a zone or a specific record. This restricts your DNS server to only accept new registrations from computers that have a computer account in Active Directory, and to only accept updates from the computer that registered the DNS record initially. It also forces the DHCP server and/or client PC’s to encrypt the information.
DNS Security (DNSSEC, RFC2535) is a public key infrastructure (PKI) (define) based system in which authentication and data integrity can be provided to DNS resolvers. Digital signatures are used and encrypted with private keys. These digital signatures can then be authenticated by DNSSEC-aware resolvers by using the corresponding public key. The required digital signature and public keys are added to the DNS zone in the form of resource records.
The public key is stored in the KEY RR (Resource Record), and the digital signature is stored in the SIG RR. The KEY RR must be supplied to the DNS resolver before it can successfully authenticate the SIG RR. DNSSEC also introduces one additional RR, the NXT RR, which is used to cryptographically assure the resolver that a particular RR does not exist in the zone.
DNSSEC is only partially supported in Windows Server 2003 DNS, providing basic support as specified in RFC 2535. A Windows Server 2003 DNS server can only operate as a secondary to a BIND server that fully supports DNSSEC. The support is partial because DNS in Windows Server 2003 does not provide any means to sign or verify the digital signatures. In addition, the Windows Server 2003 DNS resolver does not validate any of the DNSSEC data that is returned as a result of queries.
All of this by no means covers everything you need to know about installing and hardening your Windows-based DNS servers, but it should be a good start in giving you a better idea of the key things you need to do to protect your servers and your network. Grab some aspirin, and good luck!