Jayson Broughton

“Who controls the past controls the future: who controls the present controls
the past” ~George Orwell. Well in this case, whoever controls the Network Time
Protocol (NTP) server, controls the past, present and future. NTP has been
around for quite a while now, its main purpose is to coordinate the time among
various servers, routers and networked equipment in the world. System
administrators tend to setup an NTP server, point a few clients to the NTP
server and do nothing else. Some don’t even know what NTP is or how to
properly set NTP up. Did you know that NTP has its own built in security
measures? From Access Control lists all the way up to certificate based
authentication of client/server roles. But why should you use NTP? And just
why NTP Security? Well there are a few reasons for NTP.

Convincing reasons for NTP

1. desktop clients sync time, after all employees love seeing when it’s time to
go home.

2. multiple servers sync time, keeping logs up-to-date between servers is key
to troubleshooting errors and security

3. devices (Routers, Switches, etc) keep logs in sync for troubleshooting and
centralized syslog server

4.all of the above

Security reasons for NTP

1. Access Control Lists allow an administrator to control who can sync and who
can’t sync. If your NTP server is public facing this can dramatically cut down
on bandwidth if your NTP server accidentally gets posted as a public time
server on the internet.

2. AutoKey is an encryption security feature usually used by universities and
government entities where two outward facing NTP servers ,usually a stratum 1
server and many stratum 2 clients exchange certificate based key exchange for
authentication. The key word here is ‘outward facing’ As I will go over this
again here shortly.

3. MD5 key exchange allows for internal and external clients to have MD5 hashs
to trust that the server is who it says it is before changing the time on the
server

4. By trusting who the NTP server is, a trust relationship is built that
guarantees that the time is accurate among the servers for security and legal
reasons when it comes to tracing down log files. If for instance someone has
modified DNS to point to a different NTP server but doesn’t have access to your
keys file than your internal (or other stratum servers) will not fetch the
modified time. Thus preserving the time of your log files.

5. An attacker who finds out your external facing NTP server’s hostname might
find a way of exploiting DNS and fake a time sync in order to change the
date/time of logs prior to attacking a network. With security in place on the
client side, verification of who the server is will stop such an attack.

Security Options

Well, I’ve sort of touched on the security options with NTP but I’ll go over
them again here in greater detail. NTP has 4 ways of being setup in an
environment, from totally insecure all the way to government/institution
security mandated by security policies and procedures.

1. No Security – This is the default that most people setup when they first
start out with NTP. Granted if you’re new to NTP or system administration, you
really don’t think much about NTP security and how it can affect a business.
For most SOHO (Small Office/Home Office) setups without servers this might
suffice. For businesses with servers or critical services that are outward
facing to the internet you might want to proceed to the next higher levels of
security.

2. Access Control – access control lists allow ntpd to restrict who can not
only retrieve their time from NTP, but who can also query the NTP for server
stats (such as OS and ntpd version), and control the NTP service. An outward
facing ntpd server that allows anyone access to query OS and ntpd versions is
an insecure server. Internally however, unless you don’t trust your internal
network, ACLs usually are not necessary but you can however restrict it down to
subnets. There are 4 options to the ACL including: nomodify (do not allow this
host/subnet to modify ntpd settings), noserve (do not serve time to this
host/subnet), notrust (ignore all ntp packets that are not cryptographically
authenticated), and noquery (do not allow this host/subnet to query ntpd
status). You can set all or some of these settings with ACL restrictions.

3. Shared Secrets – This is the symmetric key authentication which is used by
NTP to make sure a server is who they say they are. When fetching time, the
client requests the Key, KeyID and Key Type (which is replicated on the
server). If they differ then the time will not change, if however they match
then the time will be modified for the client. A server can have 65,534
possible keys with each key having a unique 32-bit key ID; so that gives a wide
range of possibilities. This can be used in a WAN/LAN situation behind NAT or
on the outside of the network.

4. AutoKey – the forth and more hardcore
approach to NTP Security. Autokey uses public key cryptography utilizing
challenge/response exchanges. Autokey uses certificate based authentication
and requires both the server and client to be on the outside of the firewall.
This would be a useful setup for two sites where a central stratum-1 server
provides Autokey access to several Stratum-2 servers, which then have an
internal NIC that provide NTP Access to their inside clients. The keyword to
this is: This can only be used outside
the LAN, neither the client or the server can be behind a

NAT

So now that I have explained the basics of NTP security, I’ll only be going
over Access Control and Shared Secrets in this blog post. I don’t have access
to multiple external IP addresses, certificate based authentication, and I just
don’t see very many people outside of institutions and government agencies
utilizing AutoKey.

Before I get started I will assume that you know how to install and start ntpd,
if you don’t then this really isn’t the post for you. I will lay out a simple
‘default’ ntp.conf file used on a server, but will not be going over what each
file and line mean. Google is your friend on setting up NTP servers.

