United States
Easy management - our secret sauce. Watch the video tour.
WatchGuard Technologies, Inc.
WatchGuard Technologies, Inc.
Products  

Security Articles

Video Tutorials

WatchGuard Feeds

White Papers

Case Studies

Network Security Glossary

NTP: It's About Time

By David Piscitello, President, Core Competence

[Editor's note: This month, Dave became a Fellow on the staff of ICANN. He'll be working with the Security and Stability Advisory Committee to help make the Internet a safer environment for us all. WatchGuard is pleased to congratulate him, and especially delighted to report that even with Dave's new position, he will continue sharing his expertise with LiveSecurity readers. --Scott]

On your network, time synchronization is essential for correlating event data, auditing, and accounting. This article explains why accurate, universal time across your entire network benefits you, and tells how to standardize on accurate time.

Why wouldn't you want accurate timekeeping in your network? After all, the root of our obsession with measuring and standardizing time lies in networking. In the mid-nineteenth century, railroad operators began imposing a standard Railroad Time across all train stations in Britain to eliminate the confusion arising from train schedules based on local times in each city served. This evolved to what we now call Greenwich Mean Time (GMT). Postal, telegraph, and later, telephone networks adopted GMT in Great Britain, and the modern concept of establishing standard time spread quickly. International travel and communications evolved, and 24 time zones representing one-hour deviations from GMT were defined so that time across the world could be synchronized "relative to GMT."

Why is universal and accurate time important?

Internationally standardized, or universal time, is as important to the Internet as it was to all the networks that preceded it. Financial (e.g., ATM) and securities transactions, telephone usage accounting, video surveillance, synchronous optical network (SONET) framing, and virtually any application that records events or measures elapsed time would be impossible to trust if they relied solely on unqualified local time entered by a system administrator. Universal time is also critical for incident handling and log analysis. How can you make sense of security events you've logged and collected from many systems if they all use different clock settings?

Your network's universal time also needs to be accurate. Every computer has an internal clock and computes time locally, but quartz crystal computer clocks are not precise. Over time, and due to environmental and power source changes, computer clocks drift from the universal time. How much so? On average, between 15 and 120 seconds per day. Suppose, then, that you try to correlate security events recorded by two different systems. Without time synchronization, events that might have occurred nearly simultaneously may appear to have happened at vastly different times, leading you to conclude (perhaps falsely) that they were separate rather than related incidents.

Many authentication services, including digital certificates, time-tokens, and Kerberos rely on accurate, synchronized time. Consider Kerberos, an authentication system where a user is granted access for a limited time following successful authentication. When client systems and Kerberos authenticators don't agree on the time, users may be prevented from authenticating. Worse, the window of opportunity for brute force and replay attacks may be left open. Either problem defeats the whole purpose of deploying a short-lived authentication method.

Use NTP to maintain Universal Time

To establish universal time across all the computers and security systems in your network, use the Network Time Protocol (NTP). NTP is a client-server protocol that operates over UDP port 123. An NTP client requests universal time coordinates from one or more trusted time sources, or from local servers with access to an attached time source. A clock discipline algorithm in the NTP client approximates "the correct time" based on multiple sources. A message digest can be negotiated to authenticate and protect NTP packets from modification.

Time sources -- precision clocks -- are hierarchically organized into stratum levels. A Stratum 1 source is the root of any time service tree. Stratum 1 sources derive time directly from a Stratum 0 reference (atomic) clock, or from a coordinated universal time service like GPS, in which every satellite has two atomic clocks. Atomic clocks are incredibly accurate, and can provide a time measurement accuracy of one second in 1,400,000 years. Subordinate time sources are referred to as Stratum 2, Stratum 3, and so on. Even Stratum 3 servers maintain accurate time sufficient for many business purposes if communication with a Stratum 1 or 2 clock is impaired.

What time source should you trust?

Many public NTP Stratum 1 and 2 servers are available for open access. These are listed at NTP.servers Web. You can also purchase standalone atomic clock or GPS time source appliances, or turn a workstation or server into a timeserver by adding time source hardware, antennae, and software. Time source solutions are priced to fit budgets for small, medium and large enterprises.

Why run your own time source when public sources are available? Aren't public timeservers safe to use? Public NTP servers are safe and reliable, and sufficiently tamper-resistant for general business purposes. But organizations that require extreme accuracy must consider how Internet access availability, latency and jitter might affect time approximation on their systems. Extremely security-sensitive applications might also require advanced security measures to protect against tampering and "time poisoning" -- measures that public NTP servers might not provide. Finally, some organizations require an audit trail of time synchronization to comply with regulations (e.g. Sarbanes-Oxley) that can only be assured when they operate their own timeservers. Understand the security policy you must satisfy before you decide how to deploy NTP.

Enable NTP... everywhere!

Put NTP to good use in your network today! Commercial third-party and shareware time clients and servers are available for virtually every operating system (visit ntp.org for more information). All security systems should have a configurable NTP client.

Begin at your firewall. Assuming you use the WSM 8.0 Policy Manager and Fireware Pro, you can enable and configure NTP servers from Setup => NTP.... In WSM versions without Fireware Pro, look for Setup => Time Zone. If you have a Firebox X Edge running build 7.1.1 or later, enable and configure NTP from Logging => System Time. Note that if you enable WSEP logging, your Edge will synchronize time with the workstation you use to manage your firewall.

If you want to use an internal time source, run a Windows server as a Primary Domain Controller (PDC) that operates in the Flexible Single Master Operation (FSMO) role. This is the only type of domain controller that can query an external time source. Configure your PDC to use a public NTP server or an attached atomic/GPS clock rather than its internal clock. Configure your firewall to use the PDC as the time source. Next, configure your servers and clients to use NTP. The Windows Time Service (W32Time) on Windows 2000, XP, and 2003 server will derive time from your PDC, unless you configure them to use an external NTP server.

If you want your clients and servers to synchronize with public NTP servers, add a policy at your firewall enabling NTP outbound from your trusted network to external timeservers. Windows 2000, 2003, and XP have built-in NTP clients (the Windows Time service).

If you decide to use external NTP servers, choose servers from the lists at NTP.servers Web. Unless your applications require Stratum 1 accuracy, use secondary (Stratum 2) NTP servers. The NTP FAQ recommends that you configure between three and eight different servers and avoid common points of failure by choosing servers from different networks. Some NTP implementations allow you to adjust polling interval; before you tinker, read this FAQ.

Is time synchronization worth the time and effort?

Some of the oldest hacks in the book involve changing system time in order to generate false time stamps on logs and files. This is just one more reason why workstations should not set their own local time.

I began this article saying that time synchronization is a must for correlating event data, auditing, and accounting. I end on the same point. A small investment in configuring network time today may save you a great deal of time later. This is one of those good practices that you won't miss until you really need it. Can you really live without using NTP?

Time will tell.