With projects like DShield, I have spend a lot of times around logs. One of the challenges in collecting logs from multiple sources is correlation and with that, correlating time. In addition to logs, some authentication systems like Kerberos will not work unless participating systems are synchronized to the same clock.

Luckily, ntp provides for a rather simple and quite accurate way to keep time on networked systems. NTP Version 3, which is the version you will find currently implemented, is defined in RFC 1305 [1]. Even though ntp isn't terribly complicated, there is a simpler version called SNTP (simple NTP). SNTP is defined in RFC 2030 [2].

Synchronizing time starts out with a primary reference source. This is a "standard clock" we use as a reference. If all you need is internal synchronization, you may just define some clock as your standard clock. But more likely then not, you are interested in synchronizing your clocks with the outside world. Various government standard organizations operate such standard clocks, and synchronize them with each other. The time to which all these national clocks are synchronized is referred to as UTC ("Universal Coordinated Time"). Occasionally, UTC is adjusted by adding leap seconds in order to match the rotation of the earth which is not exactly regular.

Now back from time to ntp. We established that we start with a master clock. All of our clocks are synchronized with this "master clock" using ntp. In order to do so, we need an ntp server connected to the master clock, and a ntp client on our system to connect to the master clock's ntp server. Usually, you end with an internal ntp server (or a couple of them for redundancy)  that is synchronized to an external source. All your internal hosts will then synchronize to your own internal standard.

Now what about the NTP protocol? How does it work? NTP deviates a bit from the standard port use. Most clients will pick an ephemeral port (>1023) and connect to the server's fixed port. For NTP however, the connection will usually be from UDP port 123 to UDP port 123 (but can be from high port to udp/123 ).

The client will connect to one or more servers, receive the time from each server. Next, the client will calculate a "drift" indicating what adjustment needs to be made to the internal clock to keep it in sync. One of the nice features of ntp is that adjustments are applied gradually, and large "jumps in time" are avoided. The ntp protocol definition explains in a lot of details various algorithms that should be used to pick the "best time" from a set of time servers.

NTP expresses time as 64bit numbers. The first 32 bits are the number of seconds from January 1st 1900. The remaining 32 bits express the fraction of seconds. 32 bits = 4 billion seconds or about 136 years. On Februrary 7th 2036, at 6:28:16 (if my math is right), ntp will "overflow". Lets hope we will have a 128 bit version of ntp implemented by then.

How is NTP secured? By default not at all. Some of its security comes from its distributed nature and by using multiple time servers. Encryption and authentication is optional with NTP. Most of the time, access to ntp servers is just controlled by IP address. But a shared secret may be used as a password and to help authenticating the response. The most recent version of ntp does allow for PKI support. For more about ntp security, see the GIAC Gold paper by Matt Willman [5]

Couple words on finding an appropriate time server: For a reasonably large network, it may be appropriate to get your own dedicated time server. There are some reasonably inexpensive products that will synchronize with non-network external clocks like GPS (usually requires an external antenna), cell phone networks (works well if you have cell phone reception in your datacenter. Does not require a monthly subscription to a cell phone service) or the governments time radio signal.

If you are concerned with too many clients connecting to your ntp server: ntp has an option to broadcast or multicast ntp data. That way, you can easily serve an entire network with time information without having to support individual connections. Multicast ntp uses the IP address 224.0.1.1.

Other time servers: Many ISP's routers have pretty good time servers build in. Check the router your network is connected to. Windows systems usually have "time.microsoft.com" pre-set, OS X systems use "time.apple.com" by default. Linux addapted pool.ntp.org over the last few years. pool.ntp.org is a set free reachable time servers [3]. Or you may refer to a list of public time server [4].

[1] http://tools.ietf.org/html/rfc1305
[2] http://tools.ietf.org/html/rfc2030
[3] http://www.pool.ntp.org/en/
[4] http://support.ntp.org/bin/view/Servers/WebHome
[5] http://www.giac.org/certified_professionals/practicals/gsec/2115.php

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter