400 Gbps NTP Amplification Attack Alarmingly Simple

Attackers used one server in a massive DDoS attack against an organization in Europe, generating 400 Gbps of bad traffic at its peak via NTP amplification.

The largest distributed denial of service attack on public record was reported this week, and with it came many alarming numbers, not only in the volume of traffic generated (400 Gbps at its peak), but in the number of Network Time Protocol servers involved (4,592 on 1,298 networks) as well as the traffic each server directed to the victim (87 Mbps). The scariest number of all, however, may be the number 1.

“Remarkably, it is possible that the attacker used only a single server running on a network that allowed source IP address spoofing to initiate the requests,” said CloudFlare CEO Matthew Prince, whose company reported the attack on Monday against one of its customers, an unnamed organization in Europe.

The simplicity of the NTP amplification attack has potential targets on edge. U.S. banks have already had their share of angst dealing with DNS amplification attacks that disrupted services throughout last year in politically motivated attacks. And one year ago, a massive DDoS against spam blacklist provider Spamhaus topped out at 300 Gbps, to date the biggest firehose of traffic directed at one target.

The use of NTP amplification as a DDoS attack technique opens a number of possibilities for attackers to try their hand at exploiting weaknesses in other foundational protocols such as SNMP, which is used to manage network devices. Prince warned in a blogpost today that attackers are already testing those waters.

“If you think NTP is bad, just wait for what’s next. SNMP has a theoretical 650x amplification factor,” Prince said. “We’ve already begun to see evidence attackers have begun to experiment with using it as a DDoS vector. Buckle up.”

Prince told Threatpost on Tuesday that the large attack lasted a couple of hours and had been mitigated by late Monday. A large webhost based in France, OVH, was also a victim according to CloudFlare and Arbor Networks; it saw volumes of traffic approaching 325 Gbps, and other attacks starting last weekend against other targets in France hitting up 80 Gbps. OVH, Prince said, was also a principle source in the attack against its customer.

“At some level, stopping an attack like this requires having more resources than the attacker is able to muster,” Prince said. “NTP attacks are definitely on the rise. Because the amplification factor per misconfigured server can be 10x as large as a typical DNS amplification attack, they pose a significant risk.”

Prince recommended that network administrators test whether they’re running misconfigured NTP servers at the Open NTP Project website.

NTP is a protocol used to synchronize time on computer clocks; experts call it a set-and-forget feature on networks, but attackers have been able to ferret out a weakness in a feature called MONLIST, which returns the IP address of the last 600 machines interacting with an NTP server. Attackers exploiting the exposed feature are able to query NTP servers for traffic counts using the victim’s spoofed source address. In return, the response is much larger than the original request, and with enough vulnerable NTP servers returning requests, a website and/or services are quickly overrun with UDP packets over port 123. NTP servers that allow source IP address spoofing and do not follow BCP38, a standard that defines how to defeat IP source address spoofing, are liable to become sources of future DDoS attacks.

“I’d personally be curious to talk with whoever added MONLIST as a command to NTP servers,” Prince said. “The command seems of such little practical use — it returns a list of up to the last 600 IP addresses that last accessed the NTP server — and yet it can do so much harm.”

Prince said a fully populated NTP list can generate a response to a MONLIST request that is 206 times larger than the request.

“In the attack, since the source IP address is spoofed and UDP does not require a handshake, the amplified response is sent to the intended target,” Prince said. “An attacker with a 1Gbps connection can theoretically generate more than 200Gbps of DDoS traffic.”

A US-CERT advisory in January warned of the potential for harm from NTP amplification attacks; it recommends moving off vulnerable versions of NTP, prior to 4.2.7, that are publically accessible. It is also possible to manually disable the MONLIST feature in NTP servers, which would mitigate attacks.

“NTP amplification can achieve as much as a 10x the amplification factor as more common DNS reflection attacks,” Prince said. “This makes an improperly secured NTP server significantly more dangerous than an open DNS resolver.”

Suggested articles


  • Brian m on

    Love the comment about ' like to talk to the person who added monlist'! There are so many idiots who are involved in standards etc. They just don't get it that the more features you add the bigger the attack area is. JavaScript and web browsers will become/are a threat because of creeping functionality.
  • Brian McNett on

    One needs to be more careful, and understand the history of a protocol better before casting aspersions at random people. The "idiot" who added monlist to NTP is Dr. David L. Mills, Ph.D., and he added it when he wrote it in 1981. I'm quite certain that it made perfect sense at the time. However, Dr. Mills recommended, over fifteen years ago, that the entirety of the mode 7 commands in NTP be removed, as they were of limited utility. It is therefore not *his* fault that the command still exists in the spec, and that people still implement it. The full brunt of the blame lies in the RFC process. Dr. Mills has moved on, failing to get the support he needed to re-write the RFC.
  • Chris R. on

    Note that the piece states this can arise from a "mis-configured" NTP server. Quite right. Beside the recommended solution from the US-CERT, it's simple to fix the problem. Use the "restrict noquery" option in your ntp.conf file. The article mentions "disable monitor", which has some of the same effects. The point is, in a correctly configured network, this need not be a problem.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.