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 NT but is supported by timeserv, which is part of the Server Resource Kit.
By default, NTP does not include any authentication; as a result, it'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.
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 | Multicast query or response from an external server |
Out | Int | 224.0.1.1 | UDP | 123 | 123 | Multicast query or response from an internal server |
Figure 22.1 shows how packet filtering works with 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.
NTP does not use embedded IP addresses and will work transparently with network address translation.
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