In the past eighteen months, the Internet has witnessed a major surge in DNS amplification attacks, a packet flood variation that is capable of generating huge amounts of bogus traffic directed at a target. How huge? Multi-gigabits per second, a deluge big enough to blow pretty much anyone off of the Internet.
Like the much older smurf attacks, DNS amplification involves using spoofed packets against innocent third parties to amplify traffic with the goal of sucking up all of a victim's bandwidth. But, smurf attacks involve sending packets to a network broadcast address to achieve amplification. DNS amplification attacks don't involve a broadcast address. Instead, these attacks involve sending small, spoofed DNS queries to a series of innocent third-party DNS servers on the Internet. The DNS servers send a larger response back to the address that appeared to make the request, resulting in an amplification of traffic directed to the ultimate flood target. Because DNS is based on stateless UDP packets, spoofing in this way is trivial.
Prior to late 2005, these attacks relied on DNS queries of 60 bytes or so, with responses of up to 512 bytes, giving an amplification factor of about 8.5. That's not bad for the attackers, but still not the level of flood they'd like to achieve. Recently, attackers have turned to some newer technology to crank up today's DNS amplification attacks several notches.
Many modern DNS servers support EDNS, a set of Extension Mechanisms for DNS, described in RFC 2671. Some of these options allow DNS responses to be larger than 512 bytes and still use UDP, provided that the requester indicates that it can handle such large responses in the DNS query. Attackers have used this characteristic to generate massive floods. By sending a query of 60 bytes to retrieve a record of about 4,000 bytes, an attacker can get an amplification factor of over 66. In the wild, several attacks of this nature have generated multiple Gigabits per second of traffic, in excess of 10 Gbps against some targets!
To achieve this attack, the bad guys first locate several third-party DNS servers that will perform recursive look-ups on behalf of anyone on the Internet (a large majority of DNS servers in the wild have this configuration). With recursive look-ups supported, the attacker can send a query to the DNS server, which will forward the query (in a recursive fashion) to a DNS server of the attacker's choosing, typically the attacker's own DNS server. Next, the attacker sends queries to those servers for a DNS record that the attacker controls on the attacker's own DNS server. Because they are configured for recursion, these third-party DNS servers send the request back to the attacker, who responds with a 4,000-byte TXT record, which will be cached in the DNS servers that will be used for amplification.
Now that the attacker has loaded the large record into several third-party DNS servers' caches (for a long time-to-live to make the large poison record "stick," of course), the attacker proceeds to send DNS query messages (with EDNS options for large responses enabled) to these servers, spoofing so the DNS queries appear to come from the source IP address that the attacker wishes to flood.
How can you defend against such a massive attack? First off, make sure you have adequate bandwidth to withstand small-scale floods. A single T1 doesn't cut it anymore for critical Internet connectivity, because any script kiddie with a grudge can suck up all of your bandwidth without flinching. If your connectivity is not mission critical, a T1 might be OK. Otherwise, go for more bandwidth so you can ride over small floods. Still, almost anyone would succumb to a multi-Gigabit per second flood from a DNS amplification attack.
Therefore, make sure you have the emergency contact number for your ISP handy at all times, so you can call them and ask for up stream filtering should such an attack begin. To identify this type of attack, look for massive floods of traffic that include DNS responses (source UDP port 53), typically with large DNS records in them. Some ISPs have deployed sensors throughout their networks to detect various kinds of floods early on, so it is quite possible that your ISP will discover and shun the attack before you even know about it. Ask your ISP if they have such capabilities.
And finally, to help stop miscreants from using your DNS servers as amplification agents for these floods, make sure your externally accessible DNS servers only perform recursion for your own networks and not just any address on the Internet. Most major DNS server types have the ability to limit recursion so that they accept requests for recursive lookups only from certain networks, such as your internal networks. By preventing the bad guys from using recursion to load the large poison DNS record, you'll prevent your DNS server from being part of the problem.
About the author This was first published in August 2006
Ed Skoudis is a founder and senior security consultant with Intelguardians, a Washington, DC-based information security consulting firm. His expertise includes hacker attacks and defenses, the information security industry and computer privacy issues. In addition to Counter Hack Reloaded, Ed is also the author of Malware: Fighting Malicious Code. He was also awarded 2004, 2005 and 2006 Microsoft MVP awards for Windows Server Security, and is an alumnus of the Honeynet Project. As an expert on SearchSecurity, Ed answers your questions relating to threats.
This was first published in August 2006