22.5. 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 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.
22.5.1. 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. NTP with packet filtering
22.5.2. 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.
22.5.3. Network Address Translation Characteristics of NTP
NTP does not use embedded IP addresses and will work transparently
with network address translation.
22.5.4. 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
22.5.5. 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.
| | |
22.4. ICMP and Network Diagnostics | | 22.6. File Synchronization |