|
||||||
NTP Network Time Protocol (RFC 1305)Introduction to Time in a Networked Environment
NTS-3000 Elproma NTP Network Time Server
NTP Security
The notion of accurate time is essential to determining the order in which events occur. This is a fundamental aspect of transactional integrity, system and networkwide logging and auditing, and troubleshooting and forensics. Having an accurate time source plays a critical role in tracing and debugging problems that occur on different platforms across a network. Events must be correlated with each other regardless of where they were generated. Furthermore, the notion of time (or time ranges) is used in many forms of access control, authentication, and encryption. In some cases, these controls can be bypassed or rendered inoperative if the time source could be manipulated. For example, a payroll function could be tricked into providing access over a weekend when normally it would be restricted to normal business hours.
Many organizations have become reliant on NTP just as they are with other services such as the domain name service (DNS). This reliance can be a weakness if the service is not properly safeguarded. Therefore, it is important that these time sources are adequately protected against a wide array of threats, both internal and external, local and remote. Time is not just an extraneous service. It is fundamental to the successful operation of today’s environments. The most significant risks to NTP services are tampering and jamming. Tampering occurs when the NTP server is affected by either accidental or malicious data modification. Jamming occurs when a time server is either destroyed or prevented from providing NTP service. As with any other application, administrators must remember that NTP is not guaranteed to be secure; poor coding and other flaws in the program could allow unintended access to NTP internals or the underlying operating system.
The NTP service is capable of protecting itself against some of these threats using architectural choices such as redundancy, and configuration options such as access control and authentication. Redundancy and its impact on an NTP implementation was discussed previously. Access control is achieved by restricting what NTP functions can be accessed from specific hosts or networks. Authentication is currently provided using symmetric keys that are installed on the NTP servers and clients. Both access control and authentication are discussed in more detail in the forthcoming articles of this series.
NTP components
Several components make up the NTP distribution. The NTP daemon, xntpd, is the usual method for using NTP. The ntpdate program can be used for fast initial synchronization before using xntpd, or instead of xntpd. The use of ntpdate instead of xntpd is discouraged, for reasons discussed below. In addition, this section discusses how the ntpq, xntpdc, and ntptrace commands can be used to monitor and control NTP clients and servers.
xntpd The xntpd process is the NTP daemon. The same daemon is used both for client and server. The file ntp.conf configures the NTP servers and clients. The advanced options enable access control, authentication, monitoring, remote management, and better time approximation.
In UNIX familly systems running default installations, the daemon is started automatically. In default installations, the ntp.conf file does not exist, so the daemon never starts. A configuration can be created from scratch or copied. If the configuration is changed, the daemon will need to be stopped and restarted in order to update the configuration without rebooting. The xntpd process can be started or restarted at any time. While most of the configuration is taken care of by the ntp.conf file, there are a few command flags. While the command flags allow easy configuration from the command line, using them is discouraged, because the same can be accomplished using the configuration file. The advantage of using the configuration file is that all the configuration information is easily determined if troubleshooting is necessary.
The xntpd process can communicate both time and configuration information. If enabled, this allows the configuration for xntpd to be queried or changed remotely. There are two different types of configuration messages which can be sent: mode 6 messages and mode 7 messages. Mode 6 messages are sent by the ntpq program and most mode 6 messages are informational. The others deal with setting variables. Mode 7 messages are sent by the xntpdc program. Mode 7 messages can be informational or can allow remote changing of the NTP configuration.
ntpdate The ntpdate program allows a client to set its date from an NTP server without permanently running the NTP daemon. Multiple servers can also be specified to allow a better selection for the best time source. Essentially, this allows a one-shot NTP transaction. Because this interaction only occurs once, the clock will eventually stray again. Repeated usage of ntpdate can overcome this, but is far from an ideal solution. Some system administrators run an ntpdate command on an hourly, daily, or weekly basis as a cron job, which is capable of keeping servers in sync within a few seconds. This light-weight solution is useful in some environments because it requires one less daemon, gives the administrator more control over NTP traffic, and is easy to configure. However, in nearly all cases, the problems are likely to outweigh the benefits. The processor load of the NTP daemon is small, so little is gained by disabling it. In addition, many clients run cron jobs simultaneously, which causes blasts of network traffic for every cron job in the span of a few seconds. This is likely to overwhelm the network, and possibly even the server (if the server is small and has a large number of clients). The client-side xntpd process randomizes the delay before a time request is made, so that this overwhelming does not occur. Since both the ntpdate cron job and the NTP daemon are simple to configure, there is no clear management advantage to either.
A final advantage of xntpd over ntpdate is that it produces a much better time sync. This is due to several facts. Unlike ntpdate, xntpd can limit the wander of the clock based on historical data—even when a time server is unavailable. The xntpd process does time adjustment continuously, so the changes to the time can be very small, so it rarely needs to use the time jumps that are likely to occur when ntpdate is run.
ntpq The ntpq program allows querying the state of the NTP daemon on a local or remote machine. Using ntpq, an administrator can check the configuration of a remote host. If such queries are allowed on a host, this can be a useful way of choosing hosts to synchronize with, because information such as their peers and reference clock types can be determined. Since ntpq uses UDP packets, hosts may be falsely unreachable on congested networks.
xntpdc The xntpdc program also allows querying the state of a local or remote NTP daemon, however, xntpdc can also make runtime configuration requests to a remote machine. This allows changing the configuration on the fly. In order to make runtime configuration changes, an authentication key is needed. This requires the creation of an NTP keys file, which is described in the xntpd man page. Like ntpq, xntpdc uses UDP packets.
ntptrace The ntptrace is an informational command that traces the source of a given client’s time. The information found by ntptrace can be determined by successive runs of ntpq on each client’s preferred server. However, ntptrace allows an easy and convenient way of learning this information. This can be a useful tool for debugging. The following is an example of ntptrace output. The ntptrace output lists the client name, its stratum, its time offset from the local host, the synchronization distance, and the ID of the reference clock attached to a server, if one exists. The synchronization distance is a measure of clock accuracy, assuming that it has a correct time source. For the exact derivation, refer to the NTP specification.
NTP Versions and Issues
NTP is perhaps one of the oldest and most used protocols on the Internet. The first version of NTP was released in 1985, but is no longer in common usage. The specifications for version 3, the latest official version, were released in 1992. The Internet RFC 1305 provides the specifications for version 3 of the NTP protocol. The latest version of NTP is 4 (NTPv4) and it is including advanced cryptographic authentication features. You can find more information on NTP on www.ntp.prg.
|
||||||
|
