The Domain Name System (DNS) has been the target of many types of attacks in recent years. Authoritative DNS servers are exposed to the Internet and generally allow queries from all IP addresses. However, DNS resolvers are typically internal to an organization and allow queries only from the internal clients they serve. DNS resolvers that allow queries from all IP addresses and are exposed to the Internet can be attacked and used to conduct Denial of Service (DoS) attacks on behalf of the hacker. Following is a picture of how an attack on an open DNS resolver could take place and result in a DNS traffic amplification attack.
Step 1: The attacker places a very large DNS record on an authoritative DNS server that is accessible from the Internet. This record also has a very long Time-To-Live (TTL) value. The attacker could also send a query for a well-known large response such as a query for ANY from isc.org.
Step 2: The attacker sends a spoofed DNS query for this DNS record to the open DNS resolver. The open DNS resolver is not checking the source IP address of the query so it accepts the query and performs the DNS recursive lookup on the behalf of the client.
Step 3: The open DNS resolver fetches the large DNS record and caches that entry for the very long TTL duration. At this point, the attacker can remove the DNS record from the authoritative DNS server.
Step 4: The attacker continues to send small spoofed queries to the open DNS resolver for that cached record. Those queries have a source address of the victim’s IP address. The open DNS resolver fails to check the query IP address and sends the large DNS cached record to the victim’s IP address. The attack continues as long as the attacker sends the fake queries.
A crafty attacker could achieve up to an 80:1 amplification potential by taking advantage of EDNS0’s (RFC 2671) larger response packet size. An army of attackers leveraging a set of open DNS resolvers could generate gigabits of DoS traffic. In fact, the largest DNS DDoS attack targeting Spamhaus in March of 2013 generated a whopping 300Gbps.
These types of attacks and how to protect against them are well documented in IETF RFC 5358, Preventing Use of Recursive Nameservers in Reflector Attacks.
Do You Have an Open DNS Resolver?
We first need to figure out if we are vulnerable to such type of attack. The first step would be to assess if any of our DNS resolvers are connected to the Internet or are reachable from the Internet.
In most enterprise environments, the DNS resolvers are on the internal network and provide recursive DNS query support to internal hosts. However, today’s networks aren’t so clear cut with all resources safely tucked away inside the internal IT environment behind a tightened down firewall. Today’s networks are turned inside out so that external mobile workers, partners, and customers can reach the services in the data center. Cloud-based services also virtualize the location of services that historically were located within the internal server farms.
Another way to determine if you have an open DNS resolver that is susceptible to this type of attack is that you are currently experiencing very high DNS traffic volumes. As Thomas Jefferson might have said, “Eternal vigilance is the price of liberty.” Therefore, we need to be aware of how our IT systems are behaving.
If your DNS resolvers are exposed to the Internet and reachable by an attacker as described above, then you will definitely need to take steps to lock it down and prevent it from being used for a DoS attack.
Internet Community Support
There are several sources of information on this issue publically available.
The Open Resolver Project is attempting to document the list of DNS servers that accept recursive queries from the Internet. They have a detailed breakdown of the number of DNS servers that are misconfigured or exhibiting specific behaviors. Their data shows that there are over 20 million open DNS resolvers on the Internet.
If you don’t know what DNS Resolver you are using, you can open up a browser and go to http://myresolver.info and it will output your public IP address and what DNS recursive resolver you seem to be using.
US-CERT has provided guidance for U.S. federal government organizations to help them secure their DNS servers from behaving as open recursive DNS resolvers. This helpful guide goes into how to secure many of the popular DNS services.
Team Cymru also has a page dedicated to this security issue and they have a good 5-minute video that covers DNS Amplification Attacks. Team Cymru also provides a secure BIND configuration template that compiles many DNS security best practices into one document.
The DNS Measurement Factory has a page dedicated to open DNS resolvers and how they perform testing along these lines. This site contains a good paper by Duane Wessels on “Is Your Caching Resolver Polluting the Internet?” The DNS Measurement Factory also provides several resources and tools to test your DNS server externally to your organization.
Preventing Open DNS Resolver Vulnerabilities
There are several ways to prevent these types of attacks if your organization has a DNS resolver that is reachable from the Internet or other untrusted networks.
One way to prevent these attacks is to restrict your DNS resolvers to only accept queries from specific IP addresses. For example, if the DNS resolver is on the internal network and only services internal clients, then it should be configured to use a filter to only those specific IP address ranges. In a typical enterprise network, this would likely be the private RFC 1918 IPv4 address space or your organization’s assigned global IPv6 address block.
If you are using a DNS resolver that straddles the internal and external network using two different physical or logical network interfaces, then you could also configure the DNS resolver to only allow queries on the internal interface from internal hosts. It could be configures such that its external interface would drop all DNS queries.
Another method of helping prevent these types of DoS attacks is to use Best Current Practice (BCP) #38 network ingress filtering on your network perimeter. If your DNS resolver is on your DMZ, then you can use filters on an external Internet router or firewall to prevent clients on the Internet from querying the DNS resolver. Regardless of the DNS server topology, BCP38 ingress/egress filtering is strongly recommended for the many other security benefits it provides.
Securing BIND 9.X DNS Servers
If your organizations uses the Internet Systems Consortium (ISC) implementation of BIND for your DNS servers, then there are simple steps you can take to prevent these types of attacks. ISC has a page titled “Is Your Open DNS Resolver Part of a Criminal Conspiracy?” which contains several good links. Following are the configuration settings to help secure your ISC BIND 9.x DNS servers:
BIND version 9.9.4 now includes Response Rate Limiting (RRL), which limits the number of responses returned by a DNS resolver to help mitigate these DNS amplification attacks. If you are running a new version of BIND (and you should always keep your software updated and patches), then you may already have this feature. To enable it, you would need to make this type of configuration setting in your /etc/named.conf file.
options {
rate-limit {
responses-per-second 5;
};
};
If you have an authoritative DNS server exposed to the Internet, then you want it to have recursion disabled. Here is the configuration settings you need to make in the /etc/named.conf file.
options {
recursion no;
additional-from-cache no;
};
If you have an internal caching DNS Resolver running BIND, then the following configuration settings in the /etc/named.conf file can help you secure these servers. This configuration uses BIND views to allow queries only from the networks in the “allowed” ACL and denies queries outside that view.
acl "allowed" {
192.168.0.0/16;
};
options {
recursion no;
additional-from-cache no;
allow-query { none; };
};
view "allowed" in {
match-clients { allowed; };
allow-query { allowed; };
recursion yes;
additional-from-cache yes;
};
Starting in BIND version 9.4, ISC the configuration options for controlling queries and recursion. Now there are allow-recursion, allow-query, and allow-query-cache settings in the /etc/named.conf file. BIND 9.4 also introduced the settings allow-query-on, allow-recursion-on, allow-query-cache-on to specify the network interface used for DNS queries. For newer BIND caching DNS Resolvers, the following configuration would help secure against open DNS resolver attacks.
acl "allowed" {
192.168.0.0/16;
localhost;
localnets;
};
options {
allow-query { any; };
allow-recursion { allowed; };
allow-query-cache { allowed; };
};
Restricting DNS Queries and Recursion on Infoblox
Infoblox DNS servers have always had a focus on security. If you are lucky enough to have Infoblox DNS appliances with Infoblox Advanced DNS Protection then you have many DNS attack mitigation options at your fingertips. Regardless, you will still want to make sure that your Infoblox DNS servers are configured to only allow query access from the systems that you require. Here are the steps to restrict queries and deny recursion to an Infoblox Grid member:
- Open up the Infoblox management GUI on your Grid Master.
- Navigate to Members/Servers.
- Click the box next to the DNS server you wish to modify.
- Down in the lower left pane click “Grid DNS Properties”.
- In the Basic mode, click on the right menu pane on “Queries”.
- You will see information on allowing queries from specific IP addresses on top.
- You can select None, a Named ACL, or configure a set of ACEs.
- On the bottom of that window you will see a checkbox labeled “Allow recursion”.
- You can disable recursion by unchecking that box.
- Or you can check that box, but then in the “Allow recursive queries from” table list the IP addresses of your internal networks that you want recursion to function.
- You can also configure recursion to be allows from None, a Named ACL, or configure a set of ACEs.
Infoblox also provides “A Checklist for Guarding Against Cache Poisoning Attacks” authored by Cricket Liu, and point #5 covers how to restrict recursion as much as possible.
There are also other Infoblox Community blogs on this topic, like those written by Renuka Nadkarni (part 1, part 2), that give good advice to Infoblox administrators.
There are also other helpful Infoblox guides available such as the Infoblox FAQ. Fred Farkle wrote a short-but-sweet blog on “How do I keep my authoritative public nameserver from answering any queries other than for the domains it is authoritative for?” that tells you how to disable recursion when using DNS Views.
Summary
Each of us who is responsible for maintaining an IT infrastructure should configure our systems using industry best practices. We should strive to be “good Internet citizens” and make sure that we are not contributing to Internet security issues. Protecting our external authoritative DNS servers is easy and there is no downside to securing our DNS infrastructure. We should take a few moments and secure our DNS Resolvers to protect against the widespread DoS attacks against Open DNS Resolvers and do our part to help make the Internet a safer place.
This post originally appeared on the Infoblox blog at https://community.infoblox.com/blogs/2014/05/13/finding-and-fixing-open-dns-resolvers.
