Which network service synchronizes the time across all devices on the network?

Network Time Protocol

Network Time Protocol (NTP) is a protocol that allows the synchronization of system clocks (from desktops to servers). Having synchronized clocks is not only convenient but required for many distributed applications. Therefore the firewall policy must allow the NTP service if the time comes from an external server.

NTP is a built-on UDP, where port 123 is used for NTP server communication and NTP clients use port 1023 (for example, a desktop). Unfortunately, like many legacy protocols, NTP suffers from security issues. It is possible to spoof NTP packets, causing clocks to set to various times (an issue for certain services that run periodically). There are several cases of NTP misuse and abuse where servers are the victim of DoS attacks.

As a result, if clock synchronization is needed, it may be better to provide an internal NTP server (master clock) that synchronizes the remaining clocks in the internal network. If synchronization is needed by an NTP server in the Internet, consider using a bastion host.

Network Time Protocol

Network Time Protocol (NTP) is a protocol that provides a very reliable way of transmitting and receiving an accurate time source over TCP/IP-based networks. NTP, defined in Request for Comments (RFC) 1305 (www.ietf.org/rfc/rfc1305.txt), is useful for synchronizing the internal clock of the computers to a common time source. Some systems, such as Novell NetWare's Novell Directory Services (NDS, or now known simply as e-Directory) as well as Microsoft Windows Server 2003 and 2000, rely on a time source to keep things running right. For system maintenance, troubleshooting of issues, and documentation, it is important that all systems be time synchronized. In addition, for prosecution of security breaches or attacks, security logs need to be accurate and so on. NTP, when used properly, can have a hierarchical disaster recovery system designed into it, with primary sources of time as well as secondaries. Having the correct time on your system(s) is very important. Many problems can surface if networked machines are not synchronized.

7.3.6.2 NTP Protocol Definition Unit (PDU)

Both the NTP request message and NTP response message are encoded as fixed-size arrays of 64 bytes. The NTP PDU format overlays the linear byte array with a structure that collects the bytes into various fixed length fields and thus maps out the application meaning of the message content. Figure 7.11 shows the NTP PDU, which defines the format of NTP request and response messages.

The NTP request message is populated as follows: The entire 48-byte array is zeroed out, and then the LI, Version, and Mode fields are set to the values 3, 4, and 3, respectively; this indicates that the message is an NTP version 4 message sent from the client (i.e., a request), with a currently unsynchronized clock (i.e., the timestamp values in the message are not meaningful). See Figure 7.12.

Figure 7.12 shows the program code that sets the NTP request message content and sends the message, in the time service client library component. Only the first byte is configured to inform the recipient that the type of message is a request (from a client) and is conformant to NTP version 4.

Figure 7.13 shows the receive method of the library component. This method is called when an NTP request message has been sent (over UDP) to the NTP time server and an NTP response is expected (also over UDP). The combined use of a short time delay and a single call to recvfrom (i.e., not repeated periodically in a loop) with the socket configured in nonblocking mode meets a useful compromise between the three potentially conflicting requirements of low-latency responsiveness, robustness, and simple design. The nonblocking socket mode ensures reliability in the sense that the call will return regardless of whether the NTP server responds or not. This is essential to prevent the NTP client library code from blocking indefinitely if the NTP server crashes or if either the request or response message is lost or corrupted in the network.

The use of the 500 ms delay allows for the round-trip time (RTT) of sending the request message and receiving the response. Network delay is continuously changing, and therefore, there can never be a perfect statically decided time-out value for long-haul network transmissions (as in the case of contacting NTP time servers). The 500 ms-delay value was found experimentally to be a good compromise between waiting long enough so that NTP responses are caught in almost all cases and on the other hand not inserting too much additional latency. Even if the RTT was near instantaneous, this approach only inserts half a second of latency.

The timestamp is held in bytes 40-47 of the response message (the Transmit Timestamp field). The timestamp value is 64 bits wide, the most significant 32 bits representing the number of seconds and the least significant 32 bits representing the fraction of seconds. For the case study application, it was deemed adequate to only consider the whole seconds part of the timestamp (hence, the values of bytes 40-43 are used as can be seen in the code in Figure 7.13). In applications where greater precision is needed, the fractional part of the timestamp can also be taken into account.

Abstract

The Network Time Protocol (NTP) is widely deployed in the Internet to synchronize computer clocks to each other and to international standards via telephone modem, radio and satellite. The protocols and algorithms have evolved over more than a decade to produce the present NTP Version 3 specification and implementations. Most of the estimated deployment of 100 000 NTP servers and clients enjoy synchronization to within a few tens of milliseconds in the Internet of today.

This paper describes specific improvements developed for NTP Version 3 which have resulted in increased accuracy, stability and reliability in both local-area and wide-area networks. These include engineered refinements of several algorithms used to measure time differences between a local clock and a number of peer clocks in the network, as well as to select the best subset from among an ensemble of peer clocks and combine their differences to produce a local clock accuracy better than any in the ensemble. This paper also describes engineered refinements of the algorithms used to adjust the time and frequency of the local clock, which functions as a disciplined oscillator. The refinements provide automatic adjustment of algorithm parameters in response to prevailing network conditions, in order to minimize network traffic between clients and busy servers while maintaining the best accuracy. Finally, this paper describes certain enhancements to the Unix operating system kernel software in order to realize submillisecond accuracies with fast workstations and networks.

6.6.1.3 Network Time Protocol (NTP)

In use since 1985, the NTP is the most popular Internet time protocol. It is based on UDP, therefore having low networking overheads and low service response latency because it does not need to establish a TCP connection.

An NTP client periodically requests updates from at least one server. When multiple servers are used, the client averages the received time values, ignoring any outlier values (in a similar way to that used by the master server in the Berkeley algorithm; see later text).

NTP provides greater precision than the TIME and DAYTIME protocols. It uses a 64-bit time stamp value representing the time in seconds since January 1, 1900, and has a resolution of 200 picoseconds (although this level of precision cannot generally be leveraged due to dynamic network delays that can fluctuate by values significantly larger than this).

The use of NTP within distributed applications has been discussed in Chapter 3, where it is also used as an example of a request-reply protocol and explored in a practical activity using an NTP client application that has been built into the Distributed Systems Workbench.

An alternative to the continual operation of NTP is the similar but more lightweight SNTP that supports single time requests when needed (as opposed to the periodic nature of NTP usage).

Figure 6.21 illustrates infrastructural features of the NIST time service provision, showing the differentiation between the internal and external aspects of the service. The internal service configuration synchronizes the NIST internal time value to UTC/GMT and also synchronizes the NIST time servers to each other. Externally, NIST provides a number of time services that each serves the same time value but in different formats and with different levels of precision. Of these services, NTP and SNTP are the most important due to communication efficiency and precision of time values.

All of the NIST time services provide transparency to clients in the sense that clients do not need to be aware of the internal configuration and behavior of the NIST system, of the multiplicity of time services, or of the replication of NIST time servers.

Maintaining System Time

Another important consideration for the SSH server is the system time. You might think that having inaccurate time is a trivial thing. Without an accurate system time, all system logs become less valuable for forensics. This is especially true when it comes to pursuing legal action. If you cannot state with certainty when an action occurred, prosecution will be that much more difficult. If you are performing centralized log collection, it will make sorting through them all that much more difficult when events on different systems cannot be correlated to a common clock.

Configuring your SSH server to use NTP (Network Time Protocol) to keep the system clock accurate is very easy. If NTP is not already installed, you will need to install it. On most Linux distributions, NTP comes pre-installed though it may or may not be enabled. On a Redhat-based system, you can check the run levels of installed services by entering the following:

#chkconfig –list | grep ntp

ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

If ntpd is not enabled, you can enable it for runlevels 2-5 by entering:

chkconfig –level 2345 ntpd on

The NTP process can be started by entering ntpd in a terminal window. Once ntpd is enabled, it is controlled through the /etc/ntpd.conf or /etc/ntp.conf configuration file, depending on your distribution.

The configuration file needs two lines at a minimum to get things working. The following line tells NTP which server to use as a time source, in this case clock.redhat.com:

server clock.redhat.com

The next line will ensure that NTP will receive time from clock.redhat.com but will not allow that time server to modify your server's configuration (nomodify) or pull time from your server (noquery):

restrict clock.redhat.com mask 255.255.255.255 nomodify notrap noquery.

You can verify that NTP is synching with the time server by running ntpq –p. Initially the time may be off by a large margin. If this is the case, you can use ntpdate <timeserver> to set the time before letting ntpd manage the smaller adjustments. You may need to run ntpdate multiple times before it will adjust the time completely. This entire process is shown in Figure 12.3.

Ntpdate will not set the time if ntpd is currently running. In order to make the large adjustments using ntpdate, stop ntpd first using service ntpd stop for example.

The most critical value for the ntpq output is the offset, which is the difference between the system clock and the referenced time source; it is expressed in milliseconds. You should configure more than one time server if possible so that ntpd can use all of them to select the best time. This also helps ensure that any single faulty time source cannot misadjust all your devices to the wrong time.

World NTP Servers

Examining the methods and properties may seem a bit confusing at first; however, using the library module is in fact quite simple. Simply put we want to create an ntp client capable of accessing a specified ntp server to obtain a third-party source of time. In the United States, NIST manages a list of time servers that can be accessed to obtain “root” time (Figure 6.9).

Updated lists can be found at: http://tf.nist.gov/tf-cgi/servers.cgi.

In Europe, you can find an active list of NTP servers at the NTP Pool Project. Figure 6.10 shows a screenshot from their home page at http://www.pool.ntp.org/zone/europe.

For those of you wishing to obtain your time from the U.S. Naval Observatory or USNO, you might be interested to know that for many years, the USNO has provided access to NTP servers’ aptly named tick and tock. For more information on the U.S. Naval Observatory you can visit: http://www.usno.navy.mil/USNO.

3.3.2 Request-Reply Communication

The request-reply communication mechanism is the basis of a popular yet simple group of protocols in which simple two-way communication occurs between a specific pair of processes.

A generic description of request-reply communication is as follows: Interaction begins with a request for service message, which is sent from a service requestor process to a service provider process. The service provider then performs the necessary computation and returns the result in a single message to the requestor; see Figure 3.4.

Figure 3.4 shows the request-reply protocol concept. The essence of this strategy is that control flows to the service provider, that is, a request message, and data (the result of the request) flow back to the requestor.

A popular and easy to understand example of a request-reply protocol is the Network Time Protocol (NTP) service, which is one of several time services that constitute the Internet Time Service (ITS) provided by the National Institute of Standards and Technology (NIST), based in the United States. Synchronizing the time value of the clock on a computer to the correct real-world time is a vital prerequisite action in order that many applications function correctly. NTP provides a means of getting an accurate time value from one of a pool of specially designated NTP time servers. The synchronization among the various time servers within the ITS service itself is performed separately with its own internal hierarchical structure comprising several stratum's (layers) of clocks, with highly accurate clocks, such as atomic clocks, in stratum 0. It is a very important point to note that external users of the NTP service do not need to know any details of this internal configuration; they simply send a request message to any one of the NTP time servers and receive a response containing the current time value. The ITS NTP service operation is illustrated in Figure 3.5.

Figure 3.5 shows how the NTP service is accessed to retrieve a current time stamp value. In step 1, a request message formatted to comply with the NTP protocol is sent to one of the pool of NTP servers. In step 2, the specific NTP server responds with a reply message, which is sent back to the original requester (who is identified by examining the source address details in the request message). Part A of the figure provides an overview of the actual system, while part B shows the user's simplified view of the system. This example provides some important early insights into transparency requirements for distributed systems services: the NTP client does not need to know the details of the way in which the ITS service operates internally (in terms of the number of participating NTP servers and the way in which updates and synchronization are performed among the servers) in order to use the service. In terms of behavior, the NTP time service should provide a low-latency response, further reinforcing the transparency as seen by the user. In this respect, the NTP server instance should return the instantaneously available time value from its local clock, which has been presynchronized by the NTP service itself, rather than requesting a fresh synchronization activity within the service. Figure 3.6 provides pseudocode for an NTP client.

Activity C2 explores request-reply protocols and the behavior of the Network Time Protocol (NTP) using the NTP client provided within the Distributed Systems Workbench.

Activity C2

Using the Network Time Protocol (NTP) Client Within the Distributed Systems Workbench to Explore Request-Reply Protocols and the Behavior of NTP

The US National Institute of Standards and Technology (NIST) maintains the Internet Time Service (ITS), which provides a number of well-known standard time services, one of which is the Network Time Protocol service.

Expected Outcome

The first screenshot below shows the NTP client in operation, using the wolfnisttime.com NIST time server. The URL wolfnisttime.com has been resolved to IP address 207.223.123.18 and a series of NTP time requests have been sent, and responses received.

The screenshot below illustrates the use of NIST's global address time.nist.gov. In this instance, it resolved to the server at IP address 128.138.141.172. This screenshot also reveals the unreliability of UDP; NTP requests are carried over the UDP, and you can see that while 86 requests were sent, only 84 responses were received.

The screenshot below shows how NIST's global address time.nist.gov resolves to different NIST time server addresses at different times. In this instance, it resolved to the server at IP address 24.56.178.140.

Network Time Protocol (NTP)4

If you will never need to use the log information generated by the FortiGate for legal or HR purposes, it is essential to ensure that the local clock is accurate. This is also essential if you plan to use a two-factor solution, as this will help to avoid problems with clock skew between the FortiGates and the tokens. Time synchronization also makes it much easier to analyze the timeline of an event if the clocks on all the systems involved are synchronized.

You can configure the system time and time zone manually from the Web UI dashboard System Information widget. You also configure an NTP server here, so the FortiGate can pull it’s time from a trusted source. Fortinet supplies pool.ntp.org as a default which should be fine for most uses. However, if your company runs an internal NTP server, it may be more appropriate to use that. While the Web UI allows you specify only a single NTP server, FortiOS actually supports the configuration of multiple servers through the CLI. Configuration of time servers based on the NTPv3 protocol is also available from the CLI, this version of the protocol requires an authentication string for access, so it is disabled by default and is normally only used when connecting to an internal NTP server.

config system ntp

 config ntpserver

  edit 1

   set ntpv3 disable

   set server “pool.ntp.org”

  next

  edit 2

   set ntpv3 enable

   set server “privateNTP.example.com”

   set authentication enable

   set key-id 1

   set key <passphrase>

  end

 set ntpsync enable

 set syncinterval 60

end