Cyber Security Awareness Month - Day 28 - ntp (123/udp)

Published: 2009-10-28
Last Updated: 2009-10-28 13:51:38 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

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

6 comment(s)

Comments

Note that SNTP is used by windows to synchronize time within a domain (mainly to prevent clock skew so that kerberos works properly). Thus a windows domain controller will act as a SNTP server, but it in turn may be synchronized against some other external source of some sort.

Some NTP clients will refuse to synchronise to SNTP servers. If you have a Windoze network, it's worthwhile installing a real NTP server. I use and recommend the Meinberg utility.
Standard Unix, Linux, and Mac OS X NTP "clients" are also NTP servers. NTP queries to these clients can reveal a lot of information. Proper configuration of ntp.conf can prevent this information disclosure.

The default Mac OS X ntp.conf can yield very poor timekeeping under some conditions, particularly for laptops and other systems with intermittent connections to NTP servers. Unfortunately, Apple software updates often overwrite ntp.conf, so configuration changes must be refreshed.

The reference NTP client/server implementation has a very good security track record, and has been under development by the same core group for decades.

One correction: NTP version 4 is widely implemented through the reference implementation, but not yet documented in an RFC. Version 3 and 4 clients and servers interoperate fairly seamlessly, except for the extensions in version 4.

SNTP will not maintain time as accurately as a full NTP implementation, but SNTP is good enough for most client systems.

For more than you ever wanted to know about NTP, see www.ntp.org
How is the 32-bit issue mentioned in your description (2036-02-07:06:28:16) related to the well known 2038 issue (the date for overflow there
is different)?
NTP has a different epoch date than unix, and uses unsigned 32 bit seconds rather than signed 32 bit seconds (so they don't relate at all).
(1) Why in the world did the NTP protocol designers choose _1900_ as the epoch date? The protocol isn't going to be used to synchronize clocks before 1970!

(2) An easy way to address the Date of Doom is to add one more byte to the NTP protocol, "year offset from epoch date". That defers the Date of Doom by 255 years.

Diary Archives