 | Chapter 8 Configuring Internet Services |  |
| Chapter 8 Configuring Internet Services | |
NTP allows you to set the clocks on your systems very accurately, to within 100ms and sometimes even 10ms. 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 the clocks on those machines are all 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 he might do 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 simply ask servers for the current time without worrying about compensating for communications delays.
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:
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.
| Direc- | Source | Dest. | Pro- | Source | Dest. | ACK | |
|---|---|---|---|---|---|---|---|
| tion | Addr. | Addr. | tocol | Port | Port | Set | Notes |
In | Ext | Int | UDP | >1023 | 123 | [51] | Incoming query, client to server |
Out | Int | Ext | UDP | 123 | >1023 | [51] | Answer to incoming UDP query, server to client |
Out | Int | Ext | UDP | >1023 | 123 | [51] | Outgoing query, client to server |
In | Ext | Int | UDP | 123 | >1023 | [51] | Answer to outgoing UDP query, server to client |
In | Ext | Int | UDP | 123 | 123 | [51] | Query or response between two servers |
Out | Int | Ext | UDP | 123 | 123 | [51] | Query or response between two servers |
[51] UDP packets do not have ACK bits.
Figure 8.19 shows how packet filtering works with NTP.
As a UDP-based application, NTP can't be proxied by SOCKS, but can be used with the UDP Packet Relayer. Because NTP employs a hierarchy of servers, it can be configured to run on a bastion host without using explicit proxying, as shown below.
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.
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.
|  | |
| 8.12 Network Management Services |  | 8.14 Network File System (NFS) |