A variant of DNS amplification is gaining favor among the operators of commercial DDoS botnet operators. Additional best practices have been suggested to mitigate the risk of attackers using one's nameserver to target victims.
Analysis
DDoS (distributed denial-of-service) attacks attempt to overwhelm the target by sending an overwhelming amount of traffic to it from host computers -- typically members of a botnet -- that are distributed among various locations, making it difficult or infeasible to block the traffic simply by source address. Various types of traffic are sent: floods of TCP SYN (a "SYN flood" can exhaust available connections on a target), UDP, and ICMP packets. Attacks on services at a higher network layer, especially DNS, HTTP (web), and SMTP (mail) are common as well, and newer techniques have been developed for newer services, such as SIP floods designed to take down VoIP phone services.
DDoS attacks are carried out against web servers and other Internet services every day. Only the most severe attacks or the most prominent targets will make the news. There is an underground economy centered around the commercial operation of botnets designed to carry out DDoS attacks for hire or to extort money from the targets. Anyone who relies on their Internet presence to generate revenue can be a target; however, attackers often go after sites that will garner the least public support, particularly pornography sites (the less mainstream the better) and online gaming sites (gaming, in this sense, being the politically correct term for gambling).
Amplification
When faced with a large target, or a small number of available bots, the DDoS attacker may make use of amplification techniques. These use bot to send a relatively small amount of traffic to other computers that in turn send more traffic towards the actual target. A traditional way of doing this is by sending an ICMP echo request from the spoofed IP address of the intended target to a bystander (or the target's) network's broadcast address. Hosts on the network that receive and respond the request will echo the ICMP payload to the actual target, thereby hitting it with many response packets per each request sent by the attacker. Best practices in network configuration and traffic filtering have largely mitigated risks from this type of amplification. However, a newer type called "DNS amplification" made headlines in 2006. Best practices can help address this as well.
Using DNS to amplify attacks
In early 2006, DNS amplification attacks were studied by Randal Vaughn and Gadi Evron, founding members of the anti-cyber crime group Internet Security Operations Task Force (ISOTF). Their paper presented findings regarding the underlying mechanism of these attacks (spoofed UDP DNS queries), enabling configurations (allowing answers to recursive queries from arbitrary sources), and evasion tactics (packet fragmentation). The paper also studies the effects: attacks resulting in traffic peaks as high as 10 Gbps using more than 140,000 misconfigured (or too loosely configured) publicly available nameservers. Restricting who can perform recursive queries, and queries in general, has mitigated this risk.
DNS amplification without recursion
A new form of DNS amplification is gaining favor with commercial DDoS operators because it does not rely on recursive queries. This new tactic uses a very short query, asking simply for the nameservers for the "." domain. This domain is the root server domain, so the answer is large. A list of all the root domain nameservers is sent back in response. Small input and large output make this form of amplification. To direct the amplified traffic to the intended target, the attacker spoofs the source, inserting the IP address of the target system, so that the long responses will be sent "back" to it. DNS can be used over TCP, and the three-way TCP "handshake" can make it nearly impossible to spoof the IP address. However, DNS can also be used over the UDP protocol, which has no handshake and makes spoofing the IP address straightforward.
Again, the characteristics of this type of attack amplification are:
- DNS over UDP (typically port 53/udp)
- An NS (nameserver) query for "." (a single dot)
- A spoofed IP address (that of the intended target).
Solutions
For an authoritative only nameserver that does not use recursion, answering with the list of root nameservers when queried for a domain for which it is not authoritative is normal behavior. The NS type query isn't asking for an address, just the nameserver(s), so no recursion is implied and the list of root nameservers are typically served from a cache or hints file.
It's difficult, often infeasible, to detect spoofed IP addresses for UDP traffic, and the query is valid. Therefore, best practices designed to mitigate the risks of one's nameserver being used as an amplifier should focus on filtering the queries, limiting the responses, and perhaps even limiting the use of UDP for DNS.
UDP requires less overhead and has a smaller impact on DNS servers. In fact many administrators of heavily loaded DNS servers tend to turn off TCP. TCP may also result in higher latency, a delay while the three-way handshake is being performed. Load balancing and caching nameservers can help alleviate the load, and QoS (quality of service) and other traffic management techniques can reduce the impact of increased latency, but even then it's not always feasible to exclusively use TCP for DNS. Testing should be done according to one's environment before implementing this option.
If one can configure the nameserver so that the answers are smaller than (or the same size as) the queries, then it is by definition no longer able to be used in amplification. A relatively large input resulting in a smaller output is attenuation. This is not of any use to the DDoS attacker.
One can limit the queries and responses by nameserver configuration. This will vary according to one's environment. Following are some mitigation strategies for BIND nameservers.
First, let's comply with generally accepted best practices and disable recursion on authoritative nameservers with the global BIND configuration option "recursion no;".
Using BIND 9, one can configure the nameserver to limit allow-recursive and allow-query-cache with IP ranges to limit the queries used in these attacks to a known subset of hosts. In this case, the target will still receive the answer that the "recursive query was refused", which is the same length as the query, but at least it does not result in amplification.
Nameserver is a "master"
If one's nameserver is a "master" for some zones, the root hints are required to correctly send NOTIFY messages to the slave nameservers. To prevent upward referral responses, the global BIND configuration option "additional-from-cache no;" can be used, so that a query like ". IN NS" will result in a REFUSED response, which is much smaller than the answer containing all of the hint information for the root nameservers.
Alternatively, you can use access controls to accomplish the same thing by denying all queries globally and then allowing queries for each zone.
Using dedicated "views" with ACLs, one can globally deny queries and recursion in the options section, and then allow queries in each zone definition (the ones for which the nameserver is authoritative). Queries for the "." hint zone are implicitly denied. Following is an example. In this case, we'll use a fictional domain "example.com" whose nameserver, ns1.example.com, typically services queries for their other *.example.com hosts only, for which we'll use a made-up 192.168.1.* address range (192.168.1.0/24). Here's the pertinent configuration definition:
acl CLIENT {
localhost;
192.168.1.0/24;
[...]
};
options {
[...]
allow-query { CLIENT; };
};
zone "example.com" {
...
allow-query { any; };
};
Here is an example of the query and the answer before the changes (recursion is already off):
$ dig @ns1.example.com -t ns .
; <<>DiG 9.4.2-P2 <<>@ ns1.example.com -t ns .
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15478
;; flags: qr rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518333 IN NS l.root-servers.net.
. 518333 IN NS m.root-servers.net.
. 518333 IN NS a.root-servers.net.
. 518333 IN NS b.root-servers.net.
. 518333 IN NS c.root-servers.net.
. 518333 IN NS d.root-servers.net.
. 518333 IN NS e.root-servers.net.
. 518333 IN NS f.root-servers.net.
. 518333 IN NS g.root-servers.net.
. 518333 IN NS h.root-servers.net.
. 518333 IN NS i.root-servers.net.
. 518333 IN NS j.root-servers.net.
. 518333 IN NS k.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 518333 IN A 198.41.0.4
a.root-servers.net. 518333 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 518333 IN A 192.228.79.201
c.root-servers.net. 518333 IN A 192.33.4.12
d.root-servers.net. 518333 IN A 128.8.10.90
e.root-servers.net. 518333 IN A 192.203.230.10
f.root-servers.net. 518333 IN A 192.5.5.241
f.root-servers.net. 518333 IN AAAA 2001:500:2f::f
g.root-servers.net. 518333 IN A 192.112.36.4
h.root-servers.net. 518333 IN A 128.63.2.53
h.root-servers.net. 518333 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 518333 IN A 192.36.148.17
j.root-servers.net. 518333 IN A 192.58.128.30
j.root-servers.net. 518333 IN AAAA 2001:503:c27::2:30
;; Query time: 73 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Fri Jan 30 10:56:15 2009
;; MSG SIZE rcvd: 500
... and here is the same query and answer (as it would appear to an attacker) after the proposed fix:
$ dig @ns1.example.com -t ns .
; <<>> DiG 9.4.2-P2 <<>> @ns1.example.com -t ns .
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 20784
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;. IN NS
;; Query time: 66 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Fri Jan 30 11:14:54 2009
;; MSG SIZE rcvd: 17
Much better!
Nameserver is authoritative but is operating as a slave only
Root hints are not required because NOTIFY messages are not required. One cannot simply remove the root hints from the configuration. BIND comes with the root hints built into the source code, so that will not solve this problem. One of the above techniques should be used instead.
Nameserver is both authoritative and caching
These two function should be separated! Caching nameservers are susceptible to poisoning and other types of attacks. This will make you authoritative nameserver susceptible to the same attacks. Separate hardware is not required, only a separate IP address and nameserver configuration. Additionally, it may be advised to configure the authoritative nameserver to use an external address while configuring the caching nameserver to use an internal address, typically a suitable private, non-routable (RFC 1918) address.
Nameserver is caching-only
Implement proper access controls to prevent abuse by external users. Best practices for caching-only nameservers are well documented. Failure to follow them results in significant risk exposure.
These changes will mitigate risk and prevent one's nameserver from being used to amplify DDoS traffic. However, it still results in some traffic -- an attenuated amount -- still being directed at the DDoS target.
Firewall ACLs are not good countermeasures for distributed denial-of-service attacks, including any DNS amplification traffic. An IPS device (such as a snort inline box) can be given a rule to block queries used in these attacks entirely (although, this is not intended as a substitute for the above advice on nameserver configuration, which remains sound if the IPS should fail). An example snort inline "drop" rule that blocks NS queries for "." over UDP is:
drop udp any any -> $HOME_NET 53 (msg:"DNS query for single dot, possible DDoS amplification INBOUND"; content:"|01 00 00 01 00 00 00 00 00 00 00 00 02 00 01|"; classtype:attempted-dos; reference:url,isc.sans.org/diary.html?storyid=5713; sid:9999999; rev:1;)
This may result in a high number of alerts because, of course, it may be DDoS traffic and high volume is part of its nature. If you do not wish to log each time this rule blocks traffic, change the leading "drop" in the rule to "sdrop" (silent drop).
References
- http://isc.sans.org/diary.html?storyid=5713
- http://crt.io/DNS-Amplification-Attacks.pdf
- https://www.dns-oarc.net/node/98