Original release date: January 13, 2014 | Last revised: January 14, 2014

Systems Affected

NTP servers

Overview

A Network Time Protocol (NTP) Amplification attack is an emerging form of Distributed Denial of Service (DDoS) that relies on the use of publically accessible NTP servers to overwhelm a victim system with UDP traffic.

Description

The NTP service supports a monitoring service that allows administrators to query the server for traffic counts of connected clients. This information is provided via the “monlist” command. The basic attack technique consists of an attacker sending a "get monlist" request to a vulnerable NTP server, with the source address spoofed to be the victim’s address.

Version prior to 4.2.7 may be vulnerable, Slackware stable is at ntp-4.2.6p5, however, I have not seen the problem with the tests found in the CERT Notice (YMMV).

Worth your time to read the entire notice and possibly take action: https://www.us-cert.gov/ncas/alerts/TA14-013A.

Hope this helps some.

Thanks! Uh...so now what? "Version prior to 4.2.7" means "every production version of ntpd." So the fix is either a) get the development version, which will be good, but you might be following quality beta releases until the end of time; or b) add "restrict default noquery" and "restrict -6 default noquery" to your ntp.conf file. Tough choice, indeed. ntpd is slightly overdue for a new release, though, so maybe this will get things moving along...

Suppose you could also switch to ptp.

Or chrony, though it doesn't quite have the facilities or reference clocks of ntpd. Still doesn't seem too bad at first glance.

The same CVE at ntp.org has "disable monitor" as a solution, but the separate CVE listed just below it at ntp.org suggests either an upgrade or use of restrict lines as well. The ntp.org version of the CVE is at this support.ntp.org page.

The CERT notice provides a...
I suppose that, can't prove it but suppose, adding the recommended directive as above might just do the trick. Until I hear otherwise, I'll take CERT's word for it, I think. Personally, I don't want to do without NTP (nor do I want to buy a GPS reference clock -- pricey buggers, those). Over the years NTP has been pretty reliable, little glitch here, little glitch there, but all-in-all a darned useful piece of software that just sits there mumbling to itself and doing what it's supposed to do. It would not surprise me if somebody noticed this, notified NTP developers and they notified CERT right quick; they've always impressed me as a responsible bunch of folks that take seriously any problems. Can't ask for much more than that, methinks.

NTP is, pretty much, part of the infrastructure and I'm expecting a quick fix -- just the notice about how to fix the problem in existing installations kind of tells you what sort of folks you're dealing with... sorta like Slackware, eh?

Hope this helps some.

This has already been reported. When I went to add the two lines to /etc/ntp.conf, they were already therein, along with:

# Attempt to baffle cyberweasels.
disable monitor

I don't know when I added those, but since it is my habit to keep current on https://isc.sans.edu/diary.html, it was probably reported in there.

For those who wish more information on the US CERT messages, follow the links in ftp://ftp.osuosl.org/pub/slackware/s.../ChangeLog.txt. Note the CVE number begins with "2013." Unless you are operating an NTP server facing the Internet, no worries. Systems administrators probably have already fixed their systems; if not, firewall rules should cover it.

I acknowledge the sense of panic these CERT messages may invoke, but, rather than posting last year's news here, do a little research first. Everyone is a little shell-shocked by the recent upsurge in cyberweasel activity, what with 70 million Target customers and Neiman Marcus, before that Adobe.com was raided for who-knows-how-many accounts. Those sociopaths have been actively engaged in criminal activity for decades. They have no Father Figure in their pathetic lives, so they seek a sense of downward self-transcendence via herd intoxication by getting recognition from other sociopaths. I blame secular humanism, which has yet to come up with a way to teach ethics and instill a sense of moral obligation to society. But I digress.

Amplification attacks are unfortunately easy to carry out when payload asymmetries with spoofed source addresses can be triggered (e.g. small UDP requests generating large responses).

The good news is Slackware's default ntp config already mitigates monlist amplification attacks:

If, as hpfeil said, you have an internet-facing ntp server, don't become part of the problem by allowing external monlist queries.

Note: ntp 4.2.7 deprecates monlist and introduces mrulist which requires nonce-authenticated client requests. This prevents the ntp server from being used to DoS a victim.

--mancha

The correct restrict noquery line has been there since slackware-9.0. But it wouldn't hurt to add another one for IPv6 (similar restrict -6 line).