Network Time Protocol (NTP) servers are commonly installed on VPSes. This article discusses security concerns.
- 1 Purpose
- 2 Security concerns
- 3 Recommendations
- 4 Example complete configurations
NTP servers are normally installed for the purpose of regulating the operating system clock, synchronising it against multiple other time sources in order to provide greater timing accuracy than could be obtained from the hardware alone.
Some customers also run an NTP server in order to provide time services to others, for example as part of the The NTP Pool project.
As with all software, especially that which provides service to Internet hosts, there are security concerns.
UDP amplification attacks
This is the number one problem with the NTP protocol today.
NTP uses UDP datagrams which, as they don't have the three way handshake of TCP, are susceptible to being forged. If an attacker sends your NTP server a request that is forged to appear as if it came from a victim IP address, your NTP server will respond to the victim. If the response is much larger than the question then this acts as an amplification. A botnet all making such queries can create an overwhelming distributed denial of service (DDoS) attack.
If you're intending to run an NTP server at BitFolk and allow access to it from external hosts then you must disable all administrative functions that generate large responses. For ntpd this would typically be the monlist command, which can be disabled by specifying the noquery option. This doesn't prevent people from querying your ntpd for time. It disables administrative queries like monlist and peers. You can re-enable them for specific hosts only.
- CloudFlare: Understanding and mitigating NTP-based DDoS attacks
- Symantec: Hackers Spend Christmas Break Launching Large Scale NTP-Reflection Attacks
- Ars Technica: DoS attacks that took down big game sites abused Web’s time-synch protocol
There are some astonishingly badly-behaved clients out there which will occasionally spew queries at your server hundreds of times a second and never, ever stop. All you can do is firewall them off. Even that doesn't stop the traffic, it just stops your NTP server having to process the packets. There is no good solution to this problem beyond blocking and contacting abusive clients or hoping they go away.
Use the OpenBSD NTP daemon instead
If you only require an NTP client (you want/need an accurate clock, but don't provide time services to others) then the OpenBSD NTP system doesn't open a listening network socket by default. For Debian/Ubuntu systems, the package you want is "openntpd" - this should automatically replace any existing NTP server (via package Provides/Conflicts). This package is part of the "wheezy" branch, and is also available in "squeeze-backports". You will probably want to edit the openntpd configuration file to use the Bitfolk timeservers, rather than the (package default) Debian NTP pool.
If you do not need to be providing NTP service to the Internet then you could firewall it off. If you are thinking of allowing remote access to your NTP server in order to help the Pool Project then you may want to reconsider; there are already many BitFolk VPSes in the NTP Pool!
NTP uses UDP port 123. A problem with just blocking that though is when you need to use external NTP servers yourself. You could allow UDP/123 only from a defined list of IP addresses, but it is common to make use of the NTP Pool in which case IP addresses will not be known ahead of time.
Although BitFolk does provide two NTP server IP addresses for customer use, it is best to have at least three, preferably five or more peers configured, and for them to be diverse, i.e. not all provided by BitFolk.
If you know all of the IP addresses of the servers you intend to use then you could allow UDP/123 only from these addresses.
If not, and you still want to firewall NTP, you'll need a stateful ruleset. Team Cymru recommends:
-A INPUT -s 0/0 -d 0/0 -p udp --source-port 123:123 -m state --state ESTABLISHED -j ACCEPT -A OUTPUT -s 0/0 -d 0/0 -p udp --destination-port 123:123 -m state --state NEW,ESTABLISHED -j ACCEPT
Disable administrative queries except from permitted hosts
This is an absolute must for all NTP servers in use at BitFolk.
The following set of permissions are appropriate for ntpd:
restrict -4 default nomodify nopeer noquery notrap restrict -6 default nomodify nopeer noquery notrap
You may wish to allow queries from localhost and other trusted hosts:
restrict 127.0.0.1 restrict ::1
Checking if administrative queries are disabled
You can use the ntpdc command from a remote host to check if queries are disabled.
$ ntpdc -nc peers resntp-a-vip.lon.bitfolk.com resntp-a-vip.lon.bitfolk.com: timed out, nothing received ***Request timed out
From an allowed host:
$ ntpdc -nc peers resntp-a-vip.lon.bitfolk.com remote local st poll reach delay offset disp ======================================================================= +2001:ba8:1f1:f1 2001:ba8:1f1:f1 3 128 377 0.00034 -0.000151 0.10001 +2001:ba8:1f1:f1 2001:ba8:1f1:f1 3 128 377 0.00044 -0.000240 0.07191 =184.108.40.206 220.127.116.11 2 128 377 0.00859 0.004789 0.09630 *18.104.22.168 22.214.171.124 2 128 377 0.00174 -0.000002 0.08914 +126.96.36.199 188.8.131.52 16 128 0 0.00000 0.000000 3.99217 +2001:ba8:1f1:f1 2001:ba8:1f1:f1 3 128 377 0.00052 0.000045 0.07028 +184.108.40.206 220.127.116.11 16 128 0 0.00000 0.000000 3.99217 =2a01:7e00:e000: 2001:ba8:1f1:f1 3 128 377 0.00116 -0.000049 0.10240
Other ntpdc queries include monlist and kerninfo.
Example complete configurations
ntpd as client
The following complete configuration file is appropriate for a BitFolk customer using ntpd purely to keep their own host's time in sync.
driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable # iburst is permitted to BitFolk's servers but is rude to use against remote hosts server resntp-a-vip.lon.bitfolk.com iburst server resntp-b-vip.lon.bitfolk.com iburst server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org # by default ignore everyone restrict -4 default nomodify nopeer noquery notrap restrict -6 default nomodify nopeer noquery notrap # Local users may interrogate the ntp server more closely. restrict 127.0.0.1 restrict ::1 # Uncomment these to allow checks from Bitfolk's monitoring service as per # https://tools.bitfolk.com/wiki/Monitoring#Which_IP_addresses_will_BitFolk.27s_monitoring_checks_come_from.3F #restrict 18.104.22.168 #restrict 22.214.171.124 #restrict 2001:ba8:1f1:f25d:: mask ffff:ffff:ffff:ffff::
If you already run a stateful firewall then you may wish to additionally firewall off unexpected NTP queries as described above.
ntpd as Pool server
If you intend to provide time service as part of the NTP Pool then as per their instructions you should not use any pool.ntp.org hosts in your own server list. You can start with the above configuration but should replace the four pool.ntp.org hosts with three to five hand-selected NTP servers that you have permission to query.
When providing a public NTP service you obviously should not attempt to firewall UDP/123. If you run a stateful firewall configuration then you may also wish to exempt UDP/123 traffic from connection tracking as it can result in a very large number of flows being tracked.
Example iptables rules:
*raw -A PREROUTING -p udp -m udp --dport 123 -j NOTRACK -A OUTPUT -p udp -m udp --sport 123 -j NOTRACK COMMIT *filter -A INPUT -p udp -m udp --dport 123 -j ACCEPT COMMIT