Las implementaciones NTP completas solo permiten un sesgo limitado. Por ejemplo, la implementación de estándar de facto (anteriormente ISC) en Linux no se desviará del reloj local en más de 1/2000 de forma predeterminada (un poco menos de un minuto por día). Por lo tanto, un atacante no puede causar una gran desviación de reloj con tal implementación. En una configuración de servidor o sitio típica, un atacante que puede hacer que el reloj se desvíe también puede hacer cosas mucho más preocupantes, incluyendo DoS significativos.
Si necesita más precisión, obtenga un reloj que no dependa de Internet. Puede obtener señales horarias de muchos transmisores de radio , desde GPS , etc. Los receptores comienzan alrededor de $ 10 aproximadamente. Un reloj atómico te hace más independiente, pero es, por ejemplo, mucho más caro.
Las implementaciones NTP en dispositivos integrados (incluidos muchos dispositivos de red) a menudo son más tontas. Muchos de ellos restablecerán la fecha una vez al día más o menos sin realizar ninguna verificación de coherencia (especialmente aquellos sin un reloj interno, que deben obtener una fecha en el momento del arranque). Por lo tanto, si es posible, asegúrese de configurar todos estos dispositivos para obtener el tiempo de un servidor confiable en su red interna , no a través de Internet.
Si necesita seguridad adicional, NTP admite controles de integridad y autenticidad a tiempo señales Estos son suficientes para protegerse contra un atacante que solo inyecta paquetes de respuesta NTP falsos. Si el atacante puede retrasar paquetes legítimos en tránsito, autenticar los paquetes no es suficiente. Su única opción en ese caso es rechazar las respuestas si toman demasiado tiempo (el umbral depende de cuánta desviación es permisible).