Overview

DDoS (Distributed Denial-of-Service) attacks are used to render computer or information systems inaccessible. Attackers can abuse different network protocols in order to achieve their goals. In the past years, TCP protocol was regularly used to conduct Denial-of-Service attacks, but abuse of UDP protocols recently increased. UDP protocols provide many advantages for the attackers, e.g. IP address spoofing or stateless-connectivity. Some open (e.g. public NTP) services and inadvertently (e.g. SIP or Chargen) unfiltered services relying on UDP protocols are still widely open on the Internet and consequently accessible to potential abuse. In this document, recommendations are proposed to system and network administrators in order to minimize the risks associated with open services relying on UDP protocols.

Terminology

An amplification attack is a specific type of Denial-of-Service attacks which takes advantage of a protocol design. When such a protocol is queried, it generates a larger response than the query.

A reflection attack is a precondition to a successful amplification attack. We speak about reflection attacks when an attacker is able to send packets with spoofed source IP addresses. Due to the spoofed addresses, the packets are then sent back to the victims and not the attackers.

The reflection attack on authentication systems is not related to the network attack mentioned in this document.

Recommendations

Update your software

As you can see below, software relying on UDP protocols (e.g. discard services, DNS, SIP, NTP or UPnP - SSDP services) can be abused for amplification (the number of bytes the service is sending out to the victim is higher than the attacker sends to the service). We recommend to keep the software updated with the latest version to ensure that known vulnerabilities are fixed. For unknown vulnerabilities, the recommendations given below should be implemented in order to limit the impact of UDP amplification attacks.

Limiting UDP listening ports

One of the cleanest options in order to limit UDP amplification is to limit the access to the UDP services. Setting up access to the network services is usually configured at application level (e.g. NTP services) or via the super-server (e.g. chargen or similar services) daemon handling the UDP connectivity. If the services are only needed locally on the same system, we recommend to change network binding configuration to localhost only (do not to forget to include IPv6 addresses, too). On routers or home devices, we recommend to disable the SSDP services from any external interfaces and disable the remote administration of the devices from Internet.

Multicast or link-local UDP services

In some cases, services relying on UDP protocols (e.g. NTP) use multicast as method to provide the service at the network level. If you don’t need the multicast service, we recommend to disable it.

Border UDP filtering

An effective way to limit the risks of amplification attacks relying on UDP protocols is to filter out traffic coming into your networks. As an example, if you have private NTP (Network Time Protocol) services, incoming packets should not be allowed to reach your NTP services. A filtering rule can be applied on your border infrastructure in order to exclude the incoming UDP packet towards such services. As the filtering might have a strong impact on operational networks, we recommend to configure the filtering as the last solution when proper configuration of UDP services cannot be done on the system directly.

Disable DNS Open Recursion

DNS servers should not allow open recursion from the Internet. We recommend to disable DNS recursion from the Internet.

You can test your nameserver using the following dig command to query openresolvers.org project:

dig +short amiopen.openresolvers.org TXT

or nslookup on Windows platforms:

nslookup
> set type=TXT
> amiopen.openresolvers.org

The answer should be “Your resolver at <IP address> is CLOSED”. However, if the resolver is reported as OPEN, the configuration of the DNS server needs to be reviewed.

References

Examples of Sofware Vulnerabilities Causing UDP amplification

CVE-2013-5211 The monlist feature in ntp_request.c in ntpd in NTP before 4.2.7p26 allows remote attackers to cause a denial of service (traffic amplification) via forged (1) REQ_MON_GETLIST or (2) REQ_MON_GETLIST_1 requests, as exploited in the wild in December 2013.
CVE-2008-1923 The IAX2 channel driver (chan_iax2) in Asterisk 1.2 before revision 72630 and 1.4 before revision 65679, when configured to allow unauthenticated calls, sends “early audio” to an unverified source IP address of a NEW message, which allows remote attackers to cause a denial of service (traffic amplification) via a spoofed NEW message.
CVE-2006-0987 The default configuration of ISC BIND before 9.4.1-P1, when configured as a caching name server, allows recursive queries and provides additional delegation information to arbitrary IP addresses, which allows remote attackers to cause a denial of service (traffic amplification) via DNS queries with spoofed source IP addresses.
CVE-2012-3411 Dnsmasq before 2.63test1, when used with certain libvirt configurations, replies to requests from prohibited interfaces, which allows remote attackers to cause a denial of service (traffic amplification) via a spoofed DNS query

Classification of this document

TLP:WHITE information may be distributed without restriction, subject to copyright controls.

Revision

Version 1.3 July 8, 2015 SSDP added and RIPv1 reflection added (TLP:WHITE)
Version 1.2 February 14, 2014 Game server example added (TLP:WHITE)
Version 1.1 January 24, 2014 Terminology clarification (TLP:WHITE)
Version 1.0 January 23, 2014 Initial version (TLP:WHITE)

TR-19 - UDP Protocols Security - Recommendations To Avoid or Limit DDoS reflection / amplification