En esta página
Puntos clave
- Separar sincronización y controlEl intercambio horario cliente/servidor y las consultas administrativas cumplen funciones distintas.
- Comprobar la implementación realEl comportamiento histórico de monlist no describe todos los servidores NTP actuales.
- Comprobar la sincronización tras filtrarQue una aplicación responda no demuestra que sus fuentes de tiempo sigan funcionando.
La reflexión utiliza un origen falsificado
Un reflector NTP responde a la dirección de origen de una solicitud. Si está falsificada, un destino ajeno al servicio horario puede recibir las respuestas. Hay amplificación cuando la respuesta supera a la solicitud inicial; el patrón exacto depende de implementación, consulta y configuración.
El abuso histórico de monlist afectaba a un comportamiento antiguo de ntpd. No debe presentarse como una función activa en todos los despliegues NTP actuales. Identifique la implementación y la versión mantenida: las configuraciones de ntpd, NTPsec y chronyd no son intercambiables.
Recorrido de la reflexión NTP
- Solicitud falsificada
El origen apunta a la víctima.
- Servidor horario expuesto
Una consulta permitida produce una respuesta.
- Entrada de la víctima
Las respuestas consumen capacidad de enlace y procesamiento de paquetes.
Sincronización y consultas de control son operaciones diferentes
En el intercambio cliente/servidor habitual, el modo NTP 3 es una solicitud del cliente y el modo 4 una respuesta del servidor. El modo 6 corresponde al control; el modo 7 es una categoría privada propia de la implementación, asociada a herramientas antiguas. No clasifique todos los paquetes desde UDP 123 como la misma operación.
Una máquina que no sirve la hora públicamente puede necesitar respuestas entrantes de sus fuentes configuradas. Filtrar todos los paquetes UDP/123 puede romper la sincronización mientras parece resolver un pico de tráfico. Identifique los pares esperados y el patrón normal antes de elegir excepciones.
Analizar el incidente incluyendo la dirección
Localizar el cuello de botella
Compare contadores del proveedor, túnel y servidor con pérdidas y fallos del servicio. Una captura posterior no mide paquetes ya descartados antes. Separe la presión sobre el ancho de banda de la carga de procesamiento de paquetes.
Examinar el contexto del paquete
Registre puertos de origen y destino, modo NTP cuando pueda decodificarse, función del destino y tamaños. Las respuestas suelen salir del puerto de origen 123; mirar solo el puerto de destino 123 puede omitir respuestas dirigidas a otro puerto local del cliente.
Comprobar qué solicitó realmente el servidor
Contraste los pares horarios autorizados y la actividad reciente del cliente. La ausencia de solicitudes en observaciones muestreadas o unidireccionales no prueba una reflexión. La ruta puede ser asimétrica y los registros de flujo no tienen por qué incluir el modo NTP.
Medir las operaciones legítimas
Compruebe transacciones de la aplicación y estado de sincronización del servicio horario. Supervise desfase y accesibilidad de las fuentes durante un intervalo adecuado; el reloj del sistema puede no mostrar un error inmediato al dejar de recibir respuestas.
Restringir el control sin desactivar el servicio horario
Use una versión mantenida del servicio horario y limite las consultas administrativas a los responsables previstos. Servir la hora públicamente y permitir control remoto público son requisitos distintos. Aplique las reglas del programa utilizado y revise su exposición IPv4 e IPv6.
En los controles de acceso documentados de ntpd 4.2.8, noquery rechaza consultas ntpq/ntpdc sin denegar el servicio horario. nomodify por sí solo permite consultas de lectura. Estas explicaciones describen las opciones; no son una configuración completa para copiar en otra implementación.
Revise la lista de acceso efectiva y pruebe desde un equipo de administración autorizado y un cliente horario normal. Preserve pares necesarios, comportamiento de pools y supervisión. Programe reinicios o recargas según su procedimiento; debilitar la autenticación o desactivar toda supervisión no es una alternativa adecuada.
Filtrar antes del recurso agotado de la víctima
Si la reflexión llena la entrega del cliente, filtrar detrás no recupera capacidad. Coordine con la red ascendente un patrón verificado y acotado al destino. Si queda ancho de banda y la presión es local, una regla local adecuada todavía puede proteger el servidor.
Conserve las respuestas horarias esperadas y el tráfico UDP ajeno al ataque. Una regla por puerto de origen no inspecciona cada fragmento ni demuestra que una respuesta sea no solicitada. Confirme criterios de coincidencia, excepciones, comportamiento del límite de tasa y retirada de reglas en el receptor.
Si desvía tráfico hacia una ruta protegida, valide el enrutamiento y la entrega limpia además de la regla. Añadir encapsulación no aporta capacidad de recepción. Asigne un responsable tanto a la política temporal como al retorno al enrutamiento normal.
Ejemplo: un servidor de juegos que también usa NTP
Un servidor de juegos puede no ofrecer un servicio horario público mientras su sistema se sincroniza con pares remotos. Ante una posible reflexión, bloquear todo UDP/123 puede eliminar juntas las respuestas indeseadas y las necesarias. Es un fallo ilustrativo, no un incidente medido de un cliente.
La prueba de aceptación debe cubrir conexiones de jugadores, tráfico normal por la ruta protegida y accesibilidad de las fuentes de tiempo. Registre par seleccionado, sincronización y desfase tras filtrar y tras retirar la regla de emergencia. Un ping correcto no valida por sí solo ni la aplicación ni el reloj.
Errores que ocultan una recuperación incompleta
- Presentar la amplificación histórica monlist como el comportamiento de todos los servicios horarios actuales.
- Confundir puertos de origen y destino o asumir que toda respuesta llega al puerto local 123.
- Aplicar la sintaxis de otro programa sin verificar versión y modelo de acceso.
- Declarar la recuperación porque baja la gráfica aunque la sincronización continúe rota.
- Conservar una regla amplia de emergencia tras el ataque sin volver a probar el tráfico legítimo.
Preguntas y respuestas
¿Puede la reflexión alcanzar un servidor que no ofrece NTP?
Sí. Las respuestas pueden dirigirse a su dirección falsificada. Ese servidor puede necesitar, aun así, respuestas NTP legítimas como cliente.
¿noquery desactiva la sincronización del reloj?
En los controles de ntpd 4.2.8 citados restringe consultas administrativas, no el servicio horario. Otras reglas e implementaciones requieren comprobación independiente.
¿Qué demuestra que la mitigación funciona?
Menos carga indeseada, transacciones legítimas recuperadas, pérdidas aceptables y fuentes de tiempo operativas en la ruta de entrega real. Ningún contador de puerto aislado demuestra todo ello.