Keep in mind, ntpd is for syncing time between NTP services that utilize
ntp.org’s services, and equipment such as routers/firewalls/switches that use
the ntp protocol; not sntp (simple ntp), or Microsoft’s own implementation of
NTP. Microsoft has their own version of NTP (w32t.exe) that clients use to
authenticate to an Active Directory server to get their time from. I spent a
great ammount of time researching this, and came to the conclusion that their
solution made my head hurt. There is some form of ‘encryption’ on the line to
verify the client to the server, but there is no way to use your own shared
secrets to a separate NTP server. If you want to use your windows client to
authenticate with a linux NTP server search the internet for a win32 binary
client for NTP; there are a few of them out there. If you do however want to
use your ntp client (w32t.exe) in windows to point to your linux NTP server,
that is entirely possible; check the help page for the w32t.exe executable.

What you’re going to need is a server, and a client. Or in my case for testing
purposes; a server and some virtual machine clients. Make sure you have ntpd
already installed on the server and ntp installed on the clients.

NTP Setup

On the server side, make sure you have ntp server up and running. Minimal
setup is as follows (mileage may vary according to your Distro and how you
installed NTP). All of my testing was done with a Debian server and an Ubuntu
11.04 client.s Fedora and other distributions might put ntp files in /etc/ntp/
or another locations.

 # /etc/ntp.conf

driftfile /var/lib/ntp/ntp.drift

#I like stats
statsdir /var/log/ntpstats
statstics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

#NTP servers - I list 3 and loopback as fallback
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
server 127.0.0.1 stratum 10 #localhost

#ACL
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1 restrict ::1 

Save the file, mark as read-only(chmod 444 /etc/ntp.conf) and make sure root
only has access (chown root:root /etc/ntp.conf), restart ntpd and move on to
your ntp client.

The reason that I have ‘server 127.0.0.1 stratum 10′ in my ntp.conf file is so
that for whatever reason if my network fails, ntp won’t fail. The server will
get its time from the localhost as a stratum 10 ntp server. Clients that fetch
time will get time from a higher stratum before moving onto the lower stratum,
so this is considered a fallback if the network fails. Odds are if the network
fails, the server’s time should still be accurate enough to provide time for
other clients until internet access has been restored.

On the client side, make sure you have ntp and ntpdate installed on the client.
Then edit the /etc/ntp.conf file.

Odds are on a client you don’t need the statistics, so you can comment out
statistics, change the server pools to the ip address of your NTP server keep
the restrictions and restart ntp.

For security reasons, the same file permissions apply for the client as they do
for the server. Make sure /etc/ntp.conf is marked read-only (chmod 444) and
only accessible by root (chown root:root).

While still connected to the client, run the following command to see if your
client is successfully connecting to your server before moving onto the next
step.

 ntpdate -d servername 

This should output a bunch of debug information, including the stratum level of
your server (in my case a stratum 3 server) and if it adjusted your time. If
this worked time to move onto the next step. If it didn’t, check your config
files and /var/log/messages.

Access Control Lists

Because NTP can be configured to
broadcast date/time over a subnet ACLs can be a good thing for both a client
and server. For instance if you have an NTP server that, for whatever reason
the admins haven’t been keeping up with or were unaware that they set it up as
a broadcast NTP server; the time is off by hours, days and sometimes even years
(01-01-1970 anyone?), broadcasting to a bunch of clients set to receive NTP
broadcasts can be catastrophic. Another reason for ACLs is to make sure that a
client or server does not have access to modify settings on the server or
client side, just change the time. The positive to this is that NTP allows you
to set ACL based on subnets, so if your internal network has multiple subnets
you can restrict clients based on an ACL..certain clients can get their
date/time from xx NTP server and certain ones can’t.

Keep in mind that ACLs are order-sensitive. In this
case, I deny all then allow, just like when creating firewall rules; you tend
to deny everything then allow what you want through. If you’re not using the
server on the outside of the world; there really is no need to deny all.
Deny All, Allow Some If your NTP server is on the outside of the world
and you don’t want just everyone to have access to it, then the following ACL
will block all access, then allow restrictive access.

# Ignore all
restrict default ignore
restrict -6 default ignore

#Allow localhost
restrict 127.0.0.1
restrict -6 ::1

# Add some time servers
server x.x.x.x restrict x.x.x.x [nomodify notrap nopeer noquery]

server -6 x:x:x:x:: restrict -6 x:x:xx:: [nomodify notrap nopeer noquery]

## Add Some client access
restrict 192.168.1.10

## Add an entire subnet with more restrictions
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
restrict -6 2001;838:0:1:: mask ffff:ffff:ffff:ffff:: nomodify notrap nopeer

Basic LAN Access
For basic LAN access I tend to just go with the following
setup on my NTP server:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

What do the options Mean?
If you see a -6 in restrict, that means
it’s specifically for an ipv6 setup. If your network isn’t IPv6 then you
usually don’t need to worry about this, but it wouldn’t hurt to go ahead and
add the line in while you’re making your changes just in case at some point you
do decide to go to IPv6.

nomodify – This restriction basically says do not allow the host to modify any
ntpd settings. Modify allows certian ntp utilities to modify settings of ntpd
remotely. Nine times out of ten, this will never be necessary, as an
administrator will make changes to the configuration file itself and restart
ntpd.

