Earlier in this series, I provided a brief overview of NTP and then looked at important NTP options to lock down your servers. In this article, I’ll look at some additional security concerns.
Check out the pool
According to the excellent site NTP Pool Project website, which points users at a “big virtual cluster of Time Servers providing reliable easy to use NTP service for millions of clients,” there are 182 active servers for the UK pool in the IPv4 space and 99 available to IPv6 at the time of writing. For reference, they provide useful historical statistics and graphs to presumably keep an eye on any geographical areas which require more resilience, among other things. Figure 1 shows a graph of the available servers for the UK.
Review your options
Let’s go back to the friendly restrict command, mentioned previously. It can unilaterally “ignore” everything from hosts or subnets, This should deny absolutely everything, indeed packets of all kinds, including ntpq and ntpdc queries.
I also mentioned Kiss of Death packets earlier and adding the kod option to a restrict line means that we will send a kiss-o’-death (KoD) packet if we want help reduce unwelcome packets and introduce rate-limiting of some description.
One other point to note is that using the limited option only denies clock updates if a requests comes up against the rate limits established by the discard command. The limited option doesn’t apply to ntpq and ntpdc queries, which might add more load from a user with nefarious intentions.
A common addition to the restrict line is nomodify. This denies ntpq and ntpdc queries that might attempt to modify the time on an NTP server. As you would expect, however, any queries that return information only are allowed.
You are unlikely to avoid seeing this option: the noquery flag makes certain that you deny all ntpq and ntpdc queries. Be aware, however, that offering up the correct time is still possible despite this being enabled.
If you want to avoid building relationships with other NTP servers (e.g., unless they are successfully authenticated with you), then the nopeer option will allow you to do this. According to the manual, “This includes broadcast, symmetric-active and many-cast server packets when a configured association does not exist.”
The noserve option is simple; it dutifully denies all packets from a machine (or range of machines) except for ntpq and ntpdc queries.
As you might expect the notrust switch enforces who can connect to your NTP server. In fact, it will deny traffic that isn’t cryptographically authenticated. Again quoting from the manual:
“Note carefully how this flag interacts with the auth option of the enable and disable commands. If auth is enabled, which is the default, authentication is required for all packets that might mobilize an association. If auth is disabled, but the notrust flag is not present, an association can be mobilized whether or not authenticated. If auth is disabled, but the notrust flag is present, authentication is required only for the specified address/mask range.”
One final option to pay attention immediately to is called version. This option will be certain to disallow traffic that doesn’t match the current NTP version of your server or client. This can clearly be useful for enforcing that up-to-date versions are used and therefore older security issues present less risk. A similar approach appears in OpenSSH where using the legacy “version 1” is far from recommended; therefore, it is necessary to explicitly enable that version to avoid falling into a potential trap and opening up security holes unnecessarily.
Localized infrastructure
One infrastructure recommendation relates to installing NTP servers and introducing “peering” yourself for improving resilience and capacity. Implementing a peer-to-peer infrastructure within your Stratum 2 servers means that those servers within the peer group allow each other to update their clocks. This, in turn, helps with load balancing and any additional load on their relevant upstream servers. This approach might also be called distributing the time horizontally.
As with all online architectural challenges, there are several other factors to consider. For example, keeping time diligently with three upstream servers and building a complex internal NTP fabric, upon which you come to heavily rely, is of little use if you only have one external Internet connection.
Perimeter Lockdown
Earlier, I promised to quickly examine how to lock down your firewalling with IPtables, rather than opening up UDP port 123 carte blanche. This might apply to your local NTP client, or if you added such rules to a perimeter firewall all of the clients on your LAN. I’ll look at limiting who you can speak to in order to ensure that only very select, predefined, time servers can connect with you.
I’ll use the “uk.pool.ntp.org” example for familiarity, but in reality you might lock down these rules to three individual servers and not a pool of servers. This is because, although you are assured of the reliability of multitudinous NTP servers being available, you may not want to trust them all. Due to the high churn rate, some could be compromised and cause you unwelcome headaches.
Outbound — egress — traffic rules are slightly more sophisticated than those we use to allow traffic into our machine or network. This is because we want to allow “NEW” time lookups to be performed and also pick up the response when an NTP server responds to such a request with what’s called an “ESTABLISHED” connection. You can achieve that as follows:
# iptables -A OUTPUT -o eth0 -p udp -d uk.pool.ntp.org --sport ntp -m state --state NEW,ESTABLISHED -j ACCEPT
Note that if this were my configuration, I would most likely tie these rules to specific IP addresses.
Conversely, to allow an inbound time check to occur, you can use this fractionally simpler line with just “ESTABLISHED” connections being allowed through:
# iptables -A INPUT -i eth0 -p udp -s uk.pool.ntp.org --sport ntp -m state --state ESTABLISHED -j ACCEPT
Alternative to NTP
Finally, to help clear up any confusion there’s an alternative of sorts to the venerable Network Time Protocol that is worth a quick mention. This option comes in the form of the Simple Network Time Protocol (SNTP). What is interesting is that both timekeeping solutions follow the same packet format and actually, according to RFC 4330, “the NTP and SNTP packet formats are the same, and the arithmetic operations to calculate the client time, clock offset, and roundtrip delay are the same.” So, be confused no longer if you think SNTP is more of a subset of NTP rather than a contender.
SNTP becomes most useful when a fully fledged NTP server infrastructure can’t be justified. An earlier RFC (RFC 2030) talks specifically about not expecting SNTP to be performant at passing on the time to other clients. It also mentions that at the furthest edge of the NTP tree (by that I mean the the leaves, or the highest stratum, as opposed to the branches which then connect to the trunk) is where SNTP implementations are best suited. The RFC also warns that without redundant network links and diverse, resilient configurations, SNTP should not be relied upon for serving the time, just receiving it.
Clearly, however, on lesser powered devices SNTP can be implemented quite happily to use fewer system resources. It should therefore be applicable to a number of scenarios, specifically where the IoT demands time lookups from otherwise low-powered equipment, such as refrigerators or other domestic appliances (which I suspect are likely to remain low-powered from a computing perspective for a relatively short period of time as demands on their functionality grows).
EOF
Although I’ve only run through an overview on keeping your clocks correct with NTP, I hope this introduction has explored some of the more important aspects of the subject. I have looked at the configuration, monitoring, and securing of NTP and extolled its value to the integrity of your infrastructure.
You should consider NTP absolutely critical and can now appreciate why it should be one of the first services — possibly directly after DNS — to explore in detail when building infrastructure. Armed with a smattering of IPtables and knowledge of where to find listings of public NTP servers, you are now suitably armed to begin that very task.
Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.
Advance your career in Linux System Administration! Check out the Essentials of System Administration course from The Linux Foundation.
