Although DNS servers perform
functions that are intrinsically benign, the possibility of their
compromise does pose a significant threat to your network security. Part
of the design process for your name resolution strategy is keeping your
DNS servers, and the information they contain, safe from intrusion by
potential predators.
Determining DNS Security Threats
DNS name resolution
is an essential part of TCP/IP networking. Both Internet and Active
Directory communications rely on the ability of DNS servers to supply
clients with the IP addresses they need. There are two primary security
threats associated with DNS: interruption of service and compromise of
DNS data. As part of your name resolution strategy, you must evaluate
the threats to your DNS servers and the possible consequences, and then
take steps to protect the servers without compromising their
functionality.
Some potential threats to your DNS servers are as follows:
Denial-of-service (DoS) attacks
Flooding a DNS server with huge numbers of recursive queries can
eventually force the processor to 100 percent usage, preventing the
server from processing name resolution requests from actual clients.
This type of attack does not require a great deal of skill from the
attacker and can be extremely effective in shutting down a network. The
inability to resolve DNS names can prevent users from accessing Internet
resources and even from logging on to Active Directory servers.
Footprinting
Intruders gather information about a network’s infrastructure by
intercepting DNS data, usually to identify targets. By capturing DNS
traffic, intruders can learn the domain names, host names, and IP
addresses you are using on your network. This information frequently
discloses the functions of specific computers on the network, enabling
the intruder to decide which ones are worth attacking in other ways.
IP spoofing Intruders
can use a legitimate IP address (often obtained through footprinting)
to gain access to network services or to send damaging packets to
network computers. Spoofing can enable packets to get through filters
that are designed to block traffic from unauthorized IP addresses. Once
granted access to computers and services by using this technique, the
attacker can cause a great deal of damage.
Redirection
In this type of attack, an intruder causes a DNS server to forward name
resolution request messages to an incorrect server that is under the
attacker’s control. The attacker usually accomplishes this by corrupting
the DNS cache in a server that is using unsecured dynamic updates.
Securing DNS
A number of techniques
can protect your DNS servers and your namespace data from attack, and it
is up to you to locate the threats to your servers and to determine
what steps to take to protect against them. As with most security
problems, it is just as possible to err on the side of caution as it is
to be negligent. As an example of negligence, not implementing security
measures can leave your DNS servers open to access from the Internet and
can allow them to exchange zone data and dynamic updates with any other
computer. This leaves the servers vulnerable to any of the attacks
described in the previous section.
At the opposite extreme,
you can close off your network from the outside world by denying all
Internet access, creating an internal root, using Active Directory
domain controllers for your DNS servers, limiting administrative access
to the DNS servers, and encrypting all DNS communications. These
measures secure the DNS servers from most forms of attack, but they also
compromise the functionality of the network by preventing users from
accessing the Internet. There certainly are times when extreme measures
like these are warranted, but it is up to you to decide what level of
security your network requires.
Some of the
security measures you can use to protect your DNS servers from external
(and even internal) intrusion are described in the following sections.
Providing Redundant DNS Services
When you use
registered domain names on your network, your DNS servers must be
accessible from the Internet, and they are therefore vulnerable to DoS
attacks and other forms of intrusion. To prevent intruders from
crippling your network by these attacks, it is a good idea to use
multiple DNS servers to provide redundant services to your users. This
type of protection can be as simple as configuring your DNS clients to
use your ISP’s DNS server when yours is unavailable or unresponsive.
This way, your users can continue to access Internet services even when
someone disables your own DNS server by a DoS attack. Unless the
intruder attacks both your DNS server and the ISP’s DNS server, name
resolution services continue to function properly.
Planning
You
can also deploy your own redundant DNS servers to provide even more
protection. Placing a second server on another subnet, or at another
site, can give your users a fallback in case an attack takes place on
one of the servers. In addition, running your own servers enables you to
provide redundant name resolution services for Active Directory, which
your ISP’s DNS servers probably cannot do. |
Deploying multiple DNS
servers is also a way to protect your namespace from footprinting.
Install one server on your perimeter network, for Internet name
resolution, and another on your internal network, to host your private
namespace and provide internal name resolution services. Then configure
the internal DNS server to forward all Internet name resolution requests
to the external DNS server. This way, no computers on the Internet
communicate directly with your internal DNS server, making it less
vulnerable to all kinds of attacks.
Limiting DNS Interface Access
Another way
of securing DNS servers against unauthorized access from the Internet is
to limit the network interfaces over which the server can receive name
resolution requests. If you have configured your DNS server computer
with multiple IP addresses, you can click the Interfaces tab in the
server’s Properties dialog box in the DNS console and specify the IP
addresses that DNS clients can use to contact the server. (See Figure 1.)
For example, if a server is connected to both an internal network and
to the Internet, you can prevent the server from receiving name
resolution requests that originate on the Internet.
Securing Zone Replication
Although
it is possible to footprint a namespace by capturing name resolution
traffic, a more efficient method (for the attacker) is to intercept zone
replication traffic. By capturing zone transfer packets, for example,
an intruder can get a complete picture of a zone and all its domains and
hosts at once.
The best and simplest
way to secure zone replication traffic is to deploy all your DNS servers
on your domain controllers and store all your zones in Active
Directory. Active Directory is then responsible for performing all zone
replication. All Active Directory domain controllers perform a mutual
authentication procedure before they exchange data, so a potential
intruder cannot use IP spoofing to impersonate a domain controller. In
addition, Active Directory encrypts all traffic, which prevents anyone
capturing the packets from reading the data they contain. Finally,
access to the domain controllers themselves is restricted by the
policies you already have in place to protect your other Active
Directory data.
Planning
If
you cannot use Active Directory–integrated zones on your network, you
must create standard file-based zones and use zone transfers to
replicate the DNS namespace data. Although zone transfers are inherently
less secure than Active Directory replication, there are still
techniques you can use to prevent intruders from intercepting your DNS
data. |
One way to protect
zone transfer data is to specify the IP addresses of the DNS servers
that you allow to participate in zone transfers. If you do not do this, a
potential intruder can simply install a DNS server, create a secondary
zone, and request a zone transfer from your primary zone. The intruder
then has a complete copy of your zone and all the information in it.
To limit zone transfers on a
Windows Server 2003 DNS server, open the DNS console, display the
Properties dialog box for a primary zone, and then click the Zone
Transfers tab to display the dialog box shown in Figure 2.
Select the Allow Zone Transfers check box, and then choose either the
Only To Servers Listed On The Name Servers Tab or Only To The Following
Servers option. You can then specify, in either the IP Address text box
or the Name Servers tab, the IP addresses of the DNS servers that
contain your secondary zones.
Although
the preceding technique can prevent unauthorized DNS servers from
receiving zone transfers, it does not protect the packets containing the
zone transfer data themselves. An intruder with a protocol analyzer,
such as the Microsoft Network Monitor application, can capture the zone
transfer traffic and read the data inside the packets. To prevent this,
you can configure your DNS servers to encrypt their traffic using the
Internet Protocol Security extensions (IPSec) or virtual private
networking.
Preventing Cache Corruption
Potential attackers might
try to load a DNS server’s name cache with incorrect information in an
effort to redirect client connections to other servers and gather
information from the clients. The Windows Server 2003 DNS server
includes a feature that helps to prevent corruption of the cache. In a
DNS server’s Properties dialog box, click the Advanced tab (shown in Figure 3) and then select the Secure Cache Against Pollution check box under Server Options.
Activating
this feature prevents the server from caching unrelated resource
records included in reply messages. For example, if a DNS server sends a
query to an Internet server requesting the resolution of a name in the
adatum.com domain, it would normally cache all the resource records
supplied by the Internet server, no matter what information they
contained. If you activate the Secure Cache Against Pollution option,
however, the DNS server caches only resource records for names in the
adatum.com domain. The server ignores all records for names in other
domains.
Using Secure Dynamic Update
As DNS was
originally designed, administrators had to create all resource records
by hand, typing the host name of each computer and its IP address or
other information. This eventually became a problem as the use of
automatic IP addressing solutions such as the Dynamic Host Configuration
Protocol (DHCP) became more prevalent. DHCP is designed to
automatically supply IP addresses and other TCP/IP configuration
parameters to computers, which means that it is possible for a
computer’s IP address to change periodically. Because it would be
impractical for network administrators to keep track of these changes
and modify the appropriate resource records manually, the developers of
DNS created a new standard, referred to as dynamic update.
Dynamic update enables
DNS clients on the network to send messages to their DNS servers during
system startup. These messages contain the IP addresses the DHCP server
has assigned to the clients, and this information is used by the DNS
server to update its resource records with the new information.
Although
dynamic update saves DNS administrators a lot of work, it also leaves
the DNS servers vulnerable to serious forms of attack. An intruder could
create a false dynamic update message and send it to your network’s DNS
server. The message could state that your company’s Internet Web server
has changed its IP address, forcing your DNS server to add a
counterfeit address to the resource record for the Web server’s host
name. From then on, Internet traffic intended for your company Web
server would be redirected to a server under the attacker’s control.
To prevent this
from occurring, you should create Active Directory–integrated zones
whenever possible and configure them to accept only secure dynamic
updates. The procedure is to display the zone’s Properties dialog box,
click the General tab, and from the Dynamic Updates drop-down list,
select Secure Only. (See Figure 4.)
Using Standard Security Measures
In
addition to these specialized DNS security measures, you can also
protect your Windows Server 2003 DNS servers from attack using the same
techniques you use for any computer on your network. Limiting physical
access to the server and using permissions to control administrative
access are basics that you should include in the case of a DNS server,
because intruders can come from inside the organization as well as from
outside. You can also use the packet filtering capabilities of your
firewall to control access to the computer itself and to Transmission
Control Protocol (TCP) and User Datagram Protocol (UDP) port number 53,
which is the well-known port number for DNS.
