UDP reflections attacks are a popular cyberattack vector due to the relative ease in amplifying the bandwidth an attacker has into a much bigger stream of data to point at the target. They're a huge threat to modern, tech-driven businesses and something that our cloud consultants have experienced before. So, let's dig deeper into this modern menace...

What is an Amplified UDP Reflection DDOS attack? 

UDP Amplified Reflection Attacks are where the attacker uses the connectionless UDP protocol to ask a server for some piece of information, however by forging the packet header so it contains a different sender address an attacker can make it appear that the packet was sent by a different machine (In this case the Target machine). The machine that receives spoofed packets will send a response back to the forged source address, which means that this technique is mainly used when the attacker does not care about the response or the attacker has some way of guessing the response.

A quick recap on some of the terms:

Denial-of-service (DoS) or distributed denial-of-service (DDoS)

An attack that's an attempt to make a machine or network resource unavailable to its intended users. One common method of attack involves flooding the target machine with requests, so much so that it cannot respond to legitimate traffic, or that it responds so slowly as to be rendered essentially unavailable.



There are two types of Internet Protocol (IP) traffic on the internet (as well as many other non IP based protocols), they are TCP or Transmission Control Protocol and UDP or User Datagram Protocol. TCP is a connection oriented bidirectional steam of data whereas UDP is a simpler, connectionless Internet protocol that is used for sending information in one direction. TCP uses a ThreeWayHandshake to confirm both parties are able to talk to each other and are in sync. UDP on the other hand just send the data roughly towards its intended recipient and never cares or checks if it arrived or where it went.


ICMP, NTP, DNS, DHCP, TFTP, SNMP, RIP, VOIP are all examples of UDP services which if left unchecked can be abused, depending on the command sent and data requested the amplification ratio can range from 2x to over 200x. This is to say that the attacker sends a small request to the vulnerable server and the server sends a much larger response to the Target system. If you then add this to the Distributed model of a generic DDOS attack you can see how quite quickly the action of 1 attacker has been amplified to much larger levels.


Sending a PING to a server while spoofing your source IP will cause the response to be sent to the target. The request is almost the same size as the response which gives almost no amplification.

Open DNS Servers (As used to generate a 75GB/s DDOS against SpamHaus.org in March 2013)

The attacker was requesting the DNS zone file for ripe.net from open DNS resolvers while spoofing the source IP in their DNS requests pretending to be SpamHaus’s web server.

Each request was approximately 36 bytes long (e.g. ‘dig ANY ripe.net @X.X.X.X +edns=0 +bufsize=4096, where X.X.X.X is replaced with the IP address of an open DNS resolver), from this request each response was approximately 3,000 bytes. This is around 100x amplification.

NTP Monlist

"NTP contains a command called monlist which can be sent to an NTP server for monitoring purposes," CloudFlare explained in January. "It returns the addresses of up to the last 600 machines that the NTP server has interacted with. This response is much bigger than the request sent making it ideal for an amplification attack."

So a busy server that responds with the maximum 600 addresses would send 100 packets for a total of over 48kb in response to just a 234 byte request. - That’s an amplification ratio of 206xDon’t fall behind the times. Discover how the cloud can help you solve business  challenges and achieve greater value. Get in touch with our consultants today.


Various SNMP commands can be used for amplification and in fact can create a 650x amplification ratio if well targeted however comparatively there are much fewer open SNMP servers on the Internet to be used to amplify attacks and SNMP usually requires authentication (although many are poorly secured with default passwords). That makes SNMP attacks thankfully relatively rare.


Even if we purged the internet of all open DNS resolvers, NTP servers with MonList enabled and publically available SNMP servers there will probably be another vulnerable service found and exploited even harder.  I would not be surprised to see DDOS attacks growing to over 500GB/s within the year.

Problems this causes for the rest of us:

  • While you may not be the actual target of the attack if your network provide also provides services to the victim under attack the amount of garbage traffic they are receiving, having to process and deal with may cause hardware that is shared between you and the victim to clog up or even fail completely leaving you offline as well.

  • Service Providers are having to install larger and faster hardware at an ever-increasing rate to keep up with the levels of traffic being generated to try and soak up these attacks to stop them from causing mass outages

  • An extra burden is placed on the servers and devices being used to reflect traffic.

What has been done to stop them already?

  • The OpenNTPProject provides information and tools to scan network servers in order to determine if there are any NTP servers that can be abused.

  • The OpenResolverProject provides information and tools to scan network servers in order to determine if there are any DNS servers that can be abused.

These only go so far and offer the ability to check if your systems are vulnerable, what can be done to actually stop these attacks? There are many things that need to happen to completely remove this attack vector from the internet as a whole but here are just a couple of things that would largely reduce the problem.

  • Implement BCP-38 - Given all of these attacks all use the same flaw in UDP (IP Spoofing) to send the traffic to the target instead of back to the attacker. Implementation of it (and the related BCP-84) would eliminate source IP spoofed attacks of all kinds (DNS, NTP, SNMP, ...)

  • Vendors and developers of operating systems, network infrastructure devices such as routers and switches, vendors of home broadband devices, etc. should ship their devices with secure defaults. Secure defaults include:

  • Not running services such as NTP servers and DNS recursors by default

  • Ensuring that the default configuration of these services do not lend themselves to abuse - e.g:

  • Don’t allow level-6/-7 commands such as monlist by default on NTP servers from the global Internet

  • Prevent any embedded or enabled DNS recursive servers from being accessed as open precursors

  • Block outbound traffic that claims to originate from IP address that can’t be on the inside

Mitigate threats to your system

These attacks could be almost entirely mitigated by system administrators service providers, and dedicated cloud consulting support teams implementing BCP-38/ BCP-84 to block traffic with bogus sender IPs and by not leaving devices in the default insecure state provide by many manufacturers.

New call-to-action