DNS iRules: Protect Yourself From "ANY" Amplification Attacks

This is the latest in a series of DNS articles that I've been writing over the past couple of months. I started out writing about the basics of DNS and then dug into some cool DNS features on the BIG-IP. But I wanted to spend a little time on some iRule fun as well. So this article will highlight one of the many different DNS iRules out here on DevCentral. This iRule protects you from one of the popular DNS DDoS attacks (DNS Amplification Attack).

As a quick reminder, my first seven articles are:

What Is A DNS Amplification Attack?

Simply stated, a DNS amplification attack takes advantage of features that allow a very small request to return a much larger response. These attacks also rely on the fact that the attacker can request these large responses on behalf of someone else (the victim). More specifically, DNS amplification attacks are a popular type of a Distributed Denial of Service (DDoS) attack in which attackers use publically accessible open DNS resolvers to flood a target system with DNS response traffic.

DNS resolvers retrieve information from authoritative servers and return answers to end-user applications. A DNS resolver that is configured correctly will only respond for the hosts in its domain. For example, if your company has IP space 1.1.1.0 - 1.1.1.255, then your DNS resolver should not respond if a requests comes from IP address 2.2.2.2. The problem with open DNS resolvers is that they will respond to recursive queries from outside hosts. This creates some very interesting opportunities for cyber attackers.

The following diagrams outline two different scenarios: one is a DNS resolver that has been correctly configured and the other is an open DNS resolver.

I did a little research and found one website that lists over 20 million open DNS resolvers on the Internet (this number changes all the time). So what's the big deal, you say? Well, here are a few reasons that open DNS resolvers are a bad thing:

They allow outsiders to consume resources that do not belong to them
Attackers may be able to poison their cache
They are used in widespread DDoS attacks with spoofed source addresses and large DNS responses (amplification attacks)

Using one of those open DNS resolvers, I sent a simple request for isc.org records using the dig tool. You can see from the details below that I got a 3680-byte response; the request was 64 bytes (a 57x amplifier). I also tried the same request using a properly configured DNS resolver and I got a timeout response saying no servers could be reached (the correct and expected response).

 C:\dig ANY isc.org @x.x.x.x 

; <<>> DiG 9.8.6-P1 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10156
;; flags: qr rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 4, ADDITIONAL: 14

;; QUESTION SECTION:
;isc.org.                       IN      ANY

