DNS Security Basics
Your DNS is a sweet spot for hackers who want to compromise your network; learn to protect it.
- By Joern Wettern
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
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.
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.
[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
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.
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.