NTP server(s)

Jeffrey Blank blank at eclipse.ncsc.mil
Thu Oct 25 19:46:06 UTC 2012


Yes, yes.
But I'm trying to determine whether we're asserting that there should be
a compliance check (which would fail) in the STIG profile for systems
running RHEL in a variety of network roles (which may quite reasonably
only have one time server).  I am not keen on failing a majority of
systems, in order to hold them to best practice for a specific use case.

It's certainly true that a system acting as an NTP server should have
multiple time sources.  And we can have an NTP server profile which
insists on precisely that.




On 10/25/2012 03:06 PM, Gary Gapinski wrote:
> On 10/25/2012 02:28 PM, Jeffrey Blank wrote:
>> We will certainly have rules available to that end.
>>
>> The question is whether you want it encoded as part a compliance
>> enforcement regime for a wide variety of use cases.  Previous consensus
>> discussion indicated that a single NTP server in an enclave was common
>> practice, but that that system (acting as an NTP server) commonly used
>> multiple sources for time.
>>
>> What would you want to enforce on all systems, as that is our constraint?
>>
> 
> Anyone who wishes to _ensure_ time synchronization will use three or
> more NTP servers. This is normally a requirement levied for logging and
> audit purposes, but interesting things can happen to, e.g., license
> servers and clients thereof when clocks drift. Kerberos and AD are also
> sensitive to clock drift, as are software authenticators, etc. A
> one-second negative clock slew will cause an RSA Authentication Manager
> RADIUS service to decide life is no longer worth living (ask me how I
> know).
> 
> Anyone who needs not ensure time synchronization can use less than
> three, with an increased expectation of interesting failure modes.
> 
> When one server is used, the local system will track it for better or
> worse, until it becomes unavailable, at which point the local clock skew
> takes over until the server becomes available again, at which point a
> fast slew will occur.
> 
> With a quorum, there is far more assurance of accuracy as well as
> avoidance of fast slews.
> 
> Multiple lower stratum NTP servers are cheap as chips to provide, even
> in "enclaves". Most commercial network gear can provide NTP.
> 
>


More information about the scap-security-guide mailing list