A DDoS Attack Explained: DNS Amplification Attack


Up to this point, we’ve largely focused on the types of DDoS attack associated with TCP connections, but today we’d like to switch our focus over to another area: DNS amplification attacks.

A DNS amplification DDoS attack builds on the connection-less orientation of the UDP protocol. Attackers use publically accessible open DNS servers to flood a target system with DNS response traffic. The primary technique consists of an attacker sending a DNS name lookup request to an open DNS server with the source address spoofed to be the target’s address. When the DNS server sends the DNS record response, it is sent instead to the target. Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect. The amplification factor of this type of attack is up to 54x. What this means is that for every byte of traffic that is sent from the attacker, up to 54 bytes of traffic will be sent to the destination.

In most attacks of this type observed by US-CERT, the spoofed queries sent by the attacker are of the type, “ANY,” which returns all known information about a DNS zone in a single request. Because the size of the response is considerably larger than the request, the attacker is able to increase the amount of traffic directed at the victim. By leveraging a botnet to produce a large number of spoofed DNS queries, an attacker can create an immense amount of traffic with little effort. Additionally, because the responses are legitimate data coming from valid servers, it is extremely difficult to prevent these types of attacks.

Below, we see an example of a DNS query targeting port 80 from an open DNS resolver running on IP address

root@linuxbox:~# dig ANY exampletest.xab @ +edns=0

; <<>> DiG 9.8.1-P1 <<>> ANY exampletest.xab @ +edns=0
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 39, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;exampletest.xab. IN ANY

exampletest.xab. 3599 IN TXT “553992721-5400647”
exampletest.xab. 3599 IN SOA ns1.exampletest.xab. 2015062301 28800 7200 604800 3600
exampletest.xab. 299 IN MX 10 abcmail1.exampletest.xab.
exampletest.xab. 299 IN MX 10 defmail5.exampletest.xab.
exampletest.xab. 299 IN MX 10 defmail3.exampletest.xab.
exampletest.xab. 299 IN MX 10 ghimail1.exampletest.xab.
exampletest.xab. 299 IN MX 10 abcmail2.exampletest.xab.
exampletest.xab. 21599 IN NS ns1.exampletest.xab.
exampletest.xab. 21599 IN NS ns3.exampletest.xab.
exampletest.xab. 299 IN A
exampletest.xab. 299 IN A
exampletest.xab. 3599 IN TXT “178953544-4422001”
exampletest.xab. 3599 IN TXT “228406766-4422034”
exampletest.xab. 3599 IN TXT “299762315-4422055”
exampletest.xab. 3599 IN TXT “826318936-4422046”
exampletest.xab. 3599 IN TXT “598362127-4422061”
exampletest.xab. 3599 IN TXT “227933795-4422004”
exampletest.xab. 3599 IN TXT “691244312-4422022”
exampletest.xab. 3599 IN TXT “287893658-4422013”
exampletest.xab. 3599 IN TXT “186244776-4422028”
exampletest.xab. 3599 IN TXT “353675828-4422052”
exampletest.xab. 3599 IN TXT “782919862-4417942”
exampletest.xab. 3599 IN TXT “126353328-4422040”
exampletest.xab. 3599 IN TXT “294923881-4422049”
exampletest.xab. 3599 IN TXT “667921463-4422007”
exampletest.xab. 21599 IN NS ns2.exampletest.xab.
exampletest.xab. 21599 IN NS ns1.exampletest.xab.
exampletest.xab. 3599 IN TXT “764482656-4422025”
exampletest.xab. 3599 IN TXT “757973593-4422016”
exampletest.xab. 3599 IN TXT “MS=ms66433104”
exampletest.xab. 3599 IN TXT “714321871-4421998”
exampletest.xab. 3599 IN TXT “882369757-4422010”
exampletest.xab. 3599 IN TXT “ms=ms97244866”
exampletest.xab. 3599 IN TXT “321959687-4422031”
exampletest.xab. 3599 IN TXT “754510718-4422064”
exampletest.xab. 3599 IN TXT “319997471-4422043”
exampletest.xab. 3599 IN TXT “522183251-4422019”
exampletest.xab. 3599 IN TXT “688562515-4422037”
exampletest.xab. 3599 IN TXT “133466244-4422058”

