Seguridad general del protocolo de tiempo de red

5

Estoy investigando para comprender la seguridad del protocolo de tiempo de red. En particular, mi objetivo era / es comprender cómo se protege el protocolo y cuáles son los problemas.

Hasta ahora, entendí que hay básicamente 2 formas de proteger NTP, para proporcionar autenticación (y también integridad, ya que se usa un MAC): a través de la criptografía simétrica y la criptografía de clave pública. Sin embargo, por varias razones (que no enumero explícitamente por espacio), estas 2 mediciones a menudo no se usan y, por lo tanto, el NTP no se autentica. Esto conduce a una serie de problemas en términos de seguridad.

Mi pregunta es: en la práctica, ¿con qué frecuencia el NTP está realmente sujeto a ataques? Sé que existe la posibilidad de ataques tanto en ruta como fuera de ruta, y que algunos de ellos han sido corregidos (me refiero principalmente a estudios realizados por el grupo de investigación de la Universidad de Boston ). Si fuera tan fácil hackear un protocolo como NTP, todos estarían arruinando las aplicaciones a tiempo (certificados, etc.). Por lo que leí, en general, parece que, de hecho, no hay tantos ataques disponibles en NTP, aunque la mayoría de las veces el protocolo no está protegido. La única excepción parece ser los ataques DDoS (como los ataques de amplificación y reflexión), para los cuales no hay tantas soluciones. ¿Lo entendí bien o me estoy perdiendo algo importante del panorama general?

Otra pregunta: ¿por qué solo recientemente se han propuesto algunas soluciones nuevas? Me refiero principalmente a la especificación de seguridad de tiempo de red (pdf) para asegurar NTP, que también se presentó en Real World Cryptography Conference 2017 por uno de los autores del borrador de IETF (Daniel Franke). Lo que me he preguntado es si esta solución realmente proporcionaría algo útil, ya que las personas siguen usando NTP sin autenticación y no parecen preocuparse demasiado por ello.

Espero que mi pregunta haya sido clara.

    
pregunta Mark 04.04.2017 - 01:55
fuente

1 respuesta

1

Para la mayoría de las personas en la mayoría de las aplicaciones, la hora local altamente precisa es no de la esencia. Hay dos categorías amplias para las excepciones:

  • Las Autoridades de Certificación, los sistemas de no rechazo, los controles financieros y otros deben asegurarse de que el tiempo de un evento como el tiempo real se registre con precisión, asegurando integridad, pero no con tolerancias muy precisas (fuera de HFT )
  • Los sistemas de autenticación, los mecanismos de intercambio de claves y otras interacciones temporales que involucran la autenticación tienen que ver con la protección contra los ataques de repetición y utilizan el concepto de "ahora" para lograrlo, mientras que no están muy preocupados cuando el "ahora" realmente lo es, solo que no lo es. siendo reproducido desde "entonces".

Incluso dentro de estas categorías, a menos que haya consecuencias legales o de seguridad por falta de precisión o sincronización con el mundo exterior, existe una gran tolerancia de desviaciones / desacuerdos entre las partes (p. ej., la mayoría de la autenticación puede sobrevivir de segundos a minutos). ) o un simple requisito de que, si bien el tiempo no es completamente exacto contra el mundo exterior, al menos que todas las partes acuerdan su propia representación del tiempo (por ejemplo, todos los eventos de registro con 1,522 segundos de retraso aún se ordenan correctamente). p>

En su mayoría, los ataques requieren al menos el servidor, si no ambos extremos de la conexión tienen un tiempo comprometido, y una buena supervisión detectará este evento si el diseño no lo rechaza por completo.

Tengo entendido que para la mayoría de los usuarios finales, la denegación de servicio es la principal preocupación. Los grandes no confiarán en abrir NTP en Internet si son realmente serios .

    
respondido por el Liam Dennehy 25.07.2017 - 17:48
fuente

Lea otras preguntas en las etiquetas