DNS Amplification Variation Used in Recent DDoS Attacks 9:38 PM

A variant of DNS amplification is gaining favor among the operators of commercial DDoS botnet operators. Additional best practices have been suggested to mitigate the risk of attackers using one's nameserver to target victims.

Analysis

DDoS (distributed denial-of-service) attacks attempt to overwhelm the target by sending an overwhelming amount of traffic to it from host computers -- typically members of a botnet -- that are distributed among various locations, making it difficult or infeasible to block the traffic simply by source address. Various types of traffic are sent: floods of TCP SYN (a "SYN flood" can exhaust available connections on a target), UDP, and ICMP packets. Attacks on services at a higher network layer, especially DNS, HTTP (web), and SMTP (mail) are common as well, and newer techniques have been developed for newer services, such as SIP floods designed to take down VoIP phone services.

DDoS attacks are carried out against web servers and other Internet services every day. Only the most severe attacks or the most prominent targets will make the news. There is an underground economy centered around the commercial operation of botnets designed to carry out DDoS attacks for hire or to extort money from the targets. Anyone who relies on their Internet presence to generate revenue can be a target; however, attackers often go after sites that will garner the least public support, particularly pornography sites (the less mainstream the better) and online gaming sites (gaming, in this sense, being the politically correct term for gambling).

Amplification

When faced with a large target, or a small number of available bots, the DDoS attacker may make use of amplification techniques. These use bot to send a relatively small

amount of traffic to other computers that in turn send more traffic towards the actual target. A traditional way of doing this is by sending an ICMP echo request from the spoofed IP address of the intended target to a bystander (or the target's) network's broadcast address. Hosts on the network that receive and respond the request will echo the ICMP payload to the actual target, thereby hitting it with many response packets per each request sent by the attacker. Best practices in network configuration and traffic filtering have largely mitigated risks from this type of amplification. However, a newer type called "DNS amplification" made headlines in 2006. Best practices can help address this as well.

Using DNS to amplify attacks

In early 2006, DNS amplification attacks were studied by Randal Vaughn and Gadi Evron, founding members of the anti-cyber crime group Internet Security Operations Task Force (ISOTF). Their paper presented findings regarding the underlying mechanism of these attacks (spoofed UDP DNS queries), enabling configurations (allowing answers to recursive queries from arbitrary sources), and evasion tactics (packet fragmentation). The paper also studies the effects: attacks resulting in traffic peaks as high as 10 Gbps using more than 140,000 misconfigured (or too loosely configured) publicly available nameservers. Restricting who can perform recursive queries, and queries in general, has mitigated this risk.

DNS amplification without recursion

A new form of DNS amplification is gaining favor with commercial DDoS operators because it does not rely on recursive queries. This new tactic uses a very short query, asking simply for the nameservers for the "." domain. This domain is the root server domain, so the answer is large. A list of all the root domain nameservers is sent back in response. Small input and large output make this form of amplification. To direct the amplified traffic to the intended target, the attacker spoofs the source, inserting the IP address of the target system, so that the long responses will be sent "back" to it. DNS can be used over TCP, and the three-way TCP "handshake" can make it nearly impossible to spoof the IP address. However, DNS can also be used over the UDP protocol, which has no handshake and makes spoofing the IP address straightforward.

Again, the characteristics of this type of attack amplification are:

1. DNS over UDP (typically port 53/udp)

2. An NS (nameserver) query for "." (a single dot)

3. A spoofed IP address (that of the intended target).

Solutions

For an authoritative only nameserver that does not use recursion, answering with the list of root nameservers when queried for a domain for which it is not authoritative is normal behavior. The NS type query isn't asking for an address, just the nameserver(s), so no recursion is implied and the list of root nameservers are typically served from a cache or hints file.

It's difficult, often infeasible, to detect spoofed IP addresses for UDP traffic, and the query is valid. Therefore, best practices designed to mitigate the risks of one's nameserver being used as an amplifier should focus on filtering the queries, limiting the responses, and perhaps even limiting the use of UDP for DNS.

UDP requires less overhead and has a smaller impact on DNS servers. In fact many administrators of heavily loaded DNS servers tend to turn off TCP. TCP may also result in higher latency, a delay while the three-way handshake is being performed. Load balancing and caching nameservers can help alleviate the load, and QoS (quality of service) and other traffic management techniques can reduce the impact of increased latency, but even then it's not always feasible to exclusively use TCP for DNS. Testing should be done according to one's environment before implementing this option.

If one can configure the nameserver so that the answers are smaller than (or the same size as) the queries, then it is by definition no longer able to be used in amplification. A relatively large input resulting in a smaller output is attenuation. This is not of any use to the DDoS attacker.

One can limit the queries and responses by nameserver configuration. This will vary according to one's environment. Following are some mitigation strategies for BIND nameservers.

First, let's comply with generally accepted best practices and disable recursion on authoritative nameservers with the global BIND configuration option "recursion no;".

Using BIND 9, one can configure the nameserver to limit allow-recursive and allow-query-cache with IP ranges to limit the queries used in these attacks to a known subset of hosts. In this case, the target will still receive the answer that the "recursive query was refused", which is the same length as the query, but at least it does not result in amplification.

Nameserver is a "master"

If one's nameserver is a "master" for some zones, the root hints are required to correctly send NOTIFY messages to the slave nameservers. To prevent upward referral responses, the global BIND configuration option "additional-from-cache no;" can be used, so that a query like ". IN NS" will result in a REFUSED response, which is much smaller than the answer containing all of the hint information for the root nameservers.

Alternatively, you can use access controls to accomplish the same thing by denying all queries globally and then allowing queries for each zone.

Using dedicated "views" with ACLs, one can globally deny queries and recursion in the options section, and then allow queries in each zone definition (the ones for which the nameserver is authoritative). Queries for the "." hint zone are implicitly denied. Following is an example. In this case, we'll use a fictional domain "example.com" whose nameserver, ns1.example.com, typically services queries for their other *.example.com hosts only, for which we'll use a made-up 192.168.1.* address range (192.168.1.0/24). Here's the pertinent configuration definition:

acl CLIENT {

    localhost;

    192.168.1.0/24;

[...]

};

options {

[...]

    allow-query { CLIENT; };

};

zone "example.com" {

...

    allow-query { any; };

};

Here is an example of the query and the answer before the changes (recursion is already off):

$ dig @ns1.example.com -t ns .

; <<>DiG 9.4.2-P2 <<>@ ns1.example.com -t ns .

; (1 server found)

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15478

;; flags: qr rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14

;; WARNING: recursion requested but not available

;; QUESTION SECTION:

;.                              IN      NS

;; ANSWER SECTION:

.                       518333  IN      NS      l.root-servers.net.

.                       518333  IN      NS      m.root-servers.net.

.                       518333  IN      NS      a.root-servers.net.

.                       518333  IN      NS      b.root-servers.net.

.                       518333  IN      NS      c.root-servers.net.

.                       518333  IN      NS      d.root-servers.net.

.                       518333  IN      NS      e.root-servers.net.

.                       518333  IN      NS      f.root-servers.net.

.                       518333  IN      NS      g.root-servers.net.

.                       518333  IN      NS      h.root-servers.net.

.                       518333  IN      NS      i.root-servers.net.

.                       518333  IN      NS      j.root-servers.net.

.                       518333  IN      NS      k.root-servers.net.

;; ADDITIONAL SECTION:

a.root-servers.net.     518333  IN      A       198.41.0.4

a.root-servers.net.     518333  IN      AAAA    2001:503:ba3e::2:30

b.root-servers.net.     518333  IN      A       192.228.79.201

c.root-servers.net.     518333  IN      A       192.33.4.12

d.root-servers.net.     518333  IN      A       128.8.10.90

e.root-servers.net.     518333  IN      A       192.203.230.10

f.root-servers.net.     518333  IN      A       192.5.5.241

f.root-servers.net.     518333  IN      AAAA    2001:500:2f::f

g.root-servers.net.     518333  IN      A       192.112.36.4

h.root-servers.net.     518333  IN      A       128.63.2.53

h.root-servers.net.     518333  IN      AAAA    2001:500:1::803f:235

i.root-servers.net.     518333  IN      A       192.36.148.17

j.root-servers.net.     518333  IN      A       192.58.128.30

j.root-servers.net.     518333  IN      AAAA    2001:503:c27::2:30

;; Query time: 73 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)

;; WHEN: Fri Jan 30 10:56:15 2009

;; MSG SIZE  rcvd: 500

... and here is the same query and answer (as it would appear to an attacker) after the proposed fix:

$ dig @ns1.example.com -t ns .

; <<>> DiG 9.4.2-P2 <<>> @ns1.example.com -t ns .

; (1 server found)

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 20784

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; WARNING: recursion requested but not available

;; QUESTION SECTION:

;.                              IN      NS

;; Query time: 66 msec

;; SERVER: 192.168.1.2#53(192.168.1.2)

;; WHEN: Fri Jan 30 11:14:54 2009

;; MSG SIZE  rcvd: 17

Nameserver is authoritative but is operating as a slave only 

Root hints are not required because NOTIFY messages are not required. One cannot simply remove the root hints from the configuration. BIND comes with the root hints built into the source code, so that will not solve this problem. One of the above techniques should be used instead. Nameserver is both authoritative and caching These two function should be separated! Caching nameservers are susceptible to poisoning and other types of attacks. This will make you authoritative nameserver susceptible to the same attacks. Separate hardware is not required, only a separate IP address and nameserver configuration. Additionally, it may be advised to configure the authoritative nameserver to use an external address while configuring the caching nameserver to use an internal address, typically a suitable private, non-routable (RFC 1918) address. 