;; Query time: 254 msec
;; WHEN: Thu Jul 9 14:10:14 2015
;; MSG SIZE rcvd: 1175

In the example above, a 64 byte packet sent from a malicious source caused the open DNS resolver running on to reply with a packet with a size of 1175 bytes. In this case, it’s only amplification factor of 18, but they can get much larger depending on what domain is being queried! DNS amplification attacks were a very big deal in 2012.

The reason they were so popular was because they were easy to generate due to a very large number of misconfigured open DNS resolvers. This brought upon the Open Resolver Project. This site was created, as the name implies, to help identify open DNS resolvers. Of course the downside of this was that it made it easier for people to generate large DDoS attacks, but what it did was cause people to start fixing their own DNS resolvers and contact people who had misconfigured DNS resolvers. This project spearheaded significantly reducing the capability to execute DNS amplification attacks.

A funny thing that DDoS mitigation providers and probably a lot of ISPs had happen during this time was that people who were running open DNS resolvers would get in contact with us and tell us that we are DoSing their resolver. The reason they thought that we were DoSing them was that our IP (the one that the actual attacker spoofed) was continuously querying their server, so it looked like we were DoSing them. What they didn’t realize was that the packets were spoofed, and in fact they were the ones DoSing us! This was useful because we were able to tell them how to stop their resolver from participating in DDoS attacks, which helped everyone, except for the attackers.

This sort of DNS traffic is suspect primarily for the large amount of data being “requested”- no normal application or server should ever generate a request designed to elicit this kind of response. Although DNS requests mostly happen over the UDP protocol, there is a way to force DNS over TCP. If the DNS server allows for TCP mode, then denying UDP DNS requests is a very good idea.

root@linuxbox~# dig test.site ;; Truncated, retrying in TCP mode.

This eliminates the connection-less properties of UDP traffic, allowing DNS traffic to flow without simply blocking or rate-limiting packets, but only over a verified and properly-initiated connection.

DDoS Attacks Against Data Centers

data centerDDoS attacks come in all shapes and sizes. They are used to harm businesses, extort money, annoy system administrators, test vulnerabilities, and many other, mostly malicious reasons. A DDoS attack is typically meant to target a specific service, such as a website. By taking the website offline, the attacker accomplishes whatever goal he set for.

A data center is a facility that hosts many online services. They are indirectly the target of the majority of DDoS attacks, as they host most of the services on the web. These data centers all have various methods of dealing with DDoS attacks.

In order to understand the kind of impact DDoS attacks have on a data center, first we need to define at a high level what the network infrastructure of a typical data center looks like. Of course, network architecture is much more complicated, but at a high level, traffic entering the data center comes in through either the data center’s transit or peering network to the core layer, then aggregation layer, and finally the access layer prior to getting to the server hosting the online service.

Transit and peering links are connected to the large core router that sits at the edge of the network. This hardware is meant to be able to handle a large amount of data coming in. The aggregation layer is meant to handle a smaller amount of traffic. This is handled by having a larger number of aggregation layer hardware than core. The aggregation layer is typically where things like load balancing and firewalls are located. Prior to hitting the server, the traffic is sent to the access layer. The access layer is typically a top of rack switch, where a whole cabinet worth of services receive their internet connectivity from. There usually isn’t much going on at the access level. Access layer routers usually have a single or redundant uplink from the aggregation layer and either 1G or 10G. What this means is that a cabinet full of servers all share this 1G or 10G port upstream of them.

As far as vulnerability to DDoS is concerned, the end server is typically the most vulnerable due to two major factors: 1. that’s where the application is located, and as such its resources can quickly be depleted by a DDoS attacks, and 2. it only has a limited amount of network capacity (in this example, we’ll say it has a 1G port). A 1 gbps DDoS attack can take down almost any server solely due to the fact that it takes up all of the available network capacity of the server.

Moving up the chain, the access layer is the next most vulnerable part of a datacenter’s network when it comes to DDoS. This is due to the fact that it also has a more limited amount of network connectivity powering it. In this example, we’ll say the access layer switches have a 10g port coming from the aggregation layer. What this means is that a 10g DDoS attack target against a single server can take out every single server that shares an access layer switch with it. This is a huge problem for data centers. They can’t have one person getting hit by an attack impact potentially hundreds of other customers.

Aggregation and core routers are less vulnerable to DDoS attacks since they are limited almost exclusively by their network capacity.

How does a data center prevent a single customer getting DDoSed from impacting hundreds of other customers?

In order for a DDoS attack to not impact other customers at the access layer, the DDoS traffic must be stopped prior to it ever reaching the access layer. There are a couple of ways data centers handle this. One of the most typical strategies is for the data center to issue a blackhole on the destination IP address under attack to its transit providers. What this means is that when their transit providers receive traffic to that IP address, they don’t forward the traffic to the data center. This ensures that it never hits the access layer as it doesn’t even reach the core layer. Of course the issue with this is that it impacts all traffic, not just DDoS, so the web service is completely offline. This is a safe strategy for a data center though since it completely protects them against collateral damage at any layer. Another strategy is to have some sort of DDoS protection either using a cloud service where the traffic goes through another network before getting to the data center, or by using onsite hardware to scrub traffic at the core or aggregation layer prior to being forwarded to the access layer.

I mentioned two important things that get into the next part of this article. One was cloud protection and the other was blackholing IP addresses.

What happens if a data center receives an attack so large that it exceeds its total network capacity?

This is potentially the most devestating thing that can happen to a data center short of a critical event like power or cooling going out completely. Those things are less likely to occur due to the fact that data centers spend a lot of money ensuring that critical services have massive redundancy and backup. Many data centers have around 40 gigabits per second worth of network capacity. Very few of those ever get remotely close to using that much bandwidth. The reason for having so much capacity is to handle larger DDoS attacks that can wreck the entire network. Just like at the access level where a 10 gbps DDoS attack could impact potentially hundreds of customers (everyone at that specific access level), a 40 gbps DDoS attack, which would saturate the data center’s total network capacity, would take literally everyone being hosted in that data center offline. This is a very effective way to DDoS someone. By hitting them for so much that their data center can’t handle the traffic at all, they are forced to take that IP offline by blackholing it at the transit provider level. Since it never gets forwarded to the data center, it solves their problem at the cost of the one person being attacked being completely offline. This is an acceptable solution for data centers as the needs of the many outweigh the needs of the few. It costs too much for a company to invest in a massive network backbone just to handle these volumetric DDoS attacks. The other solution is for the datacenter to have a cloud DDoS protection provider that is specifically built to be able to take massive DDoS attacks. The data center can always have their traffic running through the DDoS protection provider, or have a manual or automatic method to send the DDoS traffic over to the DDoS protection provider when an attack occurs.

Free Cloud Services and How They Are Used for DDoS


Free cloud services have become popular in recent years. These services provide developers a platform to test software, and collaborate with others easily. While this sounds amazing, in reality these platforms can be a goldmine for attackers if not properly secured. Many of these services require only an email for verification. Setting up fake emails and automating this sign up process is all too simple for attackers.

A couple years ago at Black Hat in Las Vegas, security researchers Oscar Salazar and Rob Ragan demonstrated just how easy this process was. They managed to accumulate 1,000 free cloud accounts during one weekend. With this free botnet they performed LiteCoin mining, allowing them to average $1,750 per week in pure profit.

This was a proof of concept exercise and as such restraint was shown. A malicious user on the other hand, would feel no need to limit themselves. Imagine tens of thousands of free cloud services being utilized for DDoS attacks. Being able to bypass email authentication is simple for any skilled coder, free cloud providers need to be aware of this, and take the necessary steps to improve authentication. These types of services are ideal for attackers to perform distributed network scanning, distributed password cracking, DDoS attacks, click-fraud, crypto currency mining and data storage.

Moving forward we need to keep security in mind as we offer free services and connect more devices to the internet. The threat landscape is constantly evolving, as a community we need to evolve as well. Take any and every step possible to remain secure and up to date.