[lacnog] Fwd: US-CERT Alert TA13-088A: DNS Amplification Attacks

Fernando Gont fgont en si6networks.com
Dom Mar 31 02:48:28 BRT 2013 

FYI. (Disclaimer: el reenvio no implica estar de acuerdo con el total
de los contenidos)


-------- Original Message --------
Subject: US-CERT Alert TA13-088A: DNS Amplification Attacks
Date: Fri, 29 Mar 2013 17:13:18 -0400
From: US-CERT Alerts <technical-alerts en us-cert.gov>
Organization: US-CERT - +1 202-205-5266
To: technical-alerts en us-cert.gov


National Cyber Awareness System
TA13-088A: DNS Amplification Attacks


Original release date: March 29, 2013

Systems Affected

 * Domain Name System (DNS) servers

Overview

A Domain Name Server (DNS) Amplification attack is a popular form of
Distributed Denial of Service (DDoS) that relies on the use of
publically accessible open recursive DNS servers to overwhelm a victim
system with DNS response traffic.

Description

A Domain Name Server (DNS) Amplification attack is a popular form of
Distributed Denial of Service (DDoS) that relies on the use of
publically accessible open recursive DNS servers to overwhelm a victim
system with DNS response traffic. The basic attack technique consists of
an attacker sending a DNS name lookup request to an open recursive DNS
server with the source address spoofed to be the victims address. When
the DNS server sends the DNS record response, it is sent instead to the
victim. Because the size of the response is typically considerably
larger than the request, the attacker is able to amplify the volume of
traffic directed at the victim. By leveraging a botnet to perform
additional spoofed DNS queries, an attacker can produce an overwhelming
amount of traffic with little effort. Additionally, because the
responses are legitimate data coming from valid servers, it is
especially difficult to block these types of attacks.

While the attacks are difficult to prevent, network operators can
implement several possible mitigation strategies. The primary element in
the attack that is the focus of an effective long-term solution is the
detection and elimination of open recursive DNS resolvers. These systems
are typically legitimate DNS servers that have been improperly
configured to respond to recursive queries on behalf of any system,
rather than restricting recursive responses only to requests from local
or authorized clients. By identifying these systems, an organization or
network operator can reduce the number of potential resources that the
attacker can employ in an attack.

Impact

A misconfigured Domain Name System (DNS) server can be exploited to
participate in a Distributed Denial of Service (DDoS) attack.

Solution

DETECTION

Several organizations offer free, web-based scanning tools that will
search a network for vulnerable open DNS resolvers. These tools will
scan entire network ranges and list the address of any identified open
resolvers.

Open DNS Resolver Project
http://openresolverproject.org
The Open DNS Resolver Project has compiled a list of DNS servers that
are known to serve as globally accessible open resolvers. The query
interface allows network administrators to enter IP ranges in CIDR
format [1].

The Measurement Factory
http://dns.measurement-factory.com
Like the Open DNS Resolver Project, the Measurement Factory maintains a
list of Internet accessible DNS servers and allows administrators to
search for open recursive resolvers [2]. In addition, the Measurement
Factory offers a free tool to directly test an individual DNS resolver
to determine if it allows open recursion. This will allow an
administrator to determine if configuration changes are necessary and
verify that configuration changes have been effective [3]. Finally, the
site offers statistics showing the number of open resolvers detected on
the various Autonomous System (AS) networks, sorted by the highest
number found [4].

DNSInspect
http://www.dnsinspect.com
Another freely available, web-based tool for testing DNS resolvers is
DNSInspect. This site is similar to The Measurement Factorys ability to
test a specific resolver for vulnerability, but offers the ability to
test an entire DNS Zone for several other potential configuration and
security issues [5].

Indicators

In a typical recursive DNS query, a client sends a query request to a
local DNS server requesting the resolution of a name or the reverse
resolution of an IP address. The DNS server performs the necessary
queries on behalf of the client and returns a response packet with the
requested information or an error [6, page 21]. The specification does
not allow for unsolicited responses. In a DNS amplification attack, the
key indicator is a query response without a matching request.

MITIGATION

Unfortunately, due to the overwhelming 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. While the only effective means of eliminating
this type of attack is to eliminate open recursive resolvers, this
requires a large-scale effort by numerous parties. According to the Open
DNS Resolver Project, of the 27 million known DNS resolvers on the
Internet, approximately 25 million pose a significant threat of being
used in an attack [1]. However, several possible techniques are
available to reduce the overall effectiveness of such attacks to the
Internet community as a whole. Where possible, configuration links have
been provided to assist administrators with making the recommended
changes. The configuration information has been limited to BIND9 and
Microsofts DNS Server, which are two widely deployed DNS servers. If you
are running a different DNS server, please see your vendors
documentation for configuration details.

Source IP Verification

Because the DNS queries being sent by the attacker-controlled clients
must have a source address spoofed to appear as the victims system, the
first step to reducing the effectiveness of DNS amplification is for
Internet Service Providers to deny any DNS traffic with spoofed
addresses. The Network Working Group of the Internet Engineering Task
Force released a Best Current Practice document in May 2000 that
describes how an Internet Service Provider can filter network traffic on
their network to drop packets with source addresses not reachable via
the actual packets path [7]. This configuration change would
considerably reduce the potential for most current types of DDoS
attacks.

Disabling Recursion on Authoritative Name Servers

Many of the DNS servers currently deployed on the Internet are
exclusively intended to provide name resolution for a single domain.
These systems do not need to support resolution of other domains on
behalf of a client, and therefore should be configured with recursion
disabled.

Bind9

Add the following to the global options [8]:
options {
 allow-query-cache { none; };
 recursion no;
};

Microsoft DNS Server

In the Microsoft DNS console tool [9]: * Right-click the DNS server and
click Properties.
 * Click the Advanced tab.
 * In Server options, select the Disable recursion check box, and then
click OK.

Limiting Recursion to Authorized Clients

For DNS servers that are deployed within an organization or ISP to
support name queries on behalf of a client, the resolver should be
configured to only allow queries on behalf of authorized clients. These
requests should typically only come from clients within the
organizations network address range.

BIND9

In the global options, add the following [10]:
acl corpnets { 192.168.1.0/24; 192.168.2.0/24; };
options {
 allow-query { corpnets; };
 allow-recursion { corpnets; };
};

Microsoft DNS Server

It is not currently possible to restrict recursive DNS requests to a
specific client address range in Microsoft DNS Server. The most
effective means of approximating this functionality is to configure the
internal DNS server to forward queries to an external DNS server and
restrict DNS traffic in the firewall to restrict port 53 UDP traffic to
the internal server and the external forwarder [11].

Rate Limiting Response of Recursive Name Servers

There is currently an experimental feature available as a set of patches
for BIND9 that allows an administrator to restrict the number of
responses per second being sent from the name server [12]. This is
intended to reduce the effectiveness of DNS amplification attacks by
reducing the volume of traffic coming from any single resolver.

BIND9

On BIND9 implementation running the RRL patches, add the following lines
to the options block of the authoritative views [13]:
rate-limit {
 responses-per-second 5;
 window 5;
};

Microsoft DNS Server

This option is currently not available for Microsoft DNS Server.

References

 * [1] Open DNS Resolver Project
 * [2] The Measurement Factory, "List Open Resolvers on Your Network"
 * [3] The Measurement Factory, "Open Resolver Test"
 * [4] The Measurement Factory, "Open Resolvers for Each Autonomous
System"
 * [5] "DNSInspect," DNSInspect.com
 * [6] RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES
 * [7] BCP 38: Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing
 * [8] Chapter 3. Name Server Configuration
 * [9] Disable recursion on the DNS server
 * [10] Chapter 7. BIND 9 Security Considerations
 * [11] Configure a DNS Server to Use Forwarders
 * [12] DNS Response Rate Limiting (DNS RRL)
 * [13] Response Rate Limiting in the Domain Name System (DNS RRL)

Revision History

 * March 29, 2013: Initial release

Relevant URL(s):
<http://openresolverproject.org/>

<http://dns.measurement-factory.com/cgi-bin/openresolverquery.pl>

<http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl>

<http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html>

<http://www.dnsinspect.com/>

<http://tools.ietf.org/html/rfc1034>

<http://tools.ietf.org/html/bcp38>

<http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch03.html#id2567992>

<http://technet.microsoft.com/en-us/library/cc787602.aspx>

<http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch07.html#Access_Control_Lists>

<http://technet.microsoft.com/en-us/library/cc754941.aspx>

<http://ss.vix.su/~vixie/isc-tn-2012-1.txt>

<http://www.redbarn.org/dns/ratelimits>

____________________________________________________________________

   Produced by US-CERT, a government organization.
____________________________________________________________________

This product is provided subject to this Notification:
http://www.us-cert.gov/privacy/notification/

Privacy & Use policy:
http://www.us-cert.gov/privacy/

This document can also be found at
http://www.us-cert.gov/ncas/alerts/TA13-088A

For instructions on subscribing to or unsubscribing from this
mailing list, visit http://www.us-cert.gov/mailing-lists-and-feeds/




-- 
Fernando Gont
e-mail: fernando en gont.com.ar || fgont en si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Más información sobre la lista de distribución LACNOG