Nameserver is caching-only 

Implement proper access controls to prevent abuse by external users. Best practices for caching-only nameservers are well documented. Failure to follow them results in significant risk exposure. These changes will mitigate risk and prevent one's nameserver from being used to amplify DDoS traffic. However, it still results in some traffic -- an attenuated amount -- still being directed at the DDoS target. Firewall ACLs are not good countermeasures for distributed denial-of-service attacks, including any DNS amplification traffic. An IPS device (such as a snort inline box) can be given a rule to block queries used in these attacks entirely (although, this is not intended as a substitute for the above advice on nameserver configuration, which remains sound if the IPS should fail). An example snort inline "drop" rule that blocks NS queries for "." over UDP is: drop udp any any -> $HOME_NET 53 (msg:"DNS query for single dot, possible DDoS amplification INBOUND"; content:"|01 00 00 01 00 00 00 00 00 00 00 00 02 00 01|"; classtype:attempted-dos; reference:url,isc.sans.org/diary.html?storyid=5713; sid:9999999; rev:1;)

This may result in a high number of alerts because, of course, it may be DDoS traffic and high volume is part of its nature. If you do not wish to log each time this rule blocks traffic, change the leading "drop" in the rule to "sdrop" (silent drop).

.:READ MORE:.

How Encapsulation Works Within the TCP/IP Model 11:09 AM

In the previous section we reviewed the TCP/IP and OSI model. For the sake of clarity, we will be using the TCP/IP model to demonstrate encapsulation, as compared to the OSI model. If you are still struggling with grasping concepts of the TCP/IP model you may wish to view the previous section once more. Otherwise, onward to the encapsulation process!

As we learned in the previous section, the TCP/IP model has four layers. You can view a diagram of the model below.

Keep in mind that we divide the stack into four separate layers because they each perform a certain role or task. As data is being sent from one computer, it will pass from the top layer to the bottom. On the receiving end, the data will then be rebuilt from the bottom layer to the top. You can view an example of this process below.

Each layer a packet of information travels through adds what is called a header. Think of it in terms of a Russian doll. You’re probably familiar with them: each doll has another smaller doll inside of it. Just like the dolls, each layer a sending packet passes through gains another header (or doll). When the packet is being rebuilt on the receiving end, each header is unpackaged the same way. You can see an example of a sending packet gaining header information below.

Note that at the receiving end, we would have the reverse process (Headers would be taken away at each layer, until the receiving packet is by itself.)

Since each layer of the TCP/IP model does a unique task separate of the other layers, we refer to the data package at each layer with different names. For instance, the data package at the Application Layer is called a message, while the same data package at the Internet Layer is called a datagram. Review the diagram below for the complete list of names.

Notice that the Transport Layer may have one of two names- a segment or a datagram. If the TCP protocol is being used, it is called a segment. If the UDP protocol is being used, it is called a Datagram.

The data then passes through the Internet Layer onto the Network Access Layer, where a frame is created. Once the data packet leaves this level it is converted into a bitstream of electrical pulses, commonly referred to as 1’s and 0’s.

Finally, you should note that Cisco demands CCNA students to know specific information on the Data Link Layer and encapsulation. As you can see, we haven’t used the OSI model, but the TCP/IP model (so we use the Network Access Layer as opposed to the Data Link and Physical Layer). Specifically, Cisco demands that students know that packets are packaged into frames at the Data Link Layer. And, like other layers, a header and trailer are added to the information at the Data Link Layer. You can see the encapsulation process with the OSI model below.

We know what you’re thinking- where’s a good pneumonic when you need it? The easiest one we could find was “Dirty Sick People Feel Bad,” whereas each letter of each word corresponds to Data, Segments, Packets, Frames, and Bits.

--------

Now that we have the basics down, we can finally review the entire process of data encapsulation. Refer to the below list to see a real-life example of encapsulation. If needed, you can view the above diagrams if you get lost.

The Data Encapsulation Process

---

• 1. One computer requests to send data to another over a network.
• 2. The data message flows through the Application Layer by using a TCP or UDP port to pass onto the internet layer.
• 3. The data segment obtains logical addressing at the Internet Layer via the IP protocol, and the data is then encapsulated into a datagram.
• 4. The datagram enters the Network Access Layer, where software will interface with the physical network. A data frame encapsulates the datagram for entry onto the physical network. At the end of the process, the frame is converted to a stream of bits that is then transmitted to the receiving computer.
• 5. The receiving computer removes the frame, and passes the packet onto the Internet Layer. The Internet Layer will then remove the header information and send the data to the Transport layer. Likewise, the Transport layer removes header information and passes data to the final layer. At this final layer the data is whole again, and can be read by the receiving computer if no errors are present.

.:READ MORE:.