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 websites and service providers. It has long been thought that NTP might become a route for a DDoS attack, 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 website owners can help mitigate them. You can 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 “fresh”
You may have heard of DNS based reflection attacks, 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.
The 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.
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, …).