;; ANSWER SECTION:
isc.org.                7200    IN      RRSIG   SOA 5 2 7200 20140815213213 20140716213213 4521 isc.org. HYVeuPKnCx/5kVzThEObGqTC4Pit00hAGEVS7FkHKGO15/WADV05Ipre +e5dpEYpfbcH5DMGeFsIEKQ0snsiXeAFYchcQYeKtR/zOeKOdOQVmFtP 985a9jRSvFXCtFyaC9mH5WY9r2teKhil6MaEAwrHaDOZvXj0siDZZP5j K4s=
isc.org.                59      IN      A       149.20.64.69
isc.org.                60      IN      RRSIG   A 5 2 60 20140815213213 20140716213213 4521 isc.org. OgEvyaQ6VycKAtm4K7xHycQl22ZSiaySkXCxWdYgWU+0C96F7KvH1Nay auHTpvPFvmwsdz1ijJwKn1ZsdiUbNPCGJ58V/xVyMcE71+4e+vHD8HrU 7ktt/X7bQh14dm/MqzQAQJH4LLarfCKTlBzX0xCkDhOoqLw9ZuUW54I7 uww=
isc.org.                7200    IN      MX      10 mx.ams1.isc.org.
isc.org.                7200    IN      MX      10 mx.pao1.isc.org.
isc.org.                7200    IN      RRSIG   MX 5 2 7200 20140815213213 20140716213213 4521 isc.org. NtAd/mQnrku1jf9dA84Mk366nqdADF1+HnFDg1+Rl+cNb88oIBEcBcCW SttIybIe+65ganybbYDCLV8TcovCx6o/SWZMXuXmnjy5cYey6a6uAz3x uUVfr4g1RMo6OsbnJ9GfF5NDWHxKFcToOI3scHMj9fxwK19sy17uPlSn wos=
isc.org.                7200    IN      TXT     "$Id: isc.org,v 1.1906 2014-07-16 22:31:39 dmahoney Exp $"
isc.org.                7200    IN      TXT     "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org.                7200    IN      RRSIG   TXT 5 2 7200 20140815213213 20140716213213 4521 isc.org. p2DfhLN/QATV2tE7ocHVFlQvGuomk1X9ktiatir17JWiP27349zBp7qf uHM4NJjYAsxXGQdSTLnI60we8JziiRe9czcBNWmO9mRzSNEUvGFJ1ZKr r9d6RyyMq82z468IQH7IPlsM41YAbyJIdXppU0MzHkL3Z1tdRnEH0d6z XGw=
isc.org.                59      IN      AAAA    2001:4f8:0:2::69
isc.org.                60      IN      RRSIG   AAAA 5 2 60 20140815213213 20140716213213 4521 isc.org. Zqu51yF2GkLf4NPVRMyUADzXgVksJ/KfvgiWwgMTFKmwjmU6FoAW58PJ XO/A5Zr9gvRz9K3/iyGEhlxoKM+prQhtlykUm/CUtg4tsrOnu3Z9vX7P EK9QJ9ayCw2/LAAgeslpeL9aJIWHEDL6vWrmRz4UaymUNZ9Si1peCjc3 Rik=
isc.org.                7200    IN      NAPTR   20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org.                7200    IN      RRSIG   NAPTR 5 2 7200 20140815213213 20140716213213 4521 isc.org. OzJhjUmLdxwtWJoT2T8r5f8189+tb5PK5NovNRBh13WaQgCj+Xevnbt7 Y6FV44KXze3gt54wlCE0jI/5Scj1TY7fsmEYzlhs4omyxhT1P20CmVx9 yi55UevBzkinWurVrQGS2mHh6mvldzR/uGRYNf5stVhX0bREvdRQQEkj c6k=
isc.org.                3600    IN      NSEC    _adsp._domainkey.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org.                3600    IN      RRSIG   NSEC 5 2 3600 20140815213213 20140716213213 4521 isc.org. jGkMrA76pO0rmNyjKXwVydxQEfdoxho9dIOCjXsLzvB1Q4KJljBQgHOB Qx8E59RrMoZp6dIDd14rH22BBgBXEuK7VIn4FvyR0+HTYToYdVXna8XO 9SVlFipeJe8ch2DyYr8HuYItH7WSHfSfcoG6Z0Iexulqbq4vwxeeXkvk Rh4=
isc.org.                7200    IN      DNSKEY  256 3 5 AwEAAbJpDF4RemdHHE/HrJJhR3zpzAQ6zsHqFv0i4lCWTUf4sX+cq3vS u7fKO4QJtm97S1sbcnmHonVE3QPzLOsqsY630Wy5JzrPK3gUvQLgfIso vo2v+dosITL8WbvjU1mEXhIwfuuBhYmYSKySZ0X9gpHGhdxRd+J8M7ri PfN7kHLP
isc.org.                7200    IN      DNSKEY  257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org.                7200    IN      RRSIG   DNSKEY 5 2 7200 20140815210128 20140716210128 4521 isc.org. gMreL9DFjvDFpMVl1Uh1/tPBFOg0rvo060dfEUxJEIlu2Wqsqqz/rv7X 98NgLFo5T4KLbVp8Wloc7sYBHz9OVa1ILV/UYDFFgVCAkLa9yv2XBPkj X6HEGVy1ddx2pcN6K0mKrjs75Z9kvX49c2EEu1ohc6vtLG16Y4mwy114 lWM=
isc.org.                7200    IN      RRSIG   DNSKEY 5 2 7200 20140815210128 20140716210128 12892 isc.org. Om1S8XzWDaMkne1BL1O77uNBx4VecenGpAaaoiBjnzHz/xHMBylK7mA4 OcH9OwI2NoXQ/EB7qfowkzbwZEF+Ep+VJ3y2fykpDkUGn8iueHw9CEIq m7kPbioANV7CECNT8giB/pHO7na0hAZGnhaYfBkRTw28NitNSdaPa3CFru+JspRLkxeufCNLJkpU6nlCNI0DSfmj6D8sCECNnPUBetWMBlZyfmyd pRE+ZT+5Q2qoUV152pn86MxVPLe5nJc1fEcwi/9XoFaoTtDywdL+GL0f uaWIcZm4QaugYY6Bi532/IAXfqDxaLImoQh/vYj5Q0JRgZTrsQdP0o/n aWKW5w==
isc.org.                7200    IN      SPF     "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org.                7200    IN      RRSIG   SPF 5 2 7200 20140815213213 20140716213213 4521 isc.org. Il7WC6FXFV73qEjXhqiQ2M4IYN3yZngbWmqr/FnDOeQnRTipW5+MVXel M377OezVnnmni1//KQEjeO/iVl03ShcHdhgfslSKlsPc5m2nlVaVB+CB FhNxWwIEdLOL8Yn3ZyW5i1hKqCSUmTD/KiC+xHyTQvs/QwNjmeorZ52i /gs=
isc.org.                7200    IN      SOA     ns-int.isc.org. hostmaster.isc.org. 2014071601 7200 3600 24796800 3600
isc.org.                7199    IN      NS      ord.sns-pb.isc.org.
isc.org.                7199    IN      NS      ns.isc.afilias-nst.info.
isc.org.                7199    IN      NS      ams.sns-pb.isc.org.
isc.org.                7199    IN      NS      sfba.sns-pb.isc.org.
isc.org.                7200    IN      RRSIG   NS 5 2 7200 20140815213213 20140716213213 4521 isc.org. V3ye+DubBygL2Dz7AHMjjC1CrVkWUDnjnZKOsOG/VWDY6tWFVV49OHeV 7HmaB2vAdrE7ZSr6pwffonvY9xRCPHf6QUrcrrc5bYi3QASZGZ2AKwTJ UuwVgSnh/1ZyDkOnSP29UwBYUol+CSas/Z8Oo32bBFLcsEZUWW56xUmC 1eE=
isc.org.                81985   IN      RRSIG   DS 7 2 86400 20140807155612 20140717145612 21185 org. ZO/Yl9ByYm0NZbL2x7v14pvFknBQJeL7zFRgUocxSRi3v/g/kBTACNTH Fp4dQGgO2JjMkYd2DhvFRmxLYa2+aoASPuNU9lM9TdZ36ptrBkWeNp4l 09BVLhrSW140P7Jkud/nCkn/RtHYonfwp9rs6tJxINIE3KClAMRDn1xr ZmE=
isc.org.                81985   IN      DS      12892 5 1 982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759
isc.org.                81985   IN      DS      12892 5 2 F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5

