Anatomy of a DNS DDoS Amplification Attack

by David Piscitello, ICANN SSAC Fellow
Over the past several months, a series of Distributed Denial of Service (DDoS) attacks victimized DNS root and Top Level Domain (TLD) name server operators. These attacks merit careful analysis because they combine several attack tools and methods to increase their effectiveness. The attacks also call attention to an operational problem that was solved long ago; yet most IT administrators have not adopted the answer.

The attacker's toolkit

The attacks observed against root and TLD name servers are variants of a DNS amplification attack and use the following tools:
System compromise. An attacker doesn't want to use his own system to attack other systems and risk discovery, so he launches the attack from systems on which he has gained unauthorized administrative control. There are many ways to gain control of systems. One method uses a mass email worm to infect a large number of systems. When the worm infects a system, it installs a remote software agent, or zombie,that the attacker can remotely control and direct to initiate a DoS attack.
Distributing the DoS attack sources. In the attacks observed, the attacker's goal is to saturate the targeted name server operator's communications infrastructure rather than the name servers themselves. Name server operators typically have large access circuits, so launching an attack from a single source is unlikely to accomplish this goal. But by amassing a veritable army of attack sources the attacker can fill even Gigabit per second access circuits. Botnets, a collection of zombie hosts the attacker "owns," commonly serve as the attacker's army.
Amplification. Attackers use amplification to increase the traffic volume in an attack. In the DNS attacks, the attacker uses an extension to the DNS protocol (EDNS0) that enables large DNS messages. The attacker composes a DNS request message of approximately 60 bytes to trigger delivery of a response message of approximately 4000 bytes to the target. The resulting amplification factor, approximately 70:1, significantly increases the volume of traffic the target receives, accelerating the rate at which the target's resources will be depleted.
DNS data corruption. To achieve the amplification effect, the attacker issues a DNS request that he knows will evoke a very large response. There are many ways for the attacker to know which DNS resource record to request in advance. For this article, we'll choose one and assume that the attacker has previously compromised a poorly configured name server and has modified this server's zone file to include a DNS TXT resource record of approximately 4000 bytes to serve as the amplification resource record.
Impersonation. In the DNS attacks, each attacking host uses the targeted name server's IP address as its source IP address rather than its own. The effect of spoofing IP addresses in this manner is that responses to DNS requests will be returned to the target rather than the spoofing hosts.
Exploitable name service operation. The DNS attacks exploit name servers that allow open recursion. Recursion is a method of processing a DNS request in which a name server performs the request for a client by asking the authoritative name server for the name record. Recursion is not inherently bad; however, recursion should only be provided for a trusted set of clients. Name servers that perform (open) recursion for any host provide attackers with an easily exploitable vector.

The Attack

Now that you are familiar with the attack elements, let's look at how the attack is performed. The attacker recruits his army of attack sources (the botnet). He writes the large amplification record (e.g., a 4000 byte DNS TXT resource record) in the zone file of the name server he has compromised. He tests for and compiles a list of open recursive name servers that will query the compromised name server on behalf of the spoofing hosts. (More than one million insecurely configured name servers worldwide provide open recursion, so this is quite an easy list to compile.) With these elements in place, the attacker commands his army to attack a targeted name server via the open recursive servers.
Suppose the attacker targets a name server at the IP address 10.10.1.1. At the attacker's signal, all the zombies in his botnet issue DNS request messages asking for the amplification record through open recursive servers (see diagram). The botnet hosts spoof the targeted name server by writing 10.10.1.1 in the source IP address field of the IP packets containing their DNS request messages.
The open recursive name servers accept the DNS request messages from the botnet hosts. If the open recursive name servers have not received a request for this record before, and do not already hold the amplification record in their cache, they issue a DNS request message of their own to the compromised name server to retrieve it, and the compromised name server returns the amplification record to the open recursive servers. The open recursive servers compose DNS response messages containing the amplification record and return these to the systems that originated the request. The open recursive servers believe they are sending DNS response messages to the botnet hosts that made the initial query, when in fact IP spoofing causes the responses to be forwarded to the target name server at 10.10.1.1.
The targeted name server at 10.10.1.1 never issued any DNS request messages but is now bombarded with responses. The responses contain a 4000 byte DNS TXT record. A message of this size exceeds the maximum (Ethernet) transmission unit, so it is broken into multiple IP packet fragments. This forces reassembly at the destination, which increases the processing load at the target and enhances the deception: because the response spans several IP fragments, and only the first fragment contains the UDP header, the target may not immediately recognize that the attack is DNS-based.
This DDoS attack is most effective when launched via a large number of open recursive servers. Distribution increases the traffic and decreases the focus on the sources of the attack . The impact on the misused open recursive servers is generally low, so generally goes undetected. The effect on the target, however, can be severe. Attacks based on this method have achieved a bandwidth consumption rate exceeding seven (7) Gigabits per second.

Surviving (if you are the target)

There are several measures you can take to diminish the effects of this DDoS attack.
The source IP addresses are not spoofed in the IP packets carrying the DNS response messages, so the source addresses identify the open recursive servers the zombies use. Depending on the severity of the attack and how strongly you wish to respond, you can rate-limit traffic from these source IP addresses or use a filtering rule that drops DNS response messages that are suspiciously large (over 512 bytes). In the extreme, you may choose to block traffic from the open recursive servers entirely. (This is fairly easy to do, using the Firebox's Blocked Sites list.) These efforts do not squelch the attack sources, and they do not reduce the load on networks and switches between your name server and the open recursive servers. Note that if you block all traffic from these open recursive servers you may interfere with legitimate attempts to resolve names through these servers; for example, some organizations run open recursive servers so that mobile employees can resolve from a "trusted" name server, so such users can be affected.

What can you do to reduce the threat?

We know the tools attackers use, so we need to prevent him from assembling his toolkit. Two countermeasures are obvious. Securely configure client systems and use antivirus protection so that the attacker is unable to recruit his botnet army. Securely configure name servers to reduce the attacker's ability to corrupt a zone file with the amplification record.
Disable open recursion on your name servers and only accept recursive DNS from trusted sources. This measure will greatly reduce the attack vectors. It is a relatively simple configuration change on common DNS application services such as Windows 2003 Server and BIND. If you are using an external DNS name server, test to see if it is offering open recursion. Contact your ISP or DNS provider and suggest he close this security loophole if open.
Even when used in combination, these measures cannot have the same mitigating effect as source IP address validation. By performing source IP address validation, you can effectively prevent the impersonation attack: the botnet hosts can't generate DNS request messages posing as the targeted name server, which stems the attack at the outset. If you run an Internet firewall or a router that supports access control lists, modify your egress traffic filtering policy to only allow IP packets to exit your network if they contain source IP addresses assigned from the subnets you use internally (configuration hints for Fireboxes running WFS 8.x found here, starting at step 26).
Source IP address validation is not widely implemented, despite repeated encouragement to do so by security experts and advisory groups such as SANS, CERT, and ICANN's Security and Stability Advisory Committee (SSAC). Critics of source IP address validation claim that implementation adds administrative overhead and adversely impacts performance. Sustained DDoS attacks against root and TLD name servers have potentially graver consequences, and the frequency and effectiveness of DDoS attacks is only increasing while we continue to ignore this much-needed security measure.
Telecommunications networks have been validating telephone numbers and addresses on ingress traffic for decades. It's time for IP networks do the same. ##