Time Synchronization in a UNIX/NT Environment
Nalneesh Gaur Heterogeneous environments are increasingly demanding better security measures. One such aspect of security is accurate time keeping. Any client/server operating system can expect to drift by several seconds each day depending on system activity and the platform. If unchecked, any system at a given time may be farther apart in time from another system in the same enterprise. The Network Time Protocol (NTP) provides a reliable and accurate time source. Both UNIX and Windows NT provide system administrators with software options to synchronize the time in these environments. Additionally, Windows NT 5.0 is expected to implement Kerberos authentication. Kerberos relies heavily on time synchronization to prevent replay attacks, thereby making time synchronization essential. This article stresses the necessity for accurate time keeping, discusses the implementation of time-synchronized UNIX/NT networks, and provides details on the different tools available for UNIX and Windows NT. Time Keeping In networking environments, resources are accessed by different client/server applications. Listed below are some of the items that emphasize the requirement for accurate time keeping.
2. System logs may reflect unreal values if time is inconsistent between servers.
3. Excess system activity may cause the systems clock to lag behind the "real time."
4. Kerberos is planned to be at the heart of Windows NT 5.0 authentication and is currently being used in many UNIX environments. The Kerberos authentication service protects against certain types of attacks by time stamping transactions.
5. NIS+, secure shell, and secure RPC rely on time stamps to prevent replay attacks. 6. Software builds can be unpredictable when the development-team platforms differ on system times. David Mills developed the Network Time Protocol (NTP) at the University of Delaware. The NTP is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. NTP is capable of maintaining time consistency within a millisecond on LANs and within a few tens of milliseconds across WANs. NTP is freely available and runs on all the variants of UNIX and Windows NT. NTP, currently at version 3, is capable of communicating with older versions of NTP servers. NTP provides a structured and accurate method for distribution of timestamps. NTP is built on top of the TCP/IP protocol. The protocol is capable of synchronizing multiple hosts over extended periods of time. Timeservers are organized as a series of stratums (see Figure 1). The stratum 0 consists of hardware clocks such as the radio and the atomic clocks. The devices in stratum 0 are connected to computers known as stratum 1 servers. Stratum 1 servers provide the most accurate times and thus serve as the primary network time standards. The stratum 1 servers can provide time service to multiple stratum 2 servers. It is desirable that the stratum 1 servers do not serve time directly to hosts since they may be overwhelmed with time stamp requests. The stratum 2 servers further distribute time to stratum 3 servers and so on. The number of strata is limited to 15, however. The lower strata are generally less accurate. NTP also adjusts time stamps for travel time due to network delays caused by network latencies inherent in various network components. NTP allows for encryption of time stamp packets to prevent an attack on NTP itself. However, it is important to note that the encryption may not be worthwhile if any of the servers in the chain of servers does not use encryption. The RFC 1305 (http://ds.internic.net/rfc/rfc1305.txt) describes the NTP protocol in detail. More information on the protocol, along with source code, can be obtained from http://www.eecis.udel.edu/~ntp. Most operating systems periodically check the hardware clock to adjust the OS time (software clock). Any drift in the OS clock is adjusted in gradual steps or "ticks" until the hardware time and the OS time are synchronized. This process of gradually adjusting the OS time is called the clock slew rate. Because NTP conflicts with the OS-based clock synchronization, it is recommended that the OS-based clock synchronization be turned off. On Solaris the software clock can be turned off by editing the /etc/system file and adding set dosynctodr=0. Please refer to the specific system documentation to turn off the softclock option. NTP Servers NTP operation imposes a small load on the server. Therefore, a departmental file server can be used to run the NTP server software. It is recommended that one NTP server be used for each subnet. Installation For UNIX-based systems, the distribution of the source code includes the configure command. This command will, by default, detect various options required for the successful compilation of the executables. By default the debugging option is turned on. The -prefix option can be used to specify a directory for the installation of the architecture specific files. By default, drivers for all reference clocks are included. The -disable option can be used to disable drivers that are not required. Upon completion of the configure command, make should be run to successfully compile the NTP programs. A successful compilation will result in the executables - xntpd, xntpdc, ntpq, ntpdate, tickadj, and ntptrace. The NTP server for NT has been successfully ported to Windows NT, however the server is unsupported. Commercial versions of the NTP server are available from sites such as Coetanian systems (http://www.coetanian.com). The NTP distribution contains the NTP port of NT. The NTP server for NT is supported for NT versions 3.5, 3.51, and 4.0. NTP for NT requires the latest InstallShield SDK for Windows NT 4.0, Perl5 for Win32 (available at http://www.activestate.com/software), and a C compiler. The %PATH% environmental variable must contain the path to the C compiler and the PERL 5 binaries. The NTP server, when installed properly, provides NT Event Logging. The NTP distribution contains a brief description of the installation procedure. Additionally, the documentation lists NTP server enhancements for NT, known bugs, and future plans. The distribution builds the installation files including the setup.exe file and the NTP executables prior to installation. Pre-built binaries for NTP server for Windows NT are currently unavailable. Configuration The configuration file utilized by xntp is located at /etc/ntp.conf. In its simplest form, the configuration file can contain the name of one or more servers to synchronize the time against. The client running xntpd can receive synchronization from any of the servers listed in the configuration file. Using the keyword "server" followed by the host name or the dotted IP address specifies servers. The NTP distribution documentation recommends that at least three servers be listed for redundancy. The keyword "peer" defines any host that is expected to both receive synchronization from another server, as well as to provide synchronization to it. The "peer" keyword can also have an authentication key associated with it. Normally the xntp daemon takes a day to compute the intrinsic clock frequency error. The value changes minimally after its initial computation. The frequency error can be stored in a file specified by the configuration file's "driftfile" keyword followed by the file name. Should xntpd have to be restarted, it will read the "driftfile" instead of re-computing the error. NTP will enable the authentication option when "authentication yes" is added to the configuration file. The authentication option will reject all packets that cannot be decrypted, unauthenticated packets, and packets encrypted with keys that are not trusted anymore. Every transmitted NTP packet will contain a 32-bit key ID and a 64/128-bit cryptographic checksum. The checksum is computed using either the Data Encryption Standard (DES) or the Message Digest (MD5) algorithms. This causes the receiving pair to re-compute the checksum and compare it to the checksum included with the packet. The shared and key IDs must be the same between the peers. The keyword "key" followed by the key ID after the peer host specifies the keys from the keys database. The keyword "keys" followed by the file name in the configuration file informs xntpd about the location of the authentication keys. The keys file consists of keys IDs and associated keys. NTP also uses a keyword called "trustedkeys" to invalidate any compromised keys. A sample ntp.conf file is provided in Listing 1. The configuration file lists stratum 1 servers for synchronization. Three peers are listed along with their key IDs. Note that the "trustedkeys" lists only two key IDs as one of the hosts key is probably compromised. The /etc/services file on the host machine must be configured to accept UDP packets on the NTP port 123. NTP is specifically designed to use connectionless UDP and will not respond to TCP. Startup The NTP distribution documentation recommends running tickadj and ntpdate prior to starting the NTP daemon. Running the following command can start the NTP daemon (xntpd)
brahe# xntpd -c /etc/ntp.conf -l /opt/ntp/logs/log.txt
The -l option specifies a log file. The NTP daemon should be added to the system startup files for the NTP daemon to start automatically upon bootup. Time Service for Windows NT Timeserv is part of the Windows NT resource kit for Windows NT versions 3.5 and above. Timeserv is a service for Windows NT that can set the server/workstation's time from a variety of resources. The Timeserv service runs in the background even when no one is logged on to the system. This service sets the Windows NT systems clock to within 10 milliseconds of the source. The Timeserv service implements a simple adaptation of NTP and as such may not compare well with the accuracy and reliability of NTP. Timeserv is capable of obtaining timestamps from NTP-based servers as well as from other Windows-based machines. The Timeserv service can be implemented as multi-tiered time synchronization architecture. Figure 2 shows such a Windows NT Time Service architecture. Server machines installed with the Timeserv software are considered to be either (a) master server, (b) primary time server, or (c) secondary timeserver. A master server is a machine that synchronizes its system clock by communicating with a reliable timeserver such as the timeserver at NIST or the USNO. The master timeserver thus becomes the timeserver for all internal hosts. A primary timeserver machine synchronizes its time with a master timeserver and is made available as the time source for a secondary timeserver. A secondary timeserver request synchronizes its time against another timeserver from a specific NT domain. The master Timeserv server itself may be adequate for most small LANs. The master server can also synchronize against an NTP server on the LAN. Installation of the Timeserv service is straightforward. The Microsoft Windows NT Resource Kit CD-ROM contains the timeserv.exe, timeserv.dll, and the timeserv.ini file. A timeserv.wri file on the CD-ROM provides details on the Time Service. The timeserv.exe and the timeserv.dll files must be copied to %systemroot%\system32. The timeserv.ini file must be copied to %systemroot% (on my system %systemroot% points to c:\winnt). After copying the files, timeserv.exe must be run with either a -automatic or -manual option. This option specifies whether Timeserv will be automatically started or will need to be started manually upon system bootup. The Timeserv service can be started from the Services utility in the control panel. The Timeserv program refers to the timeserv.ini file during initialization. After initialization, the entries from this file are copied into the system registry. Modifying the timeserv.ini file will require an update of the system registry for Timeserv service to absorb the changes. This can be done by stopping the Timeserv service followed by running timeserv.exe -update and then restarting the service. Time synchronization by Timeserv posts status messages to the NT event log. The default timeserv.ini file is set up to dial the United States atomic clock via a modem attached to COM1. The Timeserv initialization file is an ASCII file that contains parameters for the configuration and startup of the Timeserv service. Listing 2 displays settings in a timeserv.ini file for a server that will act as the master timeserver using an NTP server as its time source. Lines preceded by "REM" display comments in the timeserv.ini file. Synchronization Utilities On most UNIX systems, the Berkeley rdate commands synchronize the client's clock with that of a reference system timesource:
brahe% rdate timesource
rdate can be inserted into the system cron file to automate the process. The rdate command sets the client machine's time to that of the timesource. The client machine's time will be inaccurate in the event that the timesource fails to set its time correctly. Thus, the rdate command may be suitable for the client system but is not recommended for use on timeservers themselves. NTP provides the ntpdate utility akin to the Berkeley rdate utility. The ntpdate utility adjusts the system clock in gradual steps. If the system clock is offset by more than half a second from the reference, then ntpdate synchronizes the system clock in gentle steps. The ntpdate utility can be used to update the timeserver just prior to running the timeserver software. The net time is a DOS command that can be used to synchronize the time against a reliable time source on the network. Computers running Windows NT, Windows 95, Windows for Workgroups, or DOS with Microsoft network client software can use this command. On Windows NT server/workstations, this command is ordinarily available only to systems and domain administrators. The net time command is akin to the Berkeley rdate command. The net time command can be written as part of an NT domain logon script for each user. This way, the user workstation/PC will synchronize its time with a more reliable time source on the network. Listing 3 provides a cook book approach to synchronizing client workstation in a Windows NT networked environment. The basic syntax of the command resulting from net help time is as follows.
NET TIME [\\computername | DOMAIN[:domainname]] [/SET]
NET TIME synchronizes the computer's clock with that of another computer or domain, or displays the time for a
\\computername Is the name of the computer you want to check or synchronize with.
Summary In today's networked environments, time synchronization is vital. NTP provides a powerful yet flexible method to synchronize time in a UNIX/NT environment. The Microsoft NT resource kit provides the Timeserv utility that can be installed to run as a service on Windows NT platforms. Although Timeserv implements only a subset of NTP, it is a very useful utility to synchronize Windows NT clients. The Timeserv service may obtain accurate time from another UNIX or NT server running NTP or another NT server running Timeserv in master or primary mode. Both UNIX and NT provide native commands that can be used to synchronize time on a client workstation against a more reliable time source. The tools and utilities described in this article allow an enterprise consisting of UNIX and NT servers and workstations to stay time synchronized. Resources U.S. Naval Observatory Time Service Department: http://tycho.usno.navy.mil/ NTP Home page: http://www.eecis.udel.edu/~ntp NIST Time and Frequency Division: http://www.bldrdoc.gov/timefreq NTP News group: nntp://comp.protocols.time.ntp Time Service for Windows NT 3.5 or Later: http://home1.gte.net/dougho/Timeserv.htm
NTP Version3 RFC: http://ds. \ NTP download site: ftp://ftp.udel.edu/pub/ntp
Time Sync alternative to Timeserv: NTP Timeserver for windows NT: http://www.coetanian.com Perl for Windows NT: http://www.ActiveState.com/software About the Author
Nalneesh Gaur has been working with computers since the late 1980s and has spent the greater part of the past five years working with UNIX. He currently works for Dynatech Integrated Systems Corporation as a systems engineer. His work involves UNIX/Windows NT systems integration, Web design, and security aspects of the Internet and intranets.
|