News from 2014-01-09


Meinberg Security Advisory: [MBGSA-1401] NTP Monlist Network Traffic Amplification Attacks


A number of reports has been published recently, describing an increased level of abuse of the NTP "monlist" feature that is supported by NTP versions up to 4.2.7p26 and can affect Meinberg LANTIME products as well. Protecting your NTP servers against this abuse is relatively easy and can be achieved with a simple configuration change.

CVE-ID: CVE-2013-5211

1. Description of the Problem

We recently received a number of technical support inquiries and questions from our customers describing an increasing number of attempts to abuse a running NTP instance to perform traffic amplification attacks. This means an attacker sends a small amount of network traffic (one request packet in this case) to a machine and triggers a much larger ("amplified") response, potentially causing problems due to excessive network bandwidth consumption or CPU utilization on the target of the attack.

The reference implementation of NTP, published by the NTP Project (http://www.ntp.org), allows users to request a list of hosts with which the NTP daemon ntpd communicated recently. The list, called "monlist" has a size limit of 600 entries and contains the IP addresses of the last NTP clients or servers the instance has talked to.

The majority of running NTP daemons on NTP clients only list the upstream NTP servers used and therefore the list contains less than 10 entries. However, on NTP servers with many clients, this list contains the maximum of 600 entries. Only a small request packet is required to generate a large response, especially on a server with 600 entries in its "monlist".

By spoofing the source address of the request, it is possible to generate a response to any victim host with an IP address reachable by the server, allowing a potential attacker to mount a traffic amplification attack against that third party host. Sending a large amount of these crafted request packets will generate an even larger traffic flow directed towards the victim.

2. Affected Systems

All NTP installations running ntpd versions before 4.2.7p26 will per default respond to NTP Mode 7 "monlist" requests. Starting with ntpd-4.2.7p26 the "monlist" feature has been disabled and the functionality has been replaced by the "mrulist" feature that uses mode 6 packets and implements a handshake procedure to prevent the possibility for hitting a third party host with the amplified traffic.

Meinberg LANTIME NTP Servers until firmware revision 6.14.020 allow mode6/7 access in their default configuration and therefore are vulnerable as well.

3. Possible Defense Strategies

Meinberg Products

Time and Frequency Synchronization Platform in 1U Rackmount-Enclosure

Time and Frequency Synchronization Platform in 1U Rackmount-Enclosure

Read More...
Integrated security features - IMS LANTIME M1000S

Integrated security features - IMS LANTIME M1000S

Read More...

For Meinberg LANTIME products running firmware versions V4.x and V5.x, the recommended configuration changes outlined below can be applied using the "Edit additional NTP configuration" function on the NTP configuration page of the web UI.

Add the following lines to the "additional NTP configuration" of your LANTIME:

# LANTIME Additional NTP Configuration:
restrict default limited kod nomodify notrap nopeer noquery
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1

IMPORTANT: the last "restrict" line is required to ensure that the internal status updates continue to work. Failing to add this line (restrict 127.0.0.1) can cause problems with displaying the NTP status on the Web UI and on the front display etc.

LANTIME products running V6 firmware versions can be protected either by using the same approach as V4/V5 or by disabling mode 6/mode 7 support generally using the "Disable mode 6 / mode 7" option in the "General Options" section on the NTP page of the web interface.

Other NTP Installations

If updating your NTP installation to 4.2.7p26 or later is not possible, you can disable the support for handling NTP mode 7 requests by using the "restrict" statement. The "noquery" flag will disable mode 7 support (including the "monlist" feature) and can be set up in a "default restrict" statement to be applied to all incoming requests. NTP allows to define default "restrict" setting and different restrictions for specific IPs and/or subnets.

NTP packets are used for requesting status information from the NTP daemon and allow attackers to obtain knowledge about the NTP version and the OS version running on your NTP server as well as other information like upstream NTP servers and details about the current status of your NTP synchronization. In addition to disabling status query support, Meinberg recommends you disable configuration change support as well, which can be achieved by using the "nomodify" flag.

NOTE: To find out more about the meaning of the configuration statements used in this article, please refer to http://doc.ntp.org for further explanation. The configuration examples provided here should work with all ntpd versions from 4.2.0 to 4.2.6 with the obvious limitation that the IPv6 related configuration lines only work with versions that support IPv6.

Add the following lines to your NTP configuration file (ntp.conf):

# for IPv4
restrict default limited kod nomodify notrap nopeer noquery
# for IPv6
restrict -6 default limited kod nomodify notrap nopeer noquery

This will for all incoming requests disable mode 6 and mode 7 support and in addition enables the "kiss-o'-death" (kod) functionality of NTP. It will still allow everybody to send a regular NTP request (for time), but prevents all IP addresses not specifically configured from using mode 6 (status) or mode 7 (control) requests to obtain detailed information about your NTP server or use the mode 7 "monlist" feature for traffic amplification attacks.

It often makes sense to allow full access from the server itself, you can remove the restrictions for the local host by using these "restrict" lines:

# for IPv4
restrict 127.0.0.1

# for IPv6 restrict -6 ::1

In order to disable these restrictions for specific hosts or whole subnets that need access to the "monlist" and other status information provided by ntpd with the mode 6/mode 7 approach, additional "restrict" statements can be added for each of those IP addresses or subnets. If you want to allow an administrator PC to access the detailed NTP status information, you can add another "restrict" statement:

# for IPv4
restrict 192.168.0.20 nomodify nopeer

Or, to define different restrictions for a whole subnet:

# for IPv4
restrict 192.168.0.0 mask 255.255.255.0 nomodify kod

You can define multiple "restrict" lines to grant access to multiple hosts and subnets. More about possible access control configuraton functions can be found on the NTP documentation site of the NTP Project (doc.ntp.org).

5. Additional Information Sources

More about this topic can be found on the following websites:

Please do not hesitate to reach out to your Meinberg support contact if you need further assistance or have additional questions.

Updated Jan 15th, 2014: Added CVE-ID, links to CERT and NTP.org (section 5) and changed the configuration examples to include "limited" in addition to "kod", otherwise the "kod" statement would not work.


Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact Meinberg Mail Contact