MCNC Security Advisory 2014.001

NTP Server Vulnerability Could Lead to DDoS Attacks

General Information

Executive Summary

In late December 2013, details began to emerge about an increase in Distributed Denial of Service (DDoS) attacks leveraging a weakness in older versions of Network Time Protocol (NTP) server software. The weakness allows an attacker to send requests to vulnerable NTP servers and cause those servers to direct large volumes of data at intended targets.

This type of attack is known as a “reflection” attack because it allows the attacker to “bounce” the attack off of a vulnerable server and cause that server to attack the intended victim. These types of attacks can often cause Denial of Service (DoS) conditions for both the target of the attack, as well as the operators of the vulnerable NTP server.

MCNC has observed multiple instances of unusually large volumes of NTP traffic emanating from constituents on the NCREN network. Indications are that these constituents are running vulnerable NTP servers on their networks that are being used as part of a DoS attack against external targets. In order to help prevent these attacks, MCNC is releasing this security advisory to all constituents, providing information about the issue, as well as suggested actions that constituents can take to protect themselves from these attacks. 

Advisory Details

Details of the Issue

The Network Time Protocol (NTP) is commonly used to synchronize system clocks between network-connected systems. The protocol is based on UDP and is run over port 123.

A new attack technique has emerged recently that reflects and amplifies attacks by bouncing them off of vulnerable NTP servers. These attacks are similar to DNS amplification attacks that have been popular for some time. The attacks work like this:

  • The attacker sends a small, forged packet to a vulnerable NTP server. The forged packet requests that a large amount of NTP data be returned to the requestor.
  • In the original forged packet, the attacker has spoofed the source IP address, setting this address to the address of the intended target of the DDoS attack.
  • When the vulnerable NTP server responds to the request for NTP data, it sends the response to the spoofed IP address. The victim of the DDoS attack is now flooded with NTP data that it did not request.

These attacks are usually multiplied by using many vulnerable NTP servers at the same time. In many cases, the attacks cause DoS conditions for both the target of the attack (spoofed IP address), as well as the vulnerable NTP server.

NTP servers are vulnerable if they respond to external requests for the monlist command. This command is used to return a list of recent NTP clients that have contacted the NTP server. For a busy NTP server, this list can be large. Very small requests by the attacker can cause the NTP server to return megabytes of data for each request.

As described above, an attacker will make a large number of requests for the server to return the results of the monlist query, directing the responses to be sent to the intended victim of the DDoS attack.

Suggested Actions

The information below provides a list of some actions that you should consider in order to protect your systems and networks. This list is not comprehensive and there may be other actions that you choose to take. This is just a sample of some common techniques that can be used to address this NTP DDoS issue.

Find Vulnerable Systems

You should scan your network to find systems that respond to NTP query commands. The ntpdc command can be used to connect to an NTP server and determine if it responds to the monlist command. You can also use a tool like nmap to scan a network looking for vulnerable systems. More information on both of these mechanisms can be found in reference [1] in the Additional Information section below.

It is important to consider systems that you may not think are running NTP server software. Some versions of Juniper routers, NetApp ONTAP systems, or other network devices will enable a vulnerable NTP server by default when the system is configured as an NTP client. To ensure that you have addressed all possible vulnerabilities, it is advisable to scan your networks using a tool like nmap to locate vulnerable systems.

Update NTP Server Software

The most recent versions of NTP server software have removed support for the monlist command. If you have updated your NTP server software to at least version 4.2.7p26, you should be protected against these types of attacks, as your server will not respond to monlist query requests.

Modify NTP Configurations

Update your NTP server configuration to remove support for monlist and other query commands. One such mechanism is to add the following lines to your ntp configuration file:

  • restrict default kod nomodify notrap nopeer noquery
  • restrict -6 default kod nomodify notrap nopeer noquery

See reference [3] in the Additional Information section below.

Limit Unnecessary Network Connections

If your NTP server does not need to receive inbound NTP requests from arbitrary hosts on the Internet, then you should filter the incoming traffic. Consider implementing firewall rules router ACLs, or other traffic filters to limit inbound NTP requests to only be allowed from NTP time servers that you expect to sync with.

Additional Information



  • V1.0 (January 27, 2014): Advisory published.