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