Securing NTP

From BitFolk
Jump to navigation Jump to search

Network Time Protocol (NTP) servers are commonly installed on VPSes. This article discusses security concerns.

Purpose

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.

Security concerns

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.

Badly-behaved clients

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.

Recommendations

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 NTP servers, rather than just the (package default) Debian NTP pool.

Firewalling

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.

Example: 

$ 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
=37.123.115.64   85.119.80.234    2  128  377 0.00859  0.004789 0.09630
*94.228.40.3     85.119.80.234    2  128  377 0.00174 -0.000002 0.08914
+85.119.80.234   85.119.80.234   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
+209.237.247.192 85.119.80.234   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
pool -4 ntp.lon.bitfolk.com iburst
pool -6 ntp.lon.bitfolk.com iburst
pool -4 2.pool.ntp.org      iburst
pool -6 2.pool.ntp.org      iburst

# 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 85.119.80.238
#restrict 85.119.80.244
#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

chrony

chrony seems to be considered a better choice these days than ntpd. Anyone got an example config?

Retrieved from "https://tools.bitfolk.com/w/index.php?title=Securing_NTP&oldid=1911"