Correct way to run an ntp server

Intro
Concerns about DOS and DDOS have been heightened recently, for instance http://securityaffairs.co/wordpress/20934/cyber-crime/symantec-network-time-protocol-ntp-reflection-ddos-attacks.html. A more bare-bones, antiseptic description is here in CVE-2013-5211. Unfortunately those inventive hackers have found new ways to create headaches for us good guys. Last month saw an increase in DDOS attacks using poorly configured public ntp servers to create packet amplification. I’ve looked into it and determined how to run an ntp server without exposing your server to being an unwitting source of this type of traffic.

The details
This mostly applies to SUSE Linux (SLES), but I don’t think the other Linux distros would be all that different. In SLES you have the NTP configuration in /etc/ntp.conf. You have of course the regular lines, plus the server lines, which may look something like this:

...
server otc1.psu.edu prefer
server ntp2.usno.navy.mil
server tock.usno.navy.mil prefer
server navobs1.wustl.edu
...

You may not be able to use these exact same servers – sometimes you need to ask permission first.

Now if that’s all you had, plus the driftfile and the other blah, blah, you’re probably in trouble. Test this from another Linux server beforehand. Something like:

> ntpdc -c monlist

If you start seeing lines like the following you’re in trouble:

remote address          port local address      count m ver code avgint  lstint
===============================================================================
ldrj1200.drjon.drjo.ne 58372 10.192.186.15          2 7 2      0     30       0
ns.drjohnstec.com      48944 10.192.186.15          1 7 2    5d0      0      11
neus.drj.drjohnstechta   123 10.192.186.15          8 3 2    5d0      2      13
...

That’s no good because with one udp packet a whole lot of packets can be returned, or worse, sent to a different target since in general the source IP address of the UDP query packet could be spoofed.

The solution
Of course what I’m writing here is not news. It’s just somewhat hard to understand the ntp documentation on this topic on the ntp.org web site.

In my experimentation I’ve found you should add into the ntp.conf file these lines:

restrict default kod nomodify notrap nopeer noquery
# but allow some hosts access
restrict 127.0.0.1
# our monitoring server
restrict 10.192.186.89

Then, a

> sudo service ntp restart

and your remote listing should produce something like this:

> ntpdc -c monlist ntp1.johnstechtalk.com

ntp1.johnstechtalk.com: timed out, nothing received
***Request timed out

and equally important, you can still locally query your ntp server to see that it is still syncing time:

> ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l    5   64  377    0.000    0.000   0.001
*gps1.tns.its.ps .GPS.            1 u  886 1024  377   28.554    3.396   6.836
+ntp2.usno.navy. .PTP.            1 u  154 1024  377   13.124   -1.422   4.658
+tock.usno.navy. .PTP.            1 u  965 1024  377   13.906   -0.058   0.910
+navobs1.wustl.e .GPS.            1 u  194 1024  377   30.817    0.274   1.927

And, equally important, your local servers using your ntp server should also continue to be able to sync time against the ntp server you have set up.

Conclusion
We have shown how to prevent your ntp server from being using in a DDOS attack. Most ntp servers are probably protected by a firewall of some sort, but it still might be a good idea to lock it down in this way as a best security practice.

The official advice talks about upgrading to ntp version 4.7, but I find this impractical for a couple reasons. It is not generally available from the distro package vendors, and it is considered a development release. Hence the effort to massage the configuration of an older NTP server as I’ve documented here to make it invulnerable to this problem.

References
The IT Detective Agency: ntp server shows the wrong time after patching