noserve – do not serve time to this host/subnet. Why you would allow ntpd for
one subnet and not the other is beyond me, but hey they have an option for it

notrust – This setting tells the ntp server to ignore ALL ntp packets that are
not cryptographically authenticated. This means that in order to get time,
both server and client must have the keys setup. More on this in the next
part.

noquery – This is a very useful one. This tells the server not to allow any
host or subnet to query ntpd status. ntpd status may give away information
about the operating system and/or version of ntpd. With this, an attacker may
be able to find a vulnerability against said system. This can be a pro and a
con. By disabling query, you thwart an attempt on the outside of the world
from attacks, but you also you stop clients from seeing synchronization
information about the ntpd server.

Shared Secrets – Symmetric Key Exchange

Ah, the meat and
potatos, Symmetric Key Exchange. Well not really the fun part, but the
complicated and mind numbing part of NTP security. Shared Secrets probably
wouldn’t be used in a SOHO (small office/home office) environment, but more for
a WAN setup where an NTP server might be on the outside of the network, or you
have more than one outside facing NTP servers communicating with each other.
By using Shared Secrets, the lower stratum NTP server can verify without a
doubt that the time they are receiving is from an valid time source. So without
further adieu, lets get started.

Like I stated earlier, this is usually generated for NTP server #1 on the
outside of the network to communicate with another lower stratum NTP server on
the inside of another network, or the outside of another further network. Sure
the case could be made to use Symmetric Key Exchanges between all of your
servers on the inside of your network, and that’s entirely possible.

There are two ways of creating an ntp.keys file, the easy way by just adding
words to a file, and the other way by generating MD5 hashs with ntp-keygen.
I’ll go over both of them here.

Flat Text File Create a new text file called ntp.keys
and populate it as such:

#NTP Keys
1 MD5 MickeyMouse # MD5 key for this server
2 MD5 Goofy # MD5 key for this other server
3 MD5 DonaldDuck # MD5 key for that server

Save the file and there you have it. Not exactly the most secure thing in the
world but it’s easy and quick. 1 is the keyID, MD5 specifies the type,
MickeyMouse is the key itself.

Using ntp-keygen
This is the preferred way of doing things, slightly
messy but works none the less. What I tend to do is create a separate
temporary directory since there will be a bunch of individual files generated
when this is created.

 mkdir ~./tempkeys
cd ~./tempkeys
ntp-keygen -c RSA-MD5 -M 

This will generate a few files, the one we are interested in is:
ntpkey_MD5key_hostname.bunchofnumbers

 mv ntpkey_MD5key_hostname.bunchofnumbers /etc/ntp.keys && chmod
444 /etc/ntp.keys 

*Note: Make sure that with whatever solution that you do use to generate your
ntp.keys, once you are done editing your keys file, change permissions to READ
ONLY.

If your keys are generated, it’s time to modify your server to look for the
keys.

Add the following lines to your NTP server’s /etc/ntp.conf file

###Symmetric Key Authentication enable auth keys /etc/ntp.keys trustedkey 1

What this says is the following: enable authentication, location of keyfiles
and trusted key #1. If you want to add more trusted keys from /etc/ntp.keys
then add them by spaces..ex: trusted key 1 2 3 4, and so on and so forth. There
are other options you can use as well with the keys, such as: requestkey and
controlkey. Requestkey gives authorization to the ntpdc utility, and
controlkey gives access to the ntpq utility.

If you’re done on the server side, remember to change /etc/ntp.keys and
/etc/ntp.conf to read-only, making sure root only has access to the file. Lets
continue to the client side.

Client side symmetric key setup

The steps for client-side symmetric key authentication are quite simple so I’ll
do some step-by-steps here.

1. Pick a line from the server’s /etc/ntp.keys file and copy that entire line.
2. Create a new file /etc/ntp.keys and paste the line that you copied from the
server. Save/Quit the file and mark read-only with root user access only.

Before you make changes to your client’s ntp.conf file we can test the settings
from the command-line with this simple command:

ntpdate -d -a 1 -k /etc/ntp.keys ip.of.ntp.server 

With any luck, you should see ‘receive: authentication passed’. If you didn’t,
make sure your NTP server is allowing it’s UDP port through the firewall, if
your both behind the firewall, check your settings in the servers /etc/ntp.conf
file.

If all goes well it’s time to edit your client’s /etc/ntp.conf file.

Add the following lines to /etc/ntp.conf ## Key Authentication enable auth keys
/etc/ntp.keys trustedkey 1

#Replace your server with the following server ip.of.ntp.server key 1

Once you have made your changes, save and quit your ntp.conf file and restart
ntp.

There you have it! Symmetric Key Authentication.

Conclusion As you can see even something as simple as a
network time protocol can be easily secured against attackers with high level
security. I didn’t go into the more advanced features of AutoKey, but that’s
left up to the reader. Hopefully I have left with you with a little more
knowledge on how to secure your NTP servers against attack from internal or
external influences. And heck, maybe you even learned a thing or two about NTP
that you didn’t know before.