Network Time Protocol (NTP) (Building Internet Firewalls)

Network Time Protocol (NTP)

NTP allows you to set the clocks on your systems very accurately, to within 1 to 50 ms of the time on a central server. Knowing the exact time is extremely important for certain types of applications and protocols:

It's much easier to correlate information from multiple machines (log files, for example, when analyzing a break-in attempt) when all the clocks on those machines are synchronized. It's helpful to know exactly who was attacked, and in what order, if you're going to understand what the attacker was after -- and what might be coming next.
Some security protocols depend on an accurate source of time information in order to prevent "playback" attacks. Such protocols tag their communications with the current time, so that those same communications (e.g., a login/password interaction or even an entire communication) can't be replayed at a later date as part of an attack. This tagging can be circumvented if the clock can be set back to the time the communication was recorded.

NTP servers communicate with other NTP servers in a hierarchy to distribute clock information. The closer a system is to a reference clock (an atomic clock, radio clock, or some other definitive clock), the higher it is in the hierarchy. Servers communicate with each other frequently to estimate and track network delay between themselves, so that this delay can be compensated for. NTP clients can track network delay the same way servers do or can simply ask servers for the current date and time without worrying about compensating for communication delays.

NTP is provided with several vendors' versions of Unix; a few vendors (notably Silicon Graphics) include services based on the older Time protocol instead of or in addition to NTP. NTP is not provided with Windows but is supported by timeserv, which is part of the Server Resource Kit.

's easy for an attacker to forge packets with incorrect time settings. It's possible to use authentication starting in NTPv3, and you should do so.

Packet Filtering Characteristics of NTP

NTP is a UDP-based service. NTP servers use well-known port 123 to talk to each other and to NTP clients. NTP clients use random ports above 1023. As with DNS, you can tell the difference between the following:

An NTP client-to-server query
Source port above 1023, destination port 123
An NTP server-to-client response
Source port 123, destination port above 1023
An NTP server-to-server query or response
Source and destination ports both 123

Unlike DNS, NTP never uses TCP, and NTP has no analog to the DNS zone transfer operation.

NTP servers may also talk to each other using broadcast or multicast; the multicast address 224.0.1.1 is reserved for this purpose.

Direction	SourceAddr.	Dest.Addr.	Protocol	SourcePort	Dest.Port	Notes
In	Ext	Int	UDP	>1023	123	Query, external client to internal server
Out	Int	Ext	UDP	123	>1023	Response, internal server to external client
Out	Int	Ext	UDP	>1023	123	Query, internal client to external server
In	Ext	Int	UDP	123	>1023	Response, external server to internal client
In	Ext	Int	UDP	123	123	Query or response between two servers
Out	Int	Ext	UDP	123	123	Query or response between two servers
In	Ext	224.0.1.1	UDP	123	123	ulticast query or response from an external server
Out	Int	224.0.1.1	UDP	123	123	ulticast query or response from an internal server

Figure 22-1 shows how packet filtering works with NTP.

Figure 22-1

Figure 22-1. NTP with packet filtering

Proxying Characteristics of NTP

As a UDP-based application, NTP can't be proxied by SOCKS4 but can be used with the UDP Packet Relayer or SOCKS5. Because NTP employs a hierarchy of servers, it can be configured to run on a bastion host without using explicit proxying, as shown later in this chapter.

Network Address Translation Characteristics of NTP

NTP does not use embedded IP addresses and will work transparently with network address translation.

Configuring NTP to Work with a Firewall

Do you really need to configure NTP to work with a firewall? That's your first decision. You may not need to if either of the following cases is true at your site:

If you have an accurate source of time within your internal network -- for example, a radio clock receiving time signals from the National Bureau of Standards atomic clocks on one of their radio stations (or the equivalent from non-U.S. standards organizations), or a satellite clock receiving data from the Global Positioning System (GPS) satellites.
If you're more worried about having time be consistent within your network than between your network and the outside world.

In either of these cases, you don't need to run NTP across your firewall; you can simply run it internally.

If you do want to run NTP across your firewall, the best way is to set up an NTP server on a bastion host that talks to multiple external NTP servers and another NTP server on some internal host that talks to the bastion host. (You want the bastion host to talk to multiple external NTP servers because it increases accuracy and makes it harder to fool.) Next, configure internal NTP clients and other internal NTP servers to talk to the internal server that talks to the bastion server. You need to configure any packet filtering system between the internal server and the bastion host to allow the following:

Queries from the internal NTP server to the bastion host NTP server
UDP packets from port 123 on the internal server to port 123 on the bastion host
Answers from the bastion host NTP server to the internal NTP server
UDP packets from port 123 on the bastion host to port 123 on the internal host

Summary of Recommendations for NTP

Consider running NTP purely internally.
If you run NTP to the Internet, use an NTP server on a bastion host as a proxy for an internal server.

Previous	Up	Next
ICMP and Network Diagnostics	Index	File Synchronization