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.

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.