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

S100 User Guide – Rev. D – June 2005

97

Page 105
Image 105
Symmetricom manual S100 User Guide Rev. D June