;; AUTHORITY SECTION:
isc.org.                7199    IN      NS      sfba.sns-pb.isc.org.
isc.org.                7199    IN      NS      ord.sns-pb.isc.org.
isc.org.                7199    IN      NS      ns.isc.afilias-nst.info.
isc.org.                7199    IN      NS      ams.sns-pb.isc.org.

;; ADDITIONAL SECTION:
mx.ams1.isc.org.        3600    IN      A       199.6.1.65
mx.ams1.isc.org.        3600    IN      AAAA    2001:500:60::65
mx.pao1.isc.org.        3600    IN      A       149.20.64.53
mx.pao1.isc.org.        3600    IN      AAAA    2001:4f8:0:2::2b
asterisk.isc.org.       299     IN      A       149.20.32.15
ns.isc.afilias-nst.info. 9497   IN      A       199.254.63.254
ns.isc.afilias-nst.info. 9497   IN      AAAA    2001:500:2c::254
ams.sns-pb.isc.org.     2785    IN      A       199.6.1.30
ams.sns-pb.isc.org.     2785    IN      AAAA    2001:500:60::30
ord.sns-pb.isc.org.     2785    IN      A       199.6.0.30
ord.sns-pb.isc.org.     2785    IN      AAAA    2001:500:71::30
sfba.sns-pb.isc.org.    2785    IN      A       149.20.64.3
sfba.sns-pb.isc.org.    2785    IN      AAAA    2001:4f8:0:2::19
_sip._udp.isc.org.      7200    IN      SRV     0 1 5060 asterisk.isc.org.

;; Query time: 748 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Thu Jul 16 14:31:53 Central Daylight Time 2014
;; MSG SIZE  rcvd: 3680

One other key piece to this puzzle is that DNS uses the User Datagram Protocol (UDP) to send requests and responses. UDP is a connectionless protocol, so it doesn't care if the recipient of a given response is the intended recipient. An attacker could spoof an IP address and use an open DNS resolver to request a bunch of DNS data and have it sent to the victim's machine. The victim would be like, "why in the world are you sending me all this stuff I didn't ask for?!?" And then the victim would get overwhelmed with DNS data and wouldn't be able to process legitimate traffic.

