UCF STIG Viewer Logo
Changes are coming to https://stigviewer.com. Take our survey to help us understand your usage and how we can better serve you in the future.
Take Survey

The IAO will ensure all NTP-enabled devices authenticate received NTP messages.


Overview

Finding ID Version Rule ID IA Controls Severity
V-14671 NET0813 SV-15327r4_rule ECSC-1 Medium
Description
Since NTP is used to ensure accurate log file timestamp information, NTP could pose a security risk if a malicious user were able to falsify NTP information. To launch an attack on the NTP infrastructure, a hacker could inject time that would be accepted by NTP clients by spoofing the IP address of a valid NTP server. To mitigate this risk, the time messages must be authenticated by the client before accepting them as a time source. Two NTP-enabled devices can communicate in either client-server mode or peer-to-peer mode (aka “symmetric mode”). The peering mode is configured manually on the device and indicated in the outgoing NTP packets. The fundamental difference is the synchronization behavior: an NTP server can synchronize to a peer with better stratum, whereas it will never synchronize to its client regardless of the client’s stratum. From a protocol perspective, NTP clients are no different from the NTP servers. The NTP client can synchronize to multiple NTP servers, select the best server and synchronize with it, or synchronize to the averaged value returned by the servers. A hierarchical model can be used to improve scalability. With this implementation, an NTP client can also become an NTP server providing time to downstream clients at a higher stratum level and of decreasing accuracy than that of its upstream server. To increase availability, NTP peering can be used between NTP servers. In the event the device looses connectivity to it upstream NTP server, it will be able to choose time from one of its peers. The NTP authentication model is opposite of the typical client-server authentication model. NTP authentication enables an NTP client or peer to authenticate time received from their servers and peers. It’s not used to authenticate NTP clients because NTP servers don’t care about the authenticity of their clients, as they never accept any time from them.
STIG Date
WLAN Bridge Security Technical Implementation Guide 2011-10-10

Details

Check Text ( C-12793r3_chk )
Review the device (router, switch, firewall, IDS, etc) that is querying an NTP server or peer for time. Verify that the device is authenticating the NTP messages received from the NTP server or peer. Authentication must be performed using either PKI (supported in NTP v4) or SHA-1 hashing algorithm. If SHA-1 is not supported by both the NTP client or server, then MD5 can be used.
Fix Text (F-14132r3_fix)
Configure the device to authenticate all received NTP messages using either PKI (supported in NTP v4) or SHA-1 hashing algorithm. If SHA-1 is not supported by this client or the NTP peer or server, then MD5 can be used.