sudo apt-get install ntp
service ntp restart
Network Time Protocol (NTP) presents an unique ability for companies to synchronize the clocks of all the systems within the company. Time synchronization is important for many reasons ranging from application time stamps to security to proper log entries. When an organization’s systems all maintain different clock times, it becomes very difficult from a troubleshooting standpoint to determine when and under what conditions a particular event might be occurring.
NTP provides an easy way to ensure that all systems will maintain the correct time which in turn can greatly simplify the burden on administrators/tech support.
NTP works on the premise of synchronization with reference clocks, also known as ‘stratum 0‘ servers. All other NTP servers then become a lower level strata server based upon how far they are from a reference server. The start of the NTP chain is a stratum 1 server which is always directly connected to a stratum 0 reference clock. From here, lower level strata servers are connected via a network connection to a higher strata level server. Refer to the diagram below for a clearer concept.
While setting up a stratum 0 or stratum 1 server can be done, it is expensive to do so and as such this guide will focus on lower strata server setup. Tecmint has a basic host configuration of NTP at the following link:
Where this guide will differ is rather than having all of the hosts on the network querying out to public NTP servers, one (or better practice, several) server(s) will contact the public NTP system and then provide time for all hosts within the local network.
An internal NTP server is often ideal to conserve network bandwidth as well as provide some increased security through NTP restrictions and cryptography. To see how this differs from the first diagram, please see the second diagram below.
Step 1: Installation of NTP Server
1. The first step to setting up an internal NTP structure is to install the NTP server software. The software package in Debian called ‘NTP‘ currently contains all of the server utilities necessary to setup a NTP hierarchy. As with all tutorials about system configuration, Root or sudo access is assumed.
# apt-get install ntp # dpkg --get-selections ntp [Can be used to confirm NTP is installed] # dpkg -s ntp [Can also be used to confirm NTP is installed]
Step 1: Configuration of NTP Server
2. Once NTP is installed, it is time to configure what higher stratum servers to query for time. The configuration file for NTP is stored at ‘/etc/ntp.conf‘ and can be modified with any text editor. This file will contain the fully qualified domain names of the the higher level servers, restrictions set for this NTP server, and any other special parameters for hosts querying this NTP server.
To start the configuration process, the higher level servers need to be configured. Debian by default will put the Debian NTP pool in the configuration file. These are fine for most purposes but an administrator can visit NISTto specify certain servers or to use all of NIST’s servers in a round robin fashion (suggested method by NIST).
For this tutorial specific servers will be configured. The configuration file is broken into some major sections and is configured by default for IPv4 and IPv6 (If you wish to disable IPv6, there is mention to this later). To start the configuration process, the configuration file must be opened with a text editor.
# nano /etc/ntp.conf
The first few sections (driftfile, statsdir, and statistics) are fine set to the defaults. The next section contains the higher level servers through which this server should request time. The syntax for each server entry is very simple:
server <fully qualified domain name> <options> server time.nist.gov iburst â [sample entry]
Typically it is a good idea to have several higher strata servers to choose from in this list. This server will query all of the servers in the list to determine which one is the most reliable. The servers for this example were obtained from: http://tf.nist.gov/tf-cgi/servers.cgi.
Step 3: Configuration of NTP Restrictions
3. The next step is to configure NTP restrictions. These are used to allow or dis-allow hosts to interact with the NTP server. The default for NTP is serve time to anyone but do not allow configuration on both IPv4 and IPv6 connections.
This server is currently only used on an IPv4 network so IPv6 was disabled by two means. The first thing done to disable IPv6 on the NTP server was to change the defaults that the daemon starts. This was accomplished by changing the line in ‘/etc/default/ntp‘.
# nano /etc/default/ntp
NTPD_OPTS='-4 -g' [Add the ' -4 ' to this line to tell NTPD to only listen to IPv4]
Back in the main configuration file (/etc/ntp.conf), the NTP daemon will be automatically configure to share time with all IPv4/6 hosts but not allow configuration. This can be seen by the following two lines:
NTPD works on an allowed unless denied basis. Since IPv6 was disabled, the ‘restrict -6‘ line can be removed or commented out with a ‘#
This changes the default behavior for NTP to ignore all messages. This may seem odd but keep reading as restrict clauses will be used to fine tune access to this NTP server for the hosts that need access.
Now the server needs to know who is allowed to query the server for time and what else they are allowed to do with the NTP server. For this server, a private network of 172.27.0.0/16 will be used to build the restrict stanza.
This line informs the server to allow any host from the 172.27.0.0/16 network to access the server for time. The parameters after the mask help to control what any of the hosts on this network can do when querying the server. Let’s take a moment to understand each of these restrict options:
Limited: Indicates that if a client should abuse the number of packets rate control, the packets will be discarded by the sever. If the Kiss of Death packet is enabled, it will be sent back to the abusive host. The rates are configurable by an admin but the defaults are assumed here.
KOD: Kiss of Death. If a host violates the limit of packets to the server, the server will respond with s KoD packet to the violating host.
Notrap: Decline mode 6 control messages. These control messages are used for remote logging programs.
Nomodify: Prevents ntpq and ntpdc queries that would modify the server’s configuration but informational queries are still permitted.
Noquery: This option prevents hosts from querying the server for information. For example without this option hosts can use ntpdc or ntpq to determine where a particular time server is getting it’s time from or other peer time servers that it may be communicating with.
Step 4: Querying NTP Server Network
This is a moderately restrictive configuration for a network. As a result of these restrictions, there will be some issues with the time servers that this server wishes to query.
In order to correct this issue, a restrict statement needs to be added for each of the time servers that are being queried. These restrict stanzas ensure that this server can access higher level servers to get the appropriate time off-set. Below is the proper stanzas for allowing the servers previously configured in the ntp.conf file.
NTP Server Restricts
Back just before step three, a list of servers was determined to be the primary NTP servers for this server to query. As configured currently though, the ‘restrict default ignore‘ stanza will prevent this server from communicating with the servers configured.This can be changed by creating a specific server/restrict stanza for each server. This is an easy process and must be done for each server.
Server 220.127.116.11: This line must have the IP address rather than the host name. This is for safety and will help avoid issues should DNS be compromised.
restrict 18.104.22.168 mask 255.255.255.255 nomodify notrap nopeer noquery: This line does quite a bit. The first part allows the server 22.214.171.124. The nomodify, nopeer, notrap, and noquery restrict what the server (126.96.36.199) is allowed to do to this NTP server.
Note: The IP address for this part can be easily determined with the use of the nslookup command.# nslookup time-a.nist.gov [The system will reply back with the IP address]
5. At this point, the system will be ready to start keeping track of time. The configuration changes now need to be saved and the NTP service needs to be restarted.# service ntp restart
The server will take a few seconds to synchronize with the configured NTP servers but the process can easily be monitored with ‘ntpdc‘ or ‘ntpq‘ utilities.# ntpdc -pn [This utility will provide basic information about the higher level NTP servers] # ntpq -pn [This utility will provide slightly more information than 'ntpdc']
The arguments in the two commands do the same thing. The ‘-p‘ will print a list of peers as well as the current state and the ‘-n‘ will tell the utilities to show the remote server’s IP address rather than hostname.
The important piece of this 'ntpdc' output is the far left of the IP addresses. The asterisk ( * ) character indicates that server has chosen that server’s clock to synchronize time.
The important part from this output is again the asterisk ( * ) character as it indicates a synchronization. The other symbols have meanings as well, for instance the plus ( + ) symbol denotes possible candidates for synchronization and then the minus ( - ) indicates an outlier that is discarded for the time being. The minus doesn’t mean the other servers wont be used, rather it indicates that the particular server isn’t the best option.
At this point and assuming that the server’s time zone has been set properly, the server will be reflecting the right time and have synced with an upper strata server! At this point, more internal servers can be added and ‘peered’ or hosts within the network can be directed to the new internal NTP server rather than having to query out to the public NTP servers.
Step 5: NTP Client Configuration
6. The purpose behind this server setup was to create a Strata 2 server that an internal network could query for time. At this point, the server is running ( and hosts need to be directed to query this newly created internal server.
These next steps will assume a Linux machine is attempting to gather time from the newly created Strata 2server. The first step on the Linux host is to install the NTP package.# apt-get install ntp
This will install the same NTP package that was just installed on the server but this time, NTP will be configured to look at the local server rather than public NTP severs. On the host, open the configuration file ‘/etc/ntp.conf‘.# nano /etc/ntp.conf
Much of the configuration will be the same on this Linux host except the server stanzas will now point to the internal server as seen below.
Save the configuration and exit nano. At this point the client is configured to listen to time from the newly created server (be sure to substitute the appropriate server name and IP addresses in the green boxes)! Next restart the NTP service and confirm that the host is synchronizing with the newly created Debian NTP server.# service ntp restart # ntpdc -pn # ntpq -pn
The following screen-shots confirm that this host is synchronizing clocks with the newly created NTP server. This is confirmed both with ‘ntpdc‘ and ‘ntpq‘ by verifying the asterisk ( * ) by the IP address of the local NTP server.
At this point the Debian server is pulling the correct time from the Strata 1 servers and then handing out proper time to the internal network hosts. Now other devices can be configured to query this NTP server as well for time.
This particular configuration has been tested and works with multiple Cisco devices, other Debian Linux servers, and several Debian/Ubuntu based distributions. Enjoy the newly functioning Debian NTP server!