One specific type of DNS request is the "ANY" request. As you probably know, a DNS server can respond with lots of different record types (you can see several of them in the screenshot above). Some are bigger than others and, ironically for this situation, some of the biggest are the records associated with DNSSEC (which is a suite of extensions that adds security to DNS responses). If you are an attacker and you want to flood a victim's machine with lots of data, it stands to reason that you would request the largest records. Well, there's an "ANY" query that returns all known information about a DNS zone in a single request (I used the "ANY" query in the example above).

Check out the following picture for an example:

Even though a small request can result in a large response, an attacker will need to send lots of these requests in order to really affect the victim. This is where a botnet can be very powerful and effective. 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. As I like to say, "botnets put the "D" in DDoS." Imagine the scenario pictured above with millions of attack machines sending millions of "ANY" requests to millions of open DNS resolvers "on behalf of" only one victim machine. You can see pretty quickly how this distributed attack could overwhelm the victim machine.

It gets hard to prevent these types of attacks because the DNS responses are legitimate data coming from valid servers. In fact, the United States Computer Emergency Readiness Team (US-CERT) says "Unfortunately, due to the massive traffic volume that can be produced by one of these attacks, there is often little that the victim can do to counter a large-scale DNS amplification-based distributed denial-of-service attack." Well that's not very encouraging. One thing you could do is simply block the "ANY" query type, but that would also block legitimate ANY queries that are required for certain applications. What other options are there?

The iRule...

Let me introduce you to the flexibility and power of F5's iRules! Now, I'm not saying that this iRule will solve every single problem in your life, but it has certainly proven to be very effective in mitigating these "ANY" amplification attacks. The iRule (technically 2 iRules) utilizes two Virtual Servers: one UDP and one TCP.

The iRule on the UDP VIP checks to see if the query type is "ANY" and, if so, it responds with a truncated message which will force the legitimate client to use TCP (a connection-based protocol that allows the sender to know who the recipient is). This iRule also requires you to create a data group (called "admin_datagroup" in this iRule) that lists the networks that are allowed to do recursive lookups. If the DNS response is not from DNS Express and does not match the admin_datagroup then the response gets dropped. Note that starting in v11, any data groups that are configured in a partition other than /Common must be referenced by /Partition_Name/Data-Group_Name, even by iRules configured in that partition. Data groups referenced only by name are implicitly presumed to be /Common/Data-Group_Name.

The iRule on the TCP VIP simply checks to see if the response is from DNS Express or is a part of the admin_datagroup. If neither is true, the response gets dropped.

Here's the iRule (also found on the DevCentral wiki page):

# UDP VIP iRule 

# This first part checks if the DNS query type is "ANY" and responds with a truncated header 

when DNS_REQUEST { 
if { [DNS::question type] eq "ANY" } { 
DNS::answer clear 
DNS::header tc 1 
DNS::return 
} 
} 

# This part checks to see if the response packet is built from the first logic (origin = TCL) 
# If yes, then exit and do not process further 
# If no, then check if the response is from DNS Express...if it is, allow an answer for non "ANY" type 
# If not from DNS Express, check to see if it matches the admin_datagroup created for recursive allowed networks 
# If it does not match both conditions, then drop 

when DNS_RESPONSE { 
if { [DNS::origin] eq "TCL" } { 
return 
} elseif { [DNS::origin] ne "DNSX" } { 
if { not [class match [IP::client_addr] eq "admin_datagroup" ] } { 
DNS::drop 
} 
} 
}

#TCP VIP iRule 

# Simple logic to check and see if the response is from DNS Express or a part of the admin_datagroup 
# If not from DNS Express, check to see if it matches the admin_datagroup created for recursive allowed networks 
# If it does not match both conditions, then drop 

when DNS_RESPONSE { 
if { [DNS::origin] ne "DNSX" } { 
  if { not [class match [IP::client_addr] eq "admin_datagroup" ] } { 
DNS::drop 
} 
} 
}

So, that's it! Isn't it cool that you can take a few lines of simple code and mitigate a potentially disastrous DDoS attack against your critical business infrastructure? You gotta love the power and flexibility of DNS iRules. You can read more about DNS iRules on the DNS wiki page on DevCentral. Stay tuned for more exciting articles on DNS in the future!

Published Jul 16, 2014

Version 1.0