Cómo probar si el servidor NTP está seguro o no

Cómo probar si el servidor NTP está seguro o no

Estamos probando algunas de las configuraciones de NTP en el archivo ntp.conf y queremos estar seguros de si el servidor NTP está seguro o no.

Siguiendo la recomendación proporcionada aquí: https://support.ntp.org/Support/AccessRestrictions#Section_6.5.1.2.1.

agregamos :

IPV4: restrict -4 default limited kod nomodify notrap nopeer noquery

IPv6: restrict -6 default limited kod nomodify notrap nopeer noquery

Ahora la pregunta es: según la línea escrita en la documentación:

Dado que está dispuesto a permitir que otros obtengan la hora de su ntpd, ¿les permitirá ver la información del estado de su servidor (aunque esto pueda revelar información sobre su sistema operativo y la versión de ntpd)?

¿Cómo podemos estar seguros de si el servidor envía su estado o alguna otra información del sistema operativo o no?

Además, ¿cuál es la diferencia si no agregamos la opción 'noquery' en la restricción y cómo podemos probar con y sin la opción 'noquery', es decir, si agregar dicha opción tiene algún reflejo o no? (Queremos probar desde el punto de vista de la seguridad)

¿Podemos usar Wireshark para recuperar el estado o la información del sistema operativo para probar nuestras opciones de configuración?

Respuesta1

La implementación ntpd de referencia expone muchas de sus variables de implementación a través de los programas.ntpq(yntpdcalgo que sólo su autor aprecia). Estos utilizan un protocolo de control en paquetes NTP especiales. Es posible que el canal de control pueda cambiar la configuración de ntpd, aunque esto rara vez se usa en la era moderna, donde se puede automatizar la implementación de archivos de configuración en cualquier número de hosts.

Los riesgos de mantener ntpd son principalmenteprevenir la amplificación de IP a direcciones falsificadasy proteger su configuración de sincronización horaria contra cambios de direcciones IP no autorizadas en las redes.

Como siempre, mantener los parches mitiga algunos defectos. Un ataque de amplificación a través de la función "monlist" resultó enCVE-2013-5211. Esto debería haber sido una actualización hace años, pero verifique quetodode sus hosts están en una distribución compatible y reciben atención de un mantenedor.

Toda la atención prestada a monlist dio como resultado algunas herramientas para buscarlo fácilmente. Por ejemplo,script nmap ntp-monlist.

La lista completa de funciones es lacomandos documentados para ntpq. Esas líneas en la opción "elija su propia configuración" de la wiki difieren en noquery, lo que niega por completo todas las consultas ntpq. Mantener en funcionamiento el servicio de tiempo. Por ejemplo, ese script nmap no devolvería nada. En contraste, nomodfyhay una regla de acceso que controla solo los comandos que cambian la configuración. Claramente nomodifydebería estar fuertemente restringido, posiblemente solo a localhost.

Compare con configuraciones de ejemplo en otros lugares, como el paquete de su disto favorito.ntp.conf de RHEL 7sugiere esto como punto de partida para el control de acceso:

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default nomodify notrap nopeer noquery
    
# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
    
restrict 127.0.0.1 
restrict ::1
    
# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
    
# Disable the monitoring facility to prevent amplification attacks using ntpdc  
# monlist command when default restrict does not include the noquery flag. See
# CVE-2013-5211 for more details.
# Note: Monitoring will not be disabled with the limited restriction flag.
disable monitor

Tenga en cuenta la mitigación de monlist aunque ntpd ya esté parcheado. Además, el valor predeterminado para hosts remotos no se puede consultar ni modificar. Con ligeras modificaciones, esto podría hacer que un host NTP esté listo para servir a la Internet pública.

Naturalmente, una vez que sepa qué ntp.conf desea, impleméntelo. Automatice la configuración de servidores NTP, obtenga una configuración razonable en las imágenes de plantilla de todos los hosts.

Toda esta discusión sobre monlist no cubre su pregunta original sobre la identificación de plataforma y sistema operativo a través de ntp. Según los documentos ntpq, esa información de compilación puede aparecer en las variables del sistema a través del readvarcomando de control. Como en, a un servidor remoto: ntpq -c readvar time.example.net. Aunque hay algunos detalles de implementación para decodificar aquí, como qué ID de asociación es el host NTP en cuestión.

Personalmente, no me preocupa mucho exponer información de compilación sobre ntpd. Alguien se entera de que mi ntpd está actualizado y que parte de la máquina de estado no puede hacer mucho con eso. Un atacante rociaría paquetes NTP falsificados en todos los hosts que pudiera, con la esperanza de amplificarlos.

información relacionada