| Executive Summary: DNS has some limitations but there’s no reason for it to be the weakest link in your organization’s security. An incorrectly configured and neglected DNS server can be a significant security problem. DNS services, as providers of network information, will always be a target for reconnaissance and information gathering, but careful planning and vigilance will minimize the risk of malicious hackers using your own servers against you. There’s much you can do to build a solid and secure DNS infrastructure on your network, whether you're using Microsoft DNS or BIND. |
The DNS protocol is peculiar. It’s one of the oldest, most universally used, and most crucial of all networking protocols, but it’s still the source of many network security problems. DNS has some fundamental limitations, but there’s no reason for it to be the weakest link in your organization’s security.
Perhaps it’s DNS’s apparent simplicity that breeds complacency toward DNS security. It’s easy to set up a DNS server and forget about it, but an incorrectly configured and neglected DNS server can be a significant security problem. DNS services, as providers of network information, will always be targets for reconnaissance and information gathering, but careful planning and vigilance will minimize the risk of malicious hackers using your own servers against you. You can do much to build a solid and secure DNS infrastructure on your network, whether you're using Microsoft DNS or BIND. (For information about the security differences between BIND and Microsoft DNS, see the sidebar “Microsoft DNS vs. BIND.” )
DNS Server Attacks
To secure a DNS server, you need to understand how
others might exploit it. The most common threats are
Denial of Service (DoS) attacks, tampering with DNS
records, and information gathering. DoS attacks are
probably the most common threat because they’re
remarkably easy to pull off, thanks to the large number of
incorrectly configured DNS servers on the Internet. DNS
servers are often the launching points for DoS attacks,
wherein an attacker uses a DNS server that allows
recursion to pummel another server with packets. This
kind of attack starves the target server of resources and
prevents legitimate users from accessing it.
DNS tampering, which takes several forms, is less common but still a threat. One common method of DNS tampering is cache poisoning, in which an attacker injects fake records into a DNS server’s cache. Other methods of modifying DNS records include forged packets, man-in-the-middle attacks, and rogue DNS servers. In addition to modifying records, attackers use DNS servers for information gathering through DNS server mining, zone transfers, and DNS packet interception. Properly configured DNS servers can greatly limit your exposure to all these tactics.
Isolate DNS Functions
The first step to preventing attacks on DNS
servers is to plan your network infrastructure
so that you isolate DNS server functions.
The term DNS server describes two
very different functions—a fact that can lead
to confusion during configuration. A DNS
server can be an advertiser of information,
or it can be a gatherer (resolver) of information
stored elsewhere. To maximize security,
it should never perform both functions
simultaneously.
Your DNS advertiser stores and publishes authoritative records about a domain that you control. The DNS advertiser could be a public DNS server, which tells outsiders how to reach your website or mail servers, or an internal Active Directory DNS server, which tells clients where to find resources such as domain controllers. In contrast, your DNS resolver accepts DNS requests from within your organization and contacts outside DNS servers as necessary to locate host information. DNS resolvers can cache records to speed up future lookups and can act as forwarders to redirect client lookups to different DNS servers.
Most DNS servers work fine performing both functions at once, and organizations commonly have several DNS servers that perform both. This practice, however, is the primary reason so many DNS servers are vulnerable. You should have at least three distinct server roles on your network: Internet-facing DNS advertisers for publicly available servers, private DNS advertisers for AD and other internal DNS records, and DNS resolvers to perform lookups, caching, and forwarding for internal clients.
You should split these roles to improve performance and limit exposure to cache poisoning and DoS attacks. To further mitigate DoS attacks, you should have at least two servers in each role. Although many companies use a single DNS server for all roles, isolating server roles is always the best practice, because even if a configuration is not vulnerable now, it could become vulnerable in the future.
Carefully securing all DNS server roles is important, but I want to focus on the most crucial role: the Internet-facing advertisers.
Public DNS Advertisers
Your Internet-facing DNS advertisers are the
only DNS servers visible outside your network,
so you need to limit the information
stored on them; otherwise, attackers might
exploit them. Public advertisers should hold
only public host records and should publish
records only for servers accessible from the
Internet—for example, web, mail, and FTP
servers. Public advertisers should contain
only public IP addresses and other public
records such as Sender Policy Framework
records and basic contact information. If
any of your network adaptors point to your
public DNS servers, chances are you have a
problem to fix.
Although controlling information is important, your primary strategy for securing public advertisers should be to make sure they respond only to requests for the records they hold. They should never perform DNS lookups or look up other information on behalf of someone requesting records. Limiting responses will eliminate cache poisoning and prevent others from using your DNS server as a reflector in a DoS attack. Several steps are necessary in both BIND and Microsoft DNS to secure public advertisers.
Disable Recursion
Recursion allows a DNS server to track
down a host record on behalf of another
server. The problem with recursion is that
in the process of performing lookups for
others, a DNS server might be vulnerable
to cache poisoning. Furthermore, attackers
often use recursive DNS servers as part of a
distributed DoS attack.
Attackers perform DoS attacks by creating large DNS records on servers that they control, then sending thousands of requests to recursive DNS servers all over the Internet. The requests are spoofed to look as if they come from a single IP address, so each DNS server will grab the record, cache it, and return it to the spoofed IP address. By repeating this process, the attacker can flood a target server with packets. The only way to prevent the flood would be to configure every public DNS server on the Internet to block recursive queries. Fixing the estimated half-million DNS servers that allow recursion is impossible, but you can do your part by fixing your own servers.
To disable recursion with Microsoft DNS, open the DNS Management Console, rightclick the computer name in the left pane, and select Properties. Click the Advanced tab and select the Disable recursion check box, as Figure 1 shows. Also, confirm that the Secure cache against pollution option is selected.
Continue to page 2
If you use BIND, you can disable recursion by adding the following to the options section in named.conf:
Options \{
recursion no;
\};
Note that with BIND, you can use an allowrecursion ACL to permit recursion only from trusted IP addresses. Although this might be the only possible solution in some configurations, the best protection is to prevent all recursion on public DNS servers.
Limit Zone Transfers
A surprisingly common DNS server mistake
is allowing all hosts to perform zone transfers
and allowing all records for a zone to
be returned. Zone transfers let DNS servers
share information, but you should be careful
to limit which hosts can request them. If you
don’t normally allow servers to update each other, you can completely disable
zone transfers.
To limit zone transfers with Microsoft DNS, open the DNS Management Console, rightclick the domain you want to configure, click Properties, then access the Zone Transfers tab. If you want to enable zone transfers, be sure to allow only servers listed on the Name Servers tab or use specific IP addresses. Never allow zone transfers to all servers.
With BIND, you control this setting in named.conf. You can make the setting in either the global options section or individual zone sections. Keep in mind that settings in a zone section override that zone’s global options, so the best way to manage zone transfers is to prevent them globally, then configure individual zones to allow zone-transfer requests only from certain IP addresses. To do so, add to named.conf as follows:
Options \{
recursion no;
fetch-glue no;
allow-transfer \{ none; \};
\};
zone "example.com" in\{
...
allow-transfer
( 192.168.0.15; );
\};
Reduce Exposure
To prevent abuse, it’s important to limit all
network services to specific ports and IP
addresses. You should always use a packet
filter, such as a firewall or router, to limit
access to your DNS servers, and you should
configure limitations on the servers themselves.
To configure Microsoft DNS to listen
only on specific IP addresses, you can open
the DNS Management Console, right-click
the computer name, select Properties, and
select the Interfaces tab. You can then enter
specific IP addresses you want to listen on, as Figure 2 shows.
With BIND, you can set the listening IP address as a global option or a zone option in named.conf as follows:
Options \{
recursion no;
fetch-glue no;
allow-transfer \{ none; \};
listen-on \{192.168.0.8; \};
\};
With Microsoft DNS, it’s possible to manage a remote DNS server using the remote procedure call (RPC) protocol. If you don’t use this feature, you should disable RPC to reduce your attack surface. To do so, you must edit the server’s registry. Using Regedit, locate HKEY_LOCAL_MACHINE\SYSTEM CurrentControlSet\Services\DNS\Parameters, and create a DWORD value named RpcProtocol. Set this value to 0, and restart the DNS server for the setting to take effect.
You Can Do More
At this point, your DNS server won’t allow
recursive DNS requests from others, won’t
attempt to answer queries outside its zones,
will permit zone transfers only to trusted
hosts, and will listen only on the IP addresses
you specified. If it contains only public DNS
records, the server is now secure enough to be
a public DNS advertiser. With prudent firewall
configuration, careful patch management,
and other security best practices in place, you
can be confident that your DNS server isn’t a
threat to your network or others.
However, you can do more. Using IPsec between trusted hosts and implementing the DNS Security Extensions (DNSSEC) and Transaction Signature extensions can further increase the integrity and confidentiality of your DNS traffic. Careful server hardening will prevent other types of attacks on your DNS server. Finally, a good networkmonitoring system can warn you of impending attacks.