DDoS via DNS Amplification and Windows Server 2003

A quick show of hands; who else is still running Windows Server 2003 somewhere on their network? Ok, how many of you depend on those servers for DNS? It’s 2012 for fuck’s sake… what the hell is wrong with you people?

… I kid, I kid.

Unfortunately for the time being, I’m included in that group. I’ve got more than a few clients who still rely on the Windows Server 2003 DNS — which is the reason I’m writing this post.

This morning I had a client complaining about their Internet connectivity being quite unreliable. It was easy to determine that this was a DNS-related problem: pinging 8.8.8.8 (Google’s public DNS) was successful while resolving google.com was not. This particular network only has a single DNS so naturally that is where I looked next. Running netstat -a revealed a ton of outbound traffic — all DNS queries — directed towards their upstream DNSs and the root servers. Their DNS was making these queries, but why? I’d disabled recursion on that server literally years ago, but for some reason it was still responding to recursive queries — look at the “Flags” section of the log snippet below (this particular snippet was generated by windows’ DNS debug log). Notice where it says RD 1. This means the query was recursive:


20121105 08:40:29 F94 PACKET  02612A00 UDP Rcv 72.8.132.25     ebe4   Q [0001   D   NOERROR] ALL   (4)ripe(3)net(0)
UDP question info
  Socket = 512, recvd on port (65535)
  Remote addr 72.8.132.25, port 53
  Time Query=12890, Queued=0, Expire=0
  Buf length = 0x0500 (1280)
  Msg length = 0x0025 (37)
  Message:
    XID       0xebe4
    Flags     0x0100
      QR        0 (QUESTION)
      OPCODE    0 (QUERY)
      AA        0
      TC        0
      RD        1
      RA        0
      Z         0
      RCODE     0 (NOERROR)
    QCOUNT    1
    ACOUNT    0
    NSCOUNT   0
    ARCOUNT   1
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name      "(4)ripe(3)net(0)"
      QTYPE   ALL (255)
      QCLASS  1
    ANSWER SECTION:
      empty
    AUTHORITY SECTION:
      empty
    ADDITIONAL SECTION:
    Offset = 0x001a, RR count = 0
    Name      "(0)"
      TYPE   OPT  (41)
      CLASS  4096
      TTL    0
      DLEN   0
      DATA   (none)

Next I had a look at the firewall’s logs. The firewall has logging configured on all policies that allow requests from the public Internet, so when I saw this:

(For security purposes, we’ll pretend that the public IP address of the DNS targeted by the attack is 66.66.66.66)


Traffic Log for Policy:

(Src = "Untrust/Any", Dst = "Global/MIP(66.66.66.66)", Service = "DNS")

Current system time is Mon, 5 Nov 2012 08:43:21


Time Stamp Action Source Destination Translated Source Translated Dest Duration Bytes Sent Bytes Received Application

2012-11-05 08:43:11 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:42:55 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:42:39 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:42:23 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13695 72 DNS 
2012-11-05 08:42:07 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13197 72 DNS 
2012-11-05 08:41:51 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13529 72 DNS 
2012-11-05 08:41:35 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:41:19 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13363 72 DNS 
2012-11-05 08:41:11 Permit 200.35.37.219:1620 66.66.66.66:53 192.168.0.252:53 1 sec 75 208 DNS 
2012-11-05 08:41:09 Permit 199.224.64.72:27181 66.66.66.66:53 192.168.0.252:53 2 sec 90 120 DNS 
2012-11-05 08:41:05 Permit 67.94.175.199:53253 66.66.66.66:53 192.168.0.252:53 2 sec 86 219 DNS 
2012-11-05 08:41:03 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:40:47 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:40:31 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:40:15 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:39:59 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:39:55 Permit 64.233.168.83:36593 66.66.66.66:53 192.168.0.252:53 3 sec 75 91 DNS 
2012-11-05 08:39:43 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:39:27 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13446 72 DNS 
2012-11-05 08:39:11 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13363 72 DNS 
2012-11-05 08:38:55 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 13612 72 DNS 
2012-11-05 08:38:39 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 7 sec 9462 1112 DNS 
2012-11-05 08:38:33 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 25730 72 DNS 
2012-11-05 08:38:33 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 1 sec 83 1251 DNS 
2012-11-05 08:38:27 Permit 168.95.43.42:52906 66.66.66.66:53 192.168.0.252:53 4 sec 90 106 DNS 
2012-11-05 08:38:19 Permit 64.80.255.118:35570 66.66.66.66:53 192.168.0.252:53 3 sec 90 130 DNS 
2012-11-05 08:38:17 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 17 sec 24817 72 DNS 
2012-11-05 08:38:01 Permit 72.8.132.25:53 66.66.66.66:53 192.168.0.252:53 1 sec 166 1271 DNS 
2012-11-05 08:37:19 Permit 208.69.34.19:43768 66.66.66.66:53 192.168.0.252:53 4 sec 79 95 DNS 
2012-11-05 08:37:17 Permit 208.69.34.19:21491 66.66.66.66:53 192.168.0.252:53 2 sec 79 95 DNS 
2012-11-05 08:37:15 Permit 208.69.34.19:28679 66.66.66.66:53 192.168.0.252:53 1 sec 79 95 DNS 
2012-11-05 08:35:21 Permit 207.46.200.45:9397 66.66.66.66:53 192.168.0.252:53 3 sec 84 100 DNS

…It was pretty obvious what was going on. There were a few other suspicious IP addresses in the logs other than 72.8.132.25 including, but not limited to:


217.72.241.20
220.226.6.118
203.113.188.6
203.113.131.9
203.113.188.3

  1. Loads of traffic originating (i.e., “distributed”) from multiple source IPs? Check.
  2. Internet connectivity (i.e., “service”) pretty much dead (i.e., “denied”)? Check.

This has all the makings of a Distributed Denial of Service attack (DDoS). This particular type of DDoS is known as a DNS Amplification Attack, technically it’s a distributed reflected denial of service attack (DRDoS). It can occur when you are running an open DNS and somebody with malicious intent notices.

After blocking inbound requests from all of the suspicious IPs and verifying that service had been restored, I shifted my focus back to the DNS. There are two places in the DNS Management Console where you can disable recursive queries:

…But as far as I can tell, the DNS built into Windows Server 2003 will allow you to change these settings and then it disregards your configuration and does whatever it damn well pleases. You’d think that between the two of these configuration options, the server wouldn’t respond to any recursive queries. Sadly this is not the case as you can see in the test results from DNSStuff:

DNSStuff also provides a link in the test output that describes which steps you should take in order to close an open DNS. Unfortunately…

NOTE: These instructions show you how to completely disable recursion. This is the best practice. However, if you need to run a DNS server that is both authoritative and recursive/caching, you will need to check the DNS server documentation to find out how to enable recursive lookups only for your local network. It seems that there is no way to do this with Microsoft DNS; if so, you will need to use other DNS server software or use a hosted DNS service. If anyone is aware of a way to get Microsoft DNS to allow recursion only to specific IP ranges, please let us know -- lots of people would like to do that.

This is the default behavior of the Windows Server 2003 (and 2008, 2012 from what I’ve read) DNS. In other words, it is insecure out of the box — this is analogous to allowing unauthenticated, unrestricted relaying on a mail server by default. Thanks Microsoft!

Anyway… since the company-in-question has it’s website hosted on the local network and their only DNS also serves as the authoritative DNS for their domain name, my next course of action will be to configure a separate non-windows DNS and use that to host their zones. Let this serve as a cautionary tale to any of you out there who might be using a Windows server as an authoritative NS for domains and a resolver for queries originating on the local network.