Most people take for granted the fact that individual computers have an internal clock that seems to keep time pretty reliably. I have seen people even set their watch by the time displayed on their “taskbar.” What they may not be thinking about is that the built-in clock on a computer often keeps time in a similar fashion to their battery-powered watch, and the system time can often drift by up to a second a day. While that may not seem like much to the average user, it can become a real headache for a network administrator attempting to maintain an architecture relying on multiple systems spread out across the enterprise. The difficulty becomes apparent only months down the road when application services begin to fail due to the inability of certain tasks to run on schedule or the inability of two servers to agree on what time a transaction should take place.

What does this have to do with security? The effect of poor time synchronization on security can be characterized in two major ways: (1) the ability for network security services to function and (2) the ability of administrators to investigate security-related networking issues. The former can directly impact users because it most often affects their ability to log in and access network services. For example, if you use a time-sensitive token-based authentication (a popular one is RSA SecurID) each user has a physical or software token that provides a mechanism to generate a different password on a regular interval known by the server (we will use one minute for this example). Since this token operates independently of the network as a whole, an offset of over 60 seconds between the server attempting to authenticate a user and the server providing the authentication service will invalidate what the user thinks is the current password. This is a simplified example, but you can see how this can be a problem for networked applications expecting transactions to occur within a certain timeframe. Depending on the servers’ clock skew (the rate of change of the clock’s offset from ‘absolute’ or accepted time), the problem can quickly escalate to affect network services with larger tolerances for time synchronization.

The second effect I mentioned above relates to logging. When security events (such as logins) occur and resources are accessed across the network, logs are generated by all systems and applications involved. Investigating security issues can become nearly impossible when these logs cannot be properly correlated. Looking for log entries from a certain timeframe may not yield results if the system time is off by a gross amount of time. This can be especially frustrating if collecting forensic evidence to show malicious activity. Malicious individuals can exploit weak time synchronization by altering system time in an attempt to hide activity in the past (or the future if they have a twisted sense of humor). For this reason, all servers should employ some form of time synchronization with either absolute time (from an external source) or with an internal network time server. One way to do this is with Network Time Protocol, which is easily implemented using most widely-used operating systems. While I will not go into the actual configuration of an NTP server for a particular operating system, I will point out a few configuration options that will be important to the security-minded administrator.

The first thing to point out is that NTP is not an inherently secure protocol. It is a very well-known protocol, and uses a static source and destination UDP port (123). It is susceptible to replay attacks, spoofed server replies, and denial of service attacks. One way to combat spoofed server replies is to maintain a ‘mesh’ NTP architecture in which all hosts synchronize to each other using broadcast NTP traffic. This prevents one from changing the system time globally across the network by altering one server. This is still subject to denial of service conditions, however, where all hosts are flooded with NTP traffic and therefore unable to maintain synchronized clocks. To combat some of these vulnerabilities, the most recent major version of the protocol standard, NTPv4, includes provisions for the implementation of asymmetric cryptography to encrypt NTP data transmissions. This is only a draft protocol, however, and NTPv3 is the latest formalized, documented version (see RFC 1305). Assuming you are not using the encryption features of NTPv4, there are still some other configurable options to consider.

The simplest way to configure NTP on your network is to use an architecture in which all hosts talk to a central NTP server which maintains the reference time for the rest of the network. If you have services that require synchronization with outside entities, you will want to configure your NTP server to synchronize its own clock to a trusted source. This can be a public time server on the Internet, such as ntp.org or nist.gov, or you can use one of the commercially available solutions that use radio signals, satellite systems, dedicated precision clocks, or if you spend enough money, your very own internal atomic clock. In these situations it is important to note that free external time sources have no obligation to provide your network with the proper time 24/7/365, so you will want to ensure that the server is configured to fall back to using its own clock if these become available. Most NTP implementations include configuration options for restricting access to the system clock through the NTP protocol. This should be configured on all hosts, including your network’s NTP server itself, to allow only the specified servers to adjust system clocks. Also consider the time-sensitivity of applications and services running on your network when configuring a time synchronization interval. Consider the fact that security-related logs should be accurate to within seconds, but some less-critical systems may need to go offline on a regular basis. Administrators should choose an interval that allows them to readily notice if a problem exists related to system time without flooding the logs with time synchronization errors.

I hope this provides a clear understanding of how your network timekeeping practices can impact security and your ability to troubleshoot your network. If you have questions about how to make NTP work better for you, feel free to contact our support line.