ntp.conf: Is it reasonable to rely on default server list, exposed in CentOS?

Question

Every time I setup a new Linux host (CentOS, lately), expecially when such an host will have some roles within our small datacenter (around 100 hosts), I take care to:

1. install the ntp package;
2. add, on top of the server list, a new server instance pointing:
   • to our more-or-less official Italian ntp server (time.ien.it), if the system has outbound ntp access;
   • to an "internal-host", who acts like a sort of official ntp "internal" server, if the system is not Internet-connected.
3. enabling the ntp service, so to properly deals with reboots

So, as for systems with Internet access, the server-list configured in the ntp.conf is the following:

server time.ien.it iburst
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

While investigating completely different issues, I discovered that above configuration generate traffic to remote hosts I'm totally unaware of.

Here is a snippet of a tcpdump capture, taken on the outbound interface of our drbd-store-02-ch host:

where you can see:

• traffic from/to hosts I'm correctly expecting (the "yellow" one);
• traffic from/to hosts that looks unrelated to CentOS and/or ntp.org domain. Specifically:
  • 1.ntp.tld.sk
  • laika.paina.net
  • time.reisenbauer-it.com
  • 183.84.160.167.rdns.kaiju.cc

During investigation, it cames out that there where also other hosts, not included in the list above. I even found hosts whose reverse hostname clearly pointed to some big ISPs, referring to VPSs and stuff like that.

So my questions are:

1. Should I remove the default server-list and rely only to my "trusted" time.ien.it external ntp-server host?
2. if not, how can I be sure that those remote hosts are effectively "safe" and properly protected/managed... so to not put at risk my ntp-service-requests?

---

P.S.: as a side note, I'm absolutely aware about the DNS resolution process and so the problem is not "why" I'm contacting those servers. The problem is: "is it safe?"

Answer 1

The short version: it is probably safe.

The longer version: the behaviour you are seeing is completely normal and expected. The NTP pool is a dynamic pool which will likely change each time the DNS TTL expires.

Each host in the pool is monitored by the NTP pool infrastructure, and if it reports time which is too far off what is acceptable, it is removed from the pool. You can view each host's monitoring records at http://www.pool.ntp.org/scores/IP (where IP is the IP address of the server). e.g. When I look up 0.centos.pool.ntp.org on my machine right now, I get these addresses:

• 74.120.8.2
• 72.5.72.15
• 45.79.187.10
• 173.255.232.93

Assuming your time synchronisation requirements are average (in terms of offset from the true time), usual best practice is to set up 4-6 servers in your own network which sync with 4-6 servers in the pool, and point your internal hosts to those local servers. I talked about this in a more detail at this year's Linux.conf.au sysadmin miniconf (last talk on the page).

EDIT: Note that some pool servers are also TOR relay or exit nodes. This sometimes gets NTP pool users in trouble with their overly-zealous IDS/IPS or even their ISP. See https://twitter.com/_lennart/status/861714732709031936 for a recent example.

Answer 2

You should probably only use a list like that in the DMZ. Internal systems should never be able to just contact random services on the internet using UDP port 123.

1. You should reduce the list to trusted hosts only within your own network. In the DMZ you should trust that your NTP software does not just forward strange requests from the inside to the internet.
2. You can not. Those hosts could just as well be horribly configured.

So if you have a good reason to have a trusted time server, get one that interacts with a good time source device and don't hook it up to the internet.

Answer 3

This looks like the rather common case of a software vendor (Centos) shipping with the free public NTP.org pool in their default NTP configuration rather than providing their own NTP infrastructure or relying on the user to have NTP infrastructure in place.

I'll go ahead and quote their documentation below.

Regarding use of the NTP.org pool:

Consider if the NTP Pool is appropriate for your use. If business, organization or human life depends on having correct time or can be harmed by it being wrong, you shouldn't "just get it off the internet". The NTP Pool is generally very high quality, but it is a service run by volunteers in their spare time. Please talk to your equipment and service vendors about getting local and reliable service setup for you. See also our terms of service. We recommend time servers from Meinberg, but you can also find time servers from End Run, Spectracom and many others.

...

If your Internet provider has a timeserver, or if you know of a good timeserver near you, you should use that and not this list - you'll probably get better time and you'll use fewer network resources. If you know only one timeserver near you, you can of course use that and two from pool.ntp.org or so.

Regarding the NTP.org pool vendor zones (like the centos in 0.centos.pool.ntp.org):

Get your vendor zone
To allow you to use the pool as the default time service in your application, we will set you up with special hostnames, for example 0.vendor.pool.ntp.org, 1.vendor.pool.ntp.org, 2.vendor.pool.ntp.org and 3.vendor.pool.ntp.org.

You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance.

...

Why use special hostnames for vendors?
The special hostnames allows us some control of the traffic so we can optimize our load distribution and match clients to the best servers. It also gives better options for continuing support in case of problems with segments of the client population. (See the links in the basic guidelines section).

As for the safeness of the servers in the NTP.org pool, the servers in the pool are being monitored, but as they explicitly say, if you have a better (more trusted and reliable) option you should use that.

Answer 4

Consuming or providing bad time can probably be filed under "internet misdemeanors". All of the CentOS NTP names are a batch of IP addresses, probably meant to provide a broad sample for time sources (because drawing a complete NTP blank might be worse?).

Personally, I'd give moderate trust to the list that CentOS produces but if you're concerned or if there's a business need, you should be able to find NTP from your provider network or from NIST (time-a.nist.gov, etc) if you trust them. In circumstances where security was paramount, I've consumed time from my provider network and re-hosted that time reference on the core routers so that consumers within the network can all use a unified and known source.