Filter
Top Products
S100 User Guide – Rev. D – June 2005 97
2
5
3
multicasting is likely to be nearly as accurate as using a nonbroadcast server. Multicasting is
preferable to broadcasting because it makes identifying NTP traffic easier and does not affect
non-NTP clients on the network. Broadcasting or multicasting is a good fit in some
environments, however, it is not appropriate for all environments. In particular, architectural or
security concerns may preclude the use of broadcasting or multicasting. Multicast NTP
transactions open the network to denial of service attacks.
For security conscious environments, monitoring should be turned off because it could allow
an attacker to obtain sensitive information about hosts or networks. In most other
environments, disabling monitoring is an unnecessary restriction and only makes it more
difficult to solve NTP problems. Requiring authorization keys for queries is another option.
Limiting access to NTP queries prevents intruders from probing for information using the ntpq
command. While the information obtained from ntpq may seem trivial, an intruder could
discover sensitive information, including network delays (which could lead to determining
network architecture), hostnames, IP addresses, and OS versions. In addition to
authenticated transactions, NTP also provides the capability to restrict access to its services.
This function is provided using the restrict keyword. This keyword is defined in the ntp.conf
file and has the following syntax.
The address and mask are both representations of the IP address and network subnet mask
to be restricted. The flags indicate what function is to be controlled. For example, if all
communication from IP address 192.xxx.x.x is to be ignored, the following access restriction
can be used. The restrict command is often used with the default keyword, which limits the
specified access from all IP addresses.
restrict address [ mask numeric_mask ] [ flag ] [ ... ]
restrict 192.xxx.x.x ignore
restrict default ignore
Any restrict statements that do not contain a keyword will enable (rather than restrict) access.
Additional keywords such as noquery are also useful. Noquery restricts who can query the
run time configuration of the time server. While having the ability to query the server would
appear to be harmless, the query function can be useful in mapping network time
architectures and locating potential security weaknesses. For example, with the ntpsweep
command (supplied from the open-source NTP software distribution), it is possible to
determine the operating system and processor type of NTP peers. This function can be
restricted using the noquery option, otherwise queries are allowed. The version information
seen by outsiders could be modified to mask the OS version, but few administrators take the
time to obscure this information. This allows system intruders to easily obtain information
about the operating system platforms and versions. Security is only as strong as the weakest
link. For NTP, this means not only its access control and authentication but also the platform
security of its servers and clients. If a platform cannot be sufficiently protected, it is possible
that the NTP configuration and authentication key files can be stolen or compromised.
A reference clock is needed to synchronize an NTP network to a useful standard. Clients
cannot sync to a potential NTP server unless a reference clock exists in the server’s
synchronization path. There are three different ways to set up an NTP server for a large
number of clients:
• Set up a reference clock on a secured network that uses accurate public NTP servers
• Set up a reference clock directly on a secured network