TA14-017A: UDP-Based Amplification Attacks

["US-CERT" <US-CERT () ncas us-cert gov>]

Header with DHS and US-CERT logos

TA14-017A:UDP-Based Amplification Attacks [ https://www.us-cert.gov/ncas/alerts/TA14-017A ]
Original release date: January 17, 2014 | Last revised [ https://www.us-cert.gov/ncas/alerts/TA14-017A#revisions ]: 
April 13, 2016 
Systems Affected

Certain application-layer protocols that rely on User Datagram Protocol (UDP) have been identified as potential attack 
vectors:


  * DNS 
  * NTP 
  * SNMPv2 
  * NetBIOS 
  * SSDP 
  * CharGEN 
  * QOTD 
  * BitTorrent 
  * Kad 
  * Quake Network Protocol 
  * Steam Protocol 
  * RIPv1 
  * Multicast DNS (mDNS) 
  * Portmap/RPC 

Overview

A Distributed Reflective Denial of Service (DRDoS) attack is a form of Distributed Denial of Service (DDoS) that relies 
on the use of publicly accessible UDP servers, as well as bandwidth amplification factors, to overwhelm a victim system 
with UDP traffic.

Description

UDP, by design, is a connection-less protocol that does not validate source IP addresses. Unless the application-layer 
protocol uses countermeasures such as session initiation in VOIP (voice over IP), it is very easy to forge the IP 
packet datagram to include an arbitrary source IP address [1 [ http://tools.ietf.org/html/rfc3261 ]]. When many UDP 
packets have their source IP address forged to the victim IP address, the destination server (or amplifier) responds to 
the victim (instead of the attacker), creating a reflected Denial of Service (DoS) Attack.

Recently, certain UDP protocols have been found to have particular responses to certain commands that are much larger 
than the initial request. Previously, attackers were limited linearly by the number of packets directly sent to the 
target to conduct a DoS attack; now a single packet can generate tens or hundreds of times the bandwidth in its 
response. This is called an amplification attack, and when combined with a reflective DoS attack on a large scale using 
multiple amplifiers and targeting a single victim, DDoS attacks can be conducted with relative ease.

To measure the potential effect of an amplification attack, a metric called the bandwidth amplification factor (BAF) is 
used. BAF can be calculated as the number of UDP payload bytes that an amplifier sends to answer a request, compared to 
the number of UDP payload bytes of the request [2 [ http://www.christian-rossow.de/articles/Amplification_DDoS.php ]] 
[3 [ http://www.christian-rossow.de/publications/amplification-ndss2014.pdf ]].

The list of known protocolsand their associated bandwidth amplification factorsare listed below. US-CERT offers thanks 
to Christian Rossow for providing this information. For more information on bandwidth amplification factors, please see 
Christian's blog [ http://www.christian-rossow.de/articles/Amplification_DDoS.php ] and associated research paper [ 
http://www.christian-rossow.de/publications/amplification-ndss2014.pdf ].

*Protocol**Bandwidth Amplification Factor**Vulnerable Command* DNS 28 to 54 see: TA13-088A [ 
http://www.us-cert.gov/ncas/alerts/TA13-088A ][4] NTP 556.9 see: TA14-013A [ 
http://www.us-cert.gov/ncas/alerts/TA14-013A ][5] SNMPv2 6.3 GetBulk request NetBIOS 3.8 Name resolution SSDP 30.8 
SEARCH request CharGEN 358.8 Character generation request QOTD 140.3 Quote request BitTorrent 3.8 File search Kad 16.3 
Peer list exchange Quake Network Protocol 63.9 Server info exchange Steam Protocol 5.5 Server info exchange Multicast 
DNS (mDNS) 2 to 10 Unicast query RIPv1 131.24 Malformed request Portmap (RPCbind) 7 to 28 Malformed request 

In March 2015, Software Engineering Institute CERT issued Vulnerability Note (VU#550620) describing the use of mDNS in 
DRDoS attacks. Attackers can leverage mDNS by sending more information than can be handled by the device, thereby 
causing a DoS. [6 [ http://www.kb.cert.org/vuls/id/550620 ]]

In July 2015, Akamai Technologies' Prolexic Security Engineering and Research Team (PLXsert) issued a threat advisory 
describing a surge in DRDoS attacks using the Routing Information Protocol version one (RIPv1). Malicious actors are 
leveraging the behavior of RIPv1 for DDoS reflection through specially crafted request queries [7 [ 
http://www.stateoftheinternet.com ]].

In August 2015, Level 3 Threat Research Labs reported a new form of DRDoS attack that uses portmap. Attackers leverage 
the behavior of the portmap service through spoofed requests and flood a victims network with UDP traffic. [8 [ 
http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-early-warning-to-the-industry/ ]]

Impact

Attackers can utilize the bandwidth and relative trust of large servers that provide the above UDP protocols to flood 
victims with unwanted traffic, a DDoS attack.

Solution

DETECTION

Detection of DRDoS attacks is not easy because of their use of large, trusted servers that provide UDP services. 
Network operators of these exploitable services may apply traditional DoS mitigation techniques. To detect a DRDOS 
attack, watch out for abnormally large responses to a particular IP address, which may indicate that an attacker is 
using the service.

If you are a victim of DRDoS attack, there are a few things you can do to detect such activity and respond:


  * Detect and alert large UDP packets to higher order ports. 
  * Detect and alert on any non-stateful UDP packets. (A simple snort example is below. You will need to customize this 
approach to your environment with whitelist and known services.) 
Simple Snort rule example for stateless UDP check var HOME_NET [10.10.10.20]
preprocessor stream5_global: track_ip yes, track_tcp yes,track_udp yes,track_icmp no,max_tcp 262144, max_udp 131072
preprocessor stream5_ip: timeout 180
preprocessor stream5_tcp: policy first, use_static_footprint_sizes
preprocessor stream5_udp: timeout 180, ignore_any_rules
alert udp HOME_NET 1024: -> any any (msg:"UDP Session start"; flowbits:set,logged_in; flowbits:noalert; sid: 1001;)
alert udp any any -> HOME_NET 1024: (msg:"UDP Stateless"; flowbits:isnotset,logged_in; sid: 1002) 

  * If you are an upstream provider maintain updated contacts and methods with downstream customers to send alerts by 
network. 

In general, network and server administrators for Internet service providers (ISPs) should use the following best 
practices to avoid becoming amplifier nodes:


  * Detect spoofed packets using network flow. (In order to validate before blocking it, read more in the Mitigation 
section on blocking spoofed traffic.) 
  * Monitor for an unusual number of requests to UDP services at risk using network flow or other summarized network 
data. 
  * Use network flow to detect service anomalies (bytes-per-packet, packets-per-second anomalies). 

MITIGATION

If you are a victim of DRDoS attack there are a few things you can do to mitigate this attack:


  * Use stateful UDP inspection to reduce impact on critical services on your border firewall or border router (like 
reflexive ACL _[9 [ http://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfreflx.html 
]]_) 
  * Using Border Gateway Protocol (BGP), create a Remotely Triggered Blackhole, preferably in coordination with your 
upstream provider or ISP. [10 [ http://packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/ ]] 
  * Maintain a list of primary upstream provider emergency contacts to coordinate response to the attack. If you are an 
upstream provider, conduct mitigation in coordination with your downstream customers. 

In general, network and server administrators for Internet service providers (ISPs) should use the following as best 
practices to avoid becoming amplifier nodes:


  * Keep your software and configuration up to date to deny or limit abuse (e.g., DNS response rate limit [11 [ 
https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html ]] [12 [ 
http://tools.ietf.org/html/bcp38 ]] [13 [ http://tools.ietf.org/html/bcp84 ]]) 
  * Disable and remove unwanted services or deny access to local services over the Internet. 
  * Enable network-based rate-limiting to legitimate services you provide over the Internet using UDP-based protocols 
(e.g., quality of service (QoS) on switching and routing devices) 
  * Work with Customer Provider Edge manufactures for secure configuration and software [14 [ 
http://resources.sei.cmu.edu/asset_files/WhitePaper/2014_019_001_312679.pdf ]] 

As a service provider, to avoid any misuse of Internet resources


  * Block spoofed packets by using ingress filtering (the Spoofer Project [ http://spoofer.caida.org/ ][15 [ 
http://spoofer.caida.org/ ]] and IETF BCP 28 and BCP 39 guidelines [16 [ 
http://resources.sei.cmu.edu/asset_files/WhitePaper/2014_019_001_312679.pdf ]]) 
  * Use traffic shaping on UDP service requests to ensure repeated access to over-the-internet resources is not 
abusive.[17 [ http://tools.ietf.org/html/rfc2475 ]] [18 [ http://tools.ietf.org/html/rfc3260 ]] 

References

  * [1] SIP: Session Initiation Protocol [ http://tools.ietf.org/html/rfc3261 ] 
  * [2] Amplification Hell: Abusing Network Protocols for DDoS [ 
http://www.christian-rossow.de/articles/Amplification_DDoS.php ] 
  * [3] Amplication Hell: Revisiting Network Protocols for DDoS Abuse [ 
http://www.christian-rossow.de/publications/amplification-ndss2014.pdf ] 
  * [4] DNS Amplification Attacks [ http://www.us-cert.gov/ncas/alerts/TA13-088A ] 
  * [5] NTP Amplification Attacks Using CVE-2013-5211 [ http://www.us-cert.gov/ncas/alerts/TA14-013A ] 
  * [6] VU#550620: Multicast DNS (mDNS) implementations may respond to unicast queries originating outside the local 
link [ http://www.kb.cert.org/vuls/id/550620 ] 
  * [7] RIPv1 Reflection DDoS [Medium Risk] [ 
http://www.stateoftheinternet.com/resources-web-security-threat-advisories-2015-ripv1-reflection-ddos.html ] 
  * [8] A New DDoS Reflection Attack: Portmapper; An Early Warning to the Industry [ 
http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-early-warning-to-the-industry/ ] 
  * [9] Configuring IP Session Filtering (Reflexive Access Lists) [ 
http://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfreflx.html ] 
  * [10] Remotely-Triggered Black Hole (RTBH) Routing [ 
http://packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/ ] 
  * [11] A Quick Introduction to Response Rate Limiting [ 
https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html ] 
  * [12] Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing [ 
http://tools.ietf.org/html/bcp38 ] 
  * [13] Ingress Filtering for Multihomed Networks [ http://tools.ietf.org/html/bcp84 ] 
  * [14] Abuse of Customer Premise Equipment and Recommended Actions [ 
http://resources.sei.cmu.edu/asset_files/WhitePaper/2014_019_001_312679.pdf ] 
  * [15] The Spoofer Project [ http://spoofer.caida.org/ ] 
  * [16] Abuse of Customer Premise Equipment and Recommended Actions [ 
http://resources.sei.cmu.edu/asset_files/WhitePaper/2014_019_001_312679.pdf ] 
  * [17] An Architecture for Differentiated Services [ http://tools.ietf.org/html/rfc2475 ] 
  * [18] New Terminology and Clarifications for Diffserv [ http://tools.ietf.org/html/rfc3260 ] 

Revisions

  * February 9, 2014  Initial Release 
  * March 7, 2014  Updated page to include research links 
  * July 13, 2015  Added RIPv1 as an attack vector 
  * August 19, 2015  Added Multicast DNS (mDNS) and Portmap (RPCbind) as attack vectors 
  * April 13, 2016  Updated detection and mitigation information 
________________________________________________________________________

OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] | Security Publications [ 
http://www.us-cert.gov/security-publications ] | Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources [ 
http://www.us-cert.gov/related-resources ] 

STAY CONNECTED: Sign up for email updates [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ]