In the first article in this series, I provided a brief overview of NTP and explained why NTP services are critical to a healthy infrastructure. Now, let’s get our hands dirty and look at some security concerns and important NTP options to lock down your servers.
Attacks On NTP
One nasty attack that recently caused the Internet community to sit up and take note involved what’s called a Reflection Attack. In essence, by spoofing IP addresses, it was possible to ask a third-party machine to respond to an unsuspecting victim with a barrage of unwelcome data. Multiplied by thousands of machines, it was possible to slow down, or even bring to a halt, some of the largest Internet Service Providers’ (ISPs) and enterprises’ infrastructure. These Distributed Denial of Service (DDoS) attacks forced some rapid patching along with some community hand-holding to keep services up and running while hundreds of thousands of machines were patched, reconfigured, or upgraded out of necessity.
This particular attack took advantage of a command referred to as monlist or MON_GETLIST. This command is found in older versions of NTP and allows a machine to query up to the last 600 hosts that have requested the time from that NTP server. Clearly, the monlist functionality is an ideal route to generating a great deal of traffic off of a very small initial request.
Thankfully, newer versions of NTP no longer respect these requests, and it’s relatively easy — if you have access to the file /etc/ntp/conf on your NTP server — to add the following line to disable it:
disable monitor
Firewalling
There’s little doubt that it is a worthwhile pursuit to harden your NTP servers. To what extent you go to however is obviously up to you. If you are using the kernel-based Netfilter’s IPtables then you would allow access to your NTP Servers by punching a hole through your firewall as so:
# iptables -A INPUT -p udp --dport 123 -j ACCEPT # iptables -A OUTPUT -p udp --sport 123 -j ACCEPT
This configuration is not the best solution by any means as any machine can connect to your NTP servers if you haven’t locked down the relevant NTP configuration. We will look at tightening this up with a little more detail shortly.
Configuration
Fully understanding all of the configuration options that NTP can offer — including authentication, peering, and monitoring — might be considered a Herculean task, but let’s continue with our overview of the subject matter in hand.
It’s probably helpful to distinguish a little between two common tools. The interactive ntpdc program is a “special” query tool, which can be used to probe an NTP server about its current configuration and additionally make changes to that config.
With a somewhat similar name, the ntpq tool is for standard queries, however, such as looking up any of your upstream machines (like printing a list of peers by typing “peer” for example) from which you are receiving the latest time. It tends to be mostly used to monitor your NTP infrastructure to help you keep an eye on its performance as opposed to making changes and special queries.
Back to IPtables for a moment: if you wanted to allow your NTP client to look up NTP queries from an upstream server, you could use rules such as these:
# iptables -A OUTPUT -p udp --dport 123 -j ACCEPT # iptables -A INPUT -p udp --sport 123 -j ACCEPT
On your NTP client, you can test which servers you have connected to, like so:
# ntpq -p
The results of which can be seen in the example below:
remote refid st t when poll reach delay offset jitter ===================================================== 10.10.10.100 .STEP. 16 u - 1024 0 0.000 0.000 0.000 clock.ubuntu. .STEP. 16 u 63 1024 34 0.870 70.168 3.725 time.ntp.orgl 10.1.1.1 3 u 71 1024 37 0.811 -35.751 26.362
As you can see, we’re connecting to three NTP servers for reliability. These are known as our “peers.” The “STEP” entries are “kiss codes” and show that our client has updated (and corrected) its time having connected to the pertinent servers. Under the “st” field, we can see the Stratum number allocated to each server.
Restrict
It is the NTP daemon, ntpd, option called restrict that offers a way of configuring access controls as to who can set the time on their wristwatches using our server. Be warned that initially at least its syntax may seem a little counterintuitive. If you get lost at any point, thankfully there’s a hillock-sized number of man pages available to you. Simply prepend the man command to any of these manuals on the command line, such as man ntp_mon, to view them:
ntpd, ntp_auth, ntp_mon, ntp_acc, ntp_clock, ntp_misc
Under the manual for ntp_acc, we can see a multitude of restrict options. Along the lines of traditional Access Control Lists (ACLs), the clever ntpd will allow you to grow a list of IP addresses and ranges that you want to permit. To fully harden your NTP infrastructure, however, authentication should be employed, which is a subject for another day.
I mentioned that restrict was a little counterintuitive as far as options go, here is what ntpd expects to see if we want to open up NTP server to our localhost (with IP address “127.0.0.1”). This allows the localhost to have full access without any restrictions and not, as you might think, restrict its access:
restrict 127.0.0.1
The above assists with IPv4 addressing and the IPv6 equivalent would look like this:
restrict -6 ::1
Conversely, when we want to subjugate one or several hosts, we add options to the end of that command, like so:
restrict 10.10.10.0 mask 255.255.255.0 nomodify notrap
The example above deals with 254 hosts on a Class C subnet. Let’s look at some of the many other options available to the restrict option and how they manipulate NTP. It’s worth mentioning that DNS names can also be used instead of IP addresses; however, be warned that poorly maintained domain name services can cause havoc with your NTP infrastructure. In the UK, for example, it’s recommended to configure your NTP servers and clients to look upstream to these DNS names inside the /etc/ntp.conf file:
server 0.uk.pool.ntp.org
server 1.uk.pool.ntp.org
server 2.uk.pool.ntp.org
server 3.uk.pool.ntp.org
You may well ask why. There’s very good reason, as we can see from this DNS lookup, on just the first entry in the list, for public NTP servers available to the United Kingdom:
# host 0.uk.pool.ntp.org 85.119.80.232 178.18.118.13 217.114.59.3 176.126.242.239
In our abbreviated DNS lookup results, even the first DNS name “0.uk.pool.ntp.org” offers the resilience of four unique IP addresses, some of which may also be several machines and be hosted on resilient network links too perhaps.
Next time, I’ll finish up this NTP series with more configuration options for a secure setup.
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.
