Security Advisor

DNS Security Basics

Your DNS is a sweet spot for hackers who want to compromise your network; learn to protect it.

While it may seem that computer names and their corresponding IP addresses wouldn't be of much value to hackers, attacking a DNS server can be a hacker's first step toward compromising an entire network. The Domain Name System (DNS) is the standard for resolving computer names on the Internet to IP addresses. It has also become the primary method for name resolution in corporate networks.

That can be a potentially dangerous combination. All too often network administrators neglect DNS security. Here are some DNS security basics you should put into effect:

Split Personality
When Microsoft adopted DNS as the primary name resolution method for Windows -- instead of using the older WINS -- it was an important step toward making networks work together well and making them easier to use. However, by using the same name resolution method for corporate networks that the Internet uses, internal and external name resolutions are often combined.

Internet users find your company's Web site by going to www.companyname.com. Your internal computers also have a DNS name that would be something like computer.yourcompany.com, or another DNS name that's in the same or at least a similar zone. This can result in internal computer names and addresses being accessible on the DNS server that resolves names from the Internet. Good security practices dictate that you separate internal and external name resolution. This is known as a split DNS design.

A network penetration test I did a couple of years ago offers a good illustration of how dangerous it can be to not maintain a split DNS. My task was to find ways an intruder could break into a small corporate network. All the information I had to start out with was the company's domain name.

My first step was to find an externally accessible DNS server for this company and get all records for the DNS zone using a zone transfer. To my surprise, the zone data included the names and IP addresses of all their internal computers -- even domain controllers, application servers and client computers.

Using this information, I was able to create a complete map of the corporate network. Once I had done this, I noticed the company was using a firewall between their internal network and the Internet. However, one of their application servers had two IP addresses, and one of them was a public address. That meant this server was simultaneously connected to the internal network and the Internet, without any firewall protection in between.

I connected to this server to bypass the firewall, and was able to exploit a vulnerability on the server to gain administrative privileges. Then I used the compromised server to get further into the network. Within 15 minutes, I had full Domain Admin privileges.

At this point, I contacted the company's owner and explained why he now had some extremely urgent security projects on his hands. My success in breaking into the network was due to multiple security lapses. Without the initial information gained from DNS, though, I might not have known where to start.

The best way to keep internal information out of your public DNS is to eliminate any replication between the internal and external DNS. Keep the two systems completely separate. Most likely, you only have a handful of public names you need to administer. You should be able to manually maintain the external DNS entries for your Web and mail servers. Then you can use Windows' nifty dynamic DNS features for all the computers within your firewall.

You should also take an additional step when designing your internal DNS. Never use your public DNS zone name for internal computers. For example, if your domain name is redmondmag.com, use something like internal.redmondmag.com for your internal DNS zone.

Selective Transfer
DNS creates redundancy and load distribution using a system of primary and secondary servers. Normally there's a primary server for each DNS zone. All changes to the DNS entries are made on this server and then transferred to secondary servers. Both types of servers can answer DNS queries, but all changes originate from the primary server. There are certain exceptions to this, like Microsoft's Active Directory-integrated DNS, which uses a system of multiple primary servers that replicate any modifications between each other.

Figure 1
[Click on image for larger view.]
Figure 1. Make sure to restrict DNS zone transfers.

Still, each of these servers can transfer zone information to other secondary servers. To make this work, you need to configure the primary servers to let secondary servers retrieve the zone data. You should be very careful to configure any primary DNS server to only allow such zone transfers to your secondary servers and not just any computer.

There are a number of tools available to request a zone data transfer from a DNS server, including the nslookup tool that's included in Windows. I've used zone transfers on a number of occasions to get information that proved useful for finding vulnerabilities in corporate networks. In the instance described above, I was able to map out a company's entire network using the information that nslookup gave me.

Another time, I used a zone transfer to get the names and IP addresses of hundreds of computers within a large corporation. Perusing the descriptive names helped me identify several terminal servers on the internal network that were accessible directly from the Internet. This was in clear violation of that company's security policy.

Unrestricted DNS zone transfers won't necessarily let a hacker break into your network, but they can help him find weak points in your defenses. Fortunately, most DNS servers make it relatively easy for you to restrict zone transfers to only legitimate secondary servers. To test whether or not your DNS server is properly configured, start the nslookup utility that's included with Windows on a computer on the Internet. At the nslookup prompt, type server address (where address is the IP address or name of your DNS server). Next type ls -d domain (where domain is the name of your DNS domain) to list all records.

If the server is configured correctly, nslookup will report that the query was refused. If it displays the contents of your DNS zone, you should immediately fix the zone transfer settings on your DNS server (see Figure 1).

Next month I'll cover some more steps you can take to ensure your DNS is as secure as possible.

About the Author

Joern Wettern, Ph.D., MCSE, MCT, Security+, is the owner of Wettern Network Solutions, a consulting and training firm. He has written books and developed training courses on a number of networking and security topics. In addition to helping companies implement network security solutions, he regularly teaches seminars and speaks at conferences worldwide.

comments powered by Disqus

Reader Comments:

Sun, Apr 1, 2007 Donald CA

What about using an name that can not ever accidentally map to the outside world, such as redmondmag.private? When creating a DNS zone for internal use, there is nothing that says you have to use an ICAN approved Top Level Domain suffix.

Using a subset such as internal.redmondmag.com leaves room for a procedure error to register an internal name as just redmondmag.com, allowing the possibility of it getting seen.

While obfuscation is only moderately strong, and should never be used as your only protection, it is a valid layer in the security onion.

Mon, Mar 12, 2007 Anonymous Anonymous

Nice overview.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.