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. > > _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
