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 10.100.101.102 port 80 from an open DNS resolver running on IP address 192.168.5.10:
[email protected]:~# dig ANY exampletest.xab @192.168.5.10 +edns=0
; <<>> DiG 9.8.1-P1 <<>> ANY exampletest.xab @192.168.5.10 +edns=0
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 39, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;exampletest.xab. IN ANY
;; ANSWER SECTION:
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 192.168.22.167
exampletest.xab. 299 IN A 192.168.22.166
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
;; SERVER: 192.168.5.10#53(192.168.5.10)
;; 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 192.168.5.10 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.
[email protected]~# 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.