The Network Time Protocol (NTP) is one of the oldest protocols still in use on the internet today. It was first used during the mid-1980s when it was created by the University of Delaware's David L. Mills. Mills, who is widely recognized as an internet pioneer, sought to create an internet protocol (IP) that synchronizes the internal clock of a computer.
The NTP protocol has seen a great deal of abuse and misuse since its inception. This can arguably be traced back to the year 2002. In more recent times, a particular type of Distributed-Denial-of-Service (DDoS attack), which uses the NTP protocol, has become an ever-present threat. Though the idea of NTP amplification is not new, since the year 2014, hackers have successfully DDoS’d countless targets with it.
The most significant incident involving an NTP amplification DDoS was in 2014, where Cloudflare servers were directly targeted by a DDoS attack that alarmed even the CEO of the company (he called it “the start of ugly things to come”). At the time, at 400 Gbps, this was once of the largest DDoS attacks ever. For an attack to surprise a company known for strong DDoS protection, this should give you some idea of just how powerful NTP amplification can be.
As this is the case, it is vital for security professionals and leaders in charge of security policy to understand NTP amplification attacks. Though the attack has been overshadowed by other, more powerful attacks, it is still very much a threat. By the time you are finished reading this primer, you will not merely understand an NTP amplification DDoS attack, but also be able to defend against it.
An NTP amplification DDoS attack, put simply, exploits public Network Time Protocol servers to overload a target with a botnet. For the uninitiated, a botnet is a set of machines (called “zombies”) that are used in a DDoS attack. They are controlled by the attacker using a Command-and-Control (C2) server and use their large numbers to overload a target. In the case of an NTP amplification, the DDoS occurs via the User Datagram Protocol (UDP). UDP does not require any response (like the TCP/IP three-way SYN-SYN/ACK-ACK handshake) to send packets. For this reason, it is easier to create a Denial-of-Service (DoS) situation that knocks a server or network offline.
The NTP amplification attack is possible due to a flaw in the design of the Network Time Protocol. NTP has an inherent monitoring service that allows sysadmins to check traffic counts of connected clients. Using the “get monlist” command, an attacker can leverage this monitoring service’s abilities to spoof their address to be that of the victim’s. For reference, “monlist” allows an administrator to see roughly 600 of the most recent clients to connect to the server.
What eventually happens is the UDP traffic overloads the server and renders it inoperable. The administrator is none the wiser as they see all the traffic as belonging to a legitimate user.
While this is a brief overview, it is necessary to understand the NTP DDoS attack step-by-step. Only then can individuals in charge of servers learn how to defend against it.
The unfortunate reality with NTP amplification attacks is that there are very few ironclad solutions. A lot of this has to do with the age of the protocol. Older protocols are prone to exploitation on a greater scale simply because threats present in the 1980s have multiplied exponentially since then. We have computers with processing power that makes computers of old seem like primitive technology. When the internet went public in the mid-1990s, the idea of cellular phones like those we have today would be considered science fiction. With other smart devices all connecting to the Internet-of-Things, botnet creation is easier than ever before.
There are, however, some things that can be done to mitigate an NTP amplification DDoS attack. As was noted frequently throughout this report, the “monlist” command is key to exploiting an NTP server. Depending on the server used, it is possible to install a patch that disables the “monlist” command. The tricky thing with this is that the patch must be 4.2.7 or above. Many NTP servers are legacy servers and cannot support this patch. As such, there is another workaround that must be implemented for mitigation. On a public-facing NTP server, US-CERT recommends legacy systems input the “noquery” command to the “restrict default” system configuration. If executed properly, it will disable the “monlist” command.
These mitigation tactics may still not be enough. Depending on the size of your organization, it may be necessary to employ third-party services. Even the strongest networks can be crippled by a properly deployed botnet attack. As this is the case, a third-party service that can scatter network traffic may be necessary. It will then put the server load on more than just the targeted network, and instead take some of the heat off so that the spoofed traffic does not all reach the same server.