Over the last couple of weeks you may have been hearing about a new tool in the DDoS arsenal: NTP-based attacks. These have become popular recently and caused trouble for some gaming web sites and service providers. We'd long thought that NTP might become a vector for DDoS attacks because, like DNS, it is a simple UDP-based protocol that can be persuaded to return a large reply to a small request. Unfortunately, that prediction has come true.
This blog post explains how an NTP-based attack works and how web site owners can help mitigate them. CloudFlare defends web sites against NTP based attacks, but it's best to stem the flow of NTP-based DDoS by making simple configuration changes to firewalls and NTP servers. Doing so makes the web safer for everyone.
DNS Reflection is so 2013
We've written in the past about DNS-based reflection and amplification attacks and NTP-based attacks use similar techniques, just a different protocol.
A reflection attack works when an attacker can send a packet with a forged source IP address. The attacker sends a packet apparently from the intended victim to some server on the Internet that will reply immediately. Because the source IP address is forged, the remote Internet server replies and sends data to the victim.
That has two effects: the actual source of the attack is hidden and is very hard to trace, and, if many Internet servers are used, an attack can consist of an overwhelming number of packets hitting a victim from all over the world.
But what makes reflection attacks really powerful is when they are also amplified: when a small forged packet elicits a large reply from the server (or servers). In that case, an attacker can send a small packet "from" a forged source IP address and have the server (or servers) send large replies to the victim.
Amplification attacks like that result in an attacker turning a small amount of bandwidth coming from a small number of machines into a massive traffic load hitting a victim from around the Internet. Until recently the most popular protocol for amplification attacks was DNS: a small DNS query looking up the IP address of a domain name would result in a large reply.
For DNS the amplification factor (how much larger a reply is than a request) is 8x. So an attacker can generate an attack 8x larger than the bandwidth they themselves have access to. For example, an attacker controlling 10 machines with 1Gbps could generate an 80Gbps DNS amplification attack.
In the past, we've seen one attack that used SNMP for amplification: it has a factor of 650x! Luckily, there are few open SNMP servers on the Internet and SNMP usually requires authentication (although many are poorly secured). That makes SNMP attacks relatively rare.
The new kid on the block today is NTP.
Network Time Protocol attacks: as easy as (UDP port) 123
NTP is the Network Time Protocol that is used by machines connected to the Internet to set their clocks accurately. For example, the address time.euro.apple.com seen in the clock configuration on my Mac is actually the address of an NTP server run by Apple.
My Mac quietly synchronizes with that server to keep its clock accurate. And, of course, NTP is not just used by Macs: it is widely used across the Internet by desktops, servers and even phones to keep their clocks in sync.
Unfortunately, the simple UDP-based NTP protocol is prone to amplification attacks because it will reply to a packet with a spoofed source IP address and because at least one of its built in commands will send a long reply to a short request. That makes it ideal as a DDoS tool.
NTP contains a command called monlist (or sometimes MON_GETLIST) which can be sent to an NTP server for monitoring purposes. 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.
To get an idea of how much larger, I used the ntpdc command to send a monlist command to a randomly chosen open NTP server on the Internet. Here are the request and response packets captured with Wireshark.
At the command line I typed
ntpdc –c monlist 1xx.xxx.xxx.xx9
to send the MON_GETLIST command to the server at 1xx.xxx.xxx.xx9. The request packet is 234 bytes long. The response is split across 10 packets totaling 4,460 bytes. That's an amplification factor of 19x and because the response is sent in many packets an attack using this would consume a large amount of bandwidth and have a high packet rate.
This particular NTP server only had 55 addresses to tell me about. Each response packet contains 6 addresses (with one short packet at the end), so a busy server that responded with the maximum 600 addresses would send 100 packets for a total of over 48k in response to just 234 bytes. That's an amplification factor of 206x!
An attacker, armed with a list of open NTP servers on the Internet, can easily pull off a DDoS attack using NTP. And NTP servers aren't hard to find. Common tools like Metasploit and NMAP have had modules capable of identifying NTP servers that support monlist for a long time. There's also the Open NTP Project which aims to highlight open NTP servers and get them patched.
Don't be part of the problem
If you're running a normal NTP program to set the time on your server and need to know how to configure it to protect your machine, I suggest Team Cymru's excellent page on a Secure NTP Template. It shows how to secure an NTP client on Cisco IOS, Juniper JUNOS or using iptables on a Linux system.
If you're running an ntpd server that needs to be on the public Internet then it's vital that it's upgraded to at least version 4.2.7p26 (more details in CVE-2013-5211). The vulnerability was classed as a bug in the ntpd bug database (issue 1532).
If you are running an ntpd server and still need something like monlist there's the mrulist command (see issue 1531) which now requires a nonce (a proof that the command came from the IP address in the UDP packet).
Neither of these changes are recent, ntpd v4.2.7p26 was released in March 24, 2010, so upgrading doesn't require using bleeding edge code.
If you're running a network (or are a service provider) then it's vital that you implement BCP-38. Implementation of it (and the related BCP-84) would eliminate source IP spoofed attacks of all kinds (DNS, NTP, SNMP, ...).
Further Reading
If you're interested in further background on reflection and amplification attacks, take a look at my October 2013 presentation "How to launch and defend against a DDoS".
How to launch and defend against a DDoS from jgrahamc
Footnote
The black and white photograph at the top of this blog post shows the UK's original speaking clock and the original voice of the clock Jane Cain. A common way to synchronize clocks and watches was to telephone the speaking clock to get the precise time.
Geeks like me will be amused that the NTP UDP port for time synchronization is 123 and that the telephone number of the UK speaking clock is also 123. Even today dialing 123 in the UK gets you the time.