Un ataque de amplificación NTP es una técnica DDoS basada en reflexión que abusa del comando monlist del Network Time Protocol —una característica de diagnóstico de implementaciones más antiguas de servidor NTP— combinada con IP spoofing para enviar pequeñas consultas falsificadas a servidores NTP, que responden con conjuntos de datos desproporcionadamente grandes enviados directamente a una víctima falsificada, produciendo factores de amplificación históricamente tan altos como ~556x.
Resumen rápido — La amplificación NTP explota el comando
monlisten versiones del daemon NTP anteriores a 4.2.7, que devuelve una lista de hasta los últimos 600 clientes que consultaron al servidor. Un request falsificado de 8 bytes puede disparar una respuesta de hasta aproximadamente 4,460 bytes por paquete NTP, dividida a través de múltiples paquetes de respuesta que juntos alcanzan factores de amplificación de alrededor de 200x-556x. La ola de 2014 de ataques de amplificación NTP, que alcanzó 400+ Gbps contra algunos objetivos, fue una de las mayores campañas DDoS de su era. La mitigación es directa: deshabilitamonlist(por defecto desde ntp-4.2.7p26), restringe el acceso de consulta conrestrict noquery, y aplica BCP38 upstream para prevenir el spoofing en el origen.
Última actualización: 2026-08-08
La amplificación NTP surgió a prominencia a principios de 2014, cuando una ola de ataques usando la técnica produjo algunos de los mayores ataques DDoS volumétricos registrados hasta ese punto, incluyendo un ataque ampliamente reportado que excedió 400 Gbps contra un cliente de CDN, y numerosos ataques en el rango de 100-300 Gbps contra objetivos de gaming, hosting, y financieros. US-CERT emitió la Alerta TA14-013A en enero de 2014 abordando específicamente la amplificación NTP, y el incidente impulsó un parcheo rápido y coordinado de servidores NTP expuestos a través de internet. A pesar de esa respuesta, la amplificación NTP sigue siendo relevante hoy porque persiste una población significativa de servidores NTP sin parchar o sin reforzar, y la infraestructura NTP abierta y mal configurada sigue siendo periódicamente re-escaneada y usada como arma por los atacantes.
Cómo funciona la amplificación NTP
NTP (Network Time Protocol) corre sobre el puerto UDP 123 y se usa para sincronizar relojes a través de sistemas en red. El comando monlist, formalmente el request MON_GETLIST en el modo 7 (privado/control) de NTP, era una característica de diagnóstico que le pedía a un servidor NTP devolver una lista de los últimos clientes que se habían comunicado con él, pensada para ayudar a los administradores a depurar y monitorear el uso del servidor.
Paso 1: El atacante envía un request monlist pequeño y falsificado a un servidor NTP abiertoAtacante → Servidor NTP: request MON_GETLIST (~8 bytes, IP origen = IP de la víctima)
Paso 2: El servidor NTP busca en su historial de clientes reciente y respondeServidor NTP → Víctima: respuesta(s) MON_GETLIST [Cada paquete de respuesta lista hasta 6 registros de cliente, ~468 bytes por paquete; un servidor activo puede necesitar múltiples paquetes para devolver hasta 600 registros]
Paso 3: El atacante repite esto vía muchos servidores NTP abiertos simultáneamente1,000 servidores × tasa de consulta sostenida × ~4,460 bytes de respuesta agregada por consulta = gran inundación volumétrica convergiendo en la víctima
Ancho de banda propio usado por el atacante: 1,000 × 8 bytes por consulta (insignificante)Amplificación: bytes de respuesta / bytes de consulta ≈ 200x–556x dependiendo del tamaño del historial del servidor y la fragmentación de la respuestaEl factor de amplificación es inusualmente alto por dos razones: la propia consulta es extremadamente pequeña (un request desnudo de 8 bytes sin payload más allá del comando), y un servidor NTP ocupado puede acumular hasta 600 registros de cliente en su buffer de monitoreo, lo que significa que una sola consulta puede disparar decenas de paquetes de respuesta UDP de tamaño máximo en secuencia, no solo uno.
Por qué UDP y el diseño sin conexión habilitan el ataque
Como DNS, SSDP, y CLDAP, NTP corre sobre UDP, que no requiere ningún handshake para establecer una sesión antes de intercambiar datos. El servidor procesa y responde a cualquier dirección IP de origen que el request afirme, sin ningún paso de verificación. Combinado con el IP spoofing, esto significa que el servidor NTP nunca aprende que está siendo usado como reflector; desde su perspectiva, está respondiendo a una consulta de diagnóstico legítima de lo que parece un cliente normal.
Comparación de factores de amplificación
| Protocolo | Tamaño de consulta | Respuesta máxima típica | Factor de amplificación |
|---|---|---|---|
| NTP (monlist) | ~8 bytes | Hasta ~4,460 bytes (multi-paquete) | ~200x–556x |
| DNS (ANY/EDNS0) | ~60 bytes | ~4,000 bytes | ~28x–70x |
| CLDAP | ~52 bytes | ~1,068 bytes | ~56x–70x |
| SSDP | ~110 bytes | ~750 bytes | ~7x–30x |
| Memcached | ~15 bytes | Hasta ~134 MB | Hasta ~50,000x |
El factor de amplificación basado en monlist de NTP está entre los más altos de los vectores de reflexión “clásicos”, segundo históricamente solo a Memcached, que se descubrió y abusó más tarde, en 2018. La combinación de NTP de una consulta trivialmente pequeña y una respuesta grande y multi-paquete lo hizo especialmente atractivo para los atacantes que construían campañas volumétricas a gran escala de forma económica.
La ola de amplificación NTP de 2014
Los reportes públicos de incidentes de principios de 2014 documentaron un pico agudo en los ataques de amplificación NTP, impulsado en gran parte por la amplia disponibilidad de herramientas de escaneo y listas que catalogaban servidores NTP con monlist todavía habilitado. Los ataques en este periodo alcanzaron volúmenes pico que excedían los 400 Gbps contra algunos objetivos —entre los mayores volúmenes DDoS documentados públicamente hasta ese momento— e impulsaron una respuesta rápida y coordinada de la comunidad: los operadores del pool NTP, los proveedores de hosting, y las distribuciones de SO publicaron parches y guías de configuración para deshabilitar monlist por defecto. La versión del daemon NTP 4.2.7p26, publicada en respuesta, deshabilitó monlist por defecto de ahí en adelante, y este valor por defecto ha persistido en versiones posteriores.
Señales de detección
| Señal | Qué observar | Herramienta |
|---|---|---|
| Tráfico UDP/123 entrante sin consulta NTP saliente coincidente | Paquetes NTP del tamaño de una respuesta llegando sin que la víctima haya enviado un request de sincronización de tiempo correspondiente | NetFlow/IPFIX, sFlow |
| Alto volumen de paquetes UDP de ~468 bytes desde el puerto de origen 123 | Tamaño de paquete consistente con fragmentos de respuesta monlist | Captura de paquetes, tcpdump -n udp port 123 |
| Diversidad de IP de origen a través de muchos servidores NTP distintos | Tráfico de ataque convergiendo desde numerosas IP de servidor NTP no relacionadas simultáneamente | Análisis de flujo |
| Saturación de ancho de banda repentina con UDP/123 como protocolo dominante | Pico de utilización de uplink o interfaz atribuible abrumadoramente al tráfico del puerto 123 | SNMP/RMON, contadores de interfaz |
# Inspecciona tráfico NTP modo 7 (estilo monlist) en la redtcpdump -n 'udp port 123' -v
# Verifica si tu propio servidor NTP responde a una consulta estilo monlist (desde un host de prueba autorizado)ntpdc -c monlist <ip-del-servidor-ntp>
# Correlaciona NetFlow para respuestas UDP/123 sin consultas salientes coincidentesnfdump -r flows.nf 'proto udp and src port 123' -o extendedSi ntpdc -c monlist contra tu propio servidor devuelve una lista de clientes, el servidor está expuesto y debería reforzarse de inmediato (ver abajo). Ejecutar este comando contra un servidor que no controlas o administras, puramente para probar la exposición, solo debería hacerse con autorización explícita, ya que incluso una consulta de diagnóstico contribuye de forma trivial al volumen de request de un objetivo y las consideraciones legales varían por jurisdicción.
Técnicas de mitigación
Deshabilitar monlist en servidores NTP
La corrección individual más directa. Las versiones del daemon NTP 4.2.7p26 y posteriores deshabilitan monlist por defecto; los administradores que corran versiones más antiguas deberían actualizar o deshabilitar explícitamente la interfaz privada/control del modo 7:
# En ntp.conf, deshabilita explícitamente el monitoreo y las consultas de modo 7:disable monitor
# Restricción alternativa / complementaria:restrict default noquery nomodify notrap nopeerrestrict -6 default noquery nomodify notrap nopeerRestringir el acceso de consulta con restrict noquery
Incluso donde monlist en sí está deshabilitado, restringir quién puede emitir cualquier request de control/consulta NTP (a diferencia de los requests legítimos de sincronización de tiempo) reduce la exposición del servidor como reflector para cualquier vulnerabilidad futura de comando de diagnóstico:
restrict default kod nomodify notrap nopeer noqueryrestrict 127.0.0.1restrict ::1Migrar a implementaciones modernas de sincronización de tiempo
Las implementaciones modernas como chrony no implementan en absoluto la interfaz legada de modo 7 monlist, eliminando por completo la superficie vulnerable en lugar de requerir que se deshabilite explícitamente. Muchas distribuciones actuales de Linux usan chrony por defecto sobre el ntpd clásico por esta y otras razones.
BCP38 / Filtrado de ingreso (RFC 2827)
Como la amplificación NTP depende por completo del IP spoofing, el filtrado de ingreso BCP38 (RFC 2827) en la red del atacante evitaría que la consulta falsificada llegara jamás al reflector NTP. Como con todos los ataques de reflexión, esta defensa debe aplicarse upstream por las redes que originan el tráfico; una organización víctima no puede aplicarla directamente.
Rate limiting y correlación de respuesta
Los operadores de red pueden limitar la tasa del tráfico UDP/123 entrante y correlacionar las respuestas NTP entrantes contra consultas salientes previamente enviadas, descartando respuestas no solicitadas sin bloquear por completo la sincronización de tiempo legítima.
Scrubbing upstream y absorción distribuida
Como los floods NTP amplificados pueden exceder la propia capacidad de uplink de un objetivo por órdenes de magnitud, la absorción típicamente necesita ocurrir upstream, en un proveedor de scrubbing o red distribuida con suficiente capacidad agregada. Consulta Blackhole Routing vs. Scrubbing para una comparación de enfoques.
Errores comunes
| Error | Impacto | Solución correcta |
|---|---|---|
| Asumir que monlist está deshabilitado por defecto en todos los servidores NTP desplegados | Muchas implementaciones NTP de larga duración, sin parchar, o embebidas (routers, dispositivos IoT, appliances) todavía vienen con monlist habilitado o versiones de ntpd obsoletas | Audita y prueba explícitamente la exposición con ntpdc -c monlist contra tu propia infraestructura; no asumas el estado de parcheo |
| Bloquear todo el UDP/123 entrante como respuesta a incidentes | Bloquea la sincronización de tiempo legítima para los propios sistemas de la organización, lo que puede causar fallos de validación de certificados, deriva de timestamp de log, y problemas de autenticación Kerberos | Usa correlación de respuesta y rate limiting en lugar de un bloqueo general de protocolo |
| Tratar el refuerzo de NTP como una tarea de una sola vez | Continuamente se agregan dispositivos, appliances, y sistemas legados a las redes, algunos vienen con configuraciones NTP vulnerables por defecto | Incluye la revisión de configuración NTP en las auditorías de infraestructura rutinarias y las listas de verificación de onboarding de activos |
| Depender solo del firewall del lado de la víctima para detener las inundaciones amplificadas | El tráfico NTP amplificado puede exceder la propia capacidad de uplink de la víctima antes de que cualquier dispositivo on-premise tenga la oportunidad de filtrarlo | Combina el refuerzo del lado del servidor (evitar que tus propios servidores sean reflectores) con capacidad de absorción upstream para el tráfico dirigido a ti |
| Ignorar dispositivos embebidos/IoT que corren daemons NTP empaquetados | Los routers de consumidor y dispositivos IoT a veces empaquetan implementaciones NTP obsoletas con monlist habilitado, contribuyendo al pool de reflectores de internet | Asegura que el firmware de dispositivos embebidos esté actualizado y audita las configuraciones NTP por defecto expuestas al internet público |
Cómo implementarlo con Azion
La red distribuida de Azion puede ayudar a absorber y filtrar el tráfico de amplificación NTP antes de que llegue a un origen, mientras que el refuerzo del lado del servidor contra ser usado como reflector sigue siendo responsabilidad de quien opere el propio servicio NTP:
- DDoS Protection brinda detección y mitigación siempre activa para tráfico UDP volumétrico, incluyendo floods NTP amplificados, absorbiéndolo a través de la infraestructura distribuida de Azion en lugar de en tu origen.
- Network Shield puede aplicar reglas a nivel de red para identificar y filtrar patrones de tráfico UDP/123 anómalos consistentes con reflexión NTP, dependiendo de la configuración.
- Firewall permite reglas personalizadas para rate limiting y filtrado basado en protocolo a nivel de red.
- WAAP combina protecciones de red y de capa de aplicación para organizaciones que enfrentan campañas multi-vector que combinan amplificación volumétrica con abuso a nivel de aplicación.
Si tu propia infraestructura corre un servicio NTP, reforzarlo contra el abuso de monlist (deshabilitando la interfaz legada de modo 7, aplicando restrict noquery, o migrando a chrony) es una tarea de configuración independiente de cualquier proveedor de edge o protección DDoS, ya que aborda si tu servidor puede ser usado como arma contra otros en lugar de si tus aplicaciones están protegidas de ataques entrantes.
Recursos relacionados
- ¿Qué es un ataque DDoS?
- Tipos de ataques DDoS
- ¿Qué es un ataque reflejado de ICMP/UDP?
- ¿Qué es la amplificación DNS?
- Azion DDoS Protection
Preguntas frecuentes
¿Qué es un ataque de amplificación NTP? Un ataque de amplificación NTP envía una pequeña consulta falsificada —típicamente el comando monlist— a un servidor NTP abierto, que responde con un conjunto de datos mucho más grande enviado directamente a la dirección de la víctima falsificada en lugar de al atacante. Esto le permite a un atacante generar tráfico volumétrico contra una víctima que excede por mucho su propio ancho de banda.
¿Qué es el comando monlist? Monlist, formalmente el request MON_GETLIST en el protocolo privado/control de modo 7 de NTP, es una característica de diagnóstico que le pide a un servidor NTP devolver una lista de hasta los últimos 600 clientes que se comunicaron con él. Fue pensado para monitoreo legítimo del servidor pero se convirtió en el vector principal para la amplificación NTP porque su respuesta es desproporcionadamente grande comparada con el request.
¿Cuál es el factor de amplificación máximo para la amplificación NTP? Los factores de amplificación documentados públicamente para los ataques monlist de NTP van desde aproximadamente 200x hasta cerca de 556x, dependiendo de cuántos registros de cliente había acumulado un servidor dado y cómo se fragmentó la respuesta a través de múltiples paquetes UDP. Esto hace a NTP uno de los vectores de reflexión clásicos con mayor amplificación, detrás solo de Memcached.
¿La amplificación NTP sigue siendo una amenaza en 2026? La amenaza está reducida pero no eliminada. Las versiones del daemon NTP desde 4.2.7p26 (publicadas en respuesta a la ola de 2014) deshabilitan monlist por defecto, y las implementaciones modernas como chrony no implementan en absoluto la interfaz vulnerable. Sin embargo, los sistemas legados sin parchar, los dispositivos embebidos, y los appliances mal configurados continúan exponiendo servidores NTP con monlist habilitado que los escaneos periódicos a nivel de internet siguen encontrando y catalogando.
¿Cómo verifico si mi servidor NTP es vulnerable al abuso de monlist? Ejecuta ntpdc -c monlist <ip-de-tu-servidor> desde un host de prueba autorizado contra tu propio servidor. Si devuelve una lista de clientes recientes, el servidor está expuesto y debería reforzarse de inmediato deshabilitando el modo de monitoreo, aplicando restrict noquery, actualizando a una versión parchada de ntpd, o migrando a chrony.
¿Un firewall puede detener un ataque de amplificación NTP contra mí? Un firewall puede filtrar o limitar la tasa del tráfico UDP/123 entrante una vez que llega, y puede correlacionar respuestas contra consultas salientes previamente enviadas para descartar las no solicitadas. No puede prevenir que se genere el ataque; eso requiere que los servidores NTP siendo abusados como reflectores se refuercen, lo cual está fuera del control de la víctima a menos que la víctima también opere infraestructura NTP.
¿Cómo se diferencia la amplificación NTP de la amplificación DNS? Ambas son ataques de reflexión basados en UDP que dependen del IP spoofing, pero la amplificación NTP explota específicamente el comando de diagnóstico legado monlist, que históricamente producía un factor de amplificación más alto (hasta ~556x) que la amplificación DNS típica (~28x-70x). La amplificación DNS abusa de resolvers abiertos respondiendo a consultas DNS estándar, mientras que la amplificación NTP abusa de una característica de diagnóstico específica y ahora en gran medida deshabilitada.
¿Deshabilitar monlist elimina todo el riesgo de DDoS basado en NTP? Deshabilitar monlist elimina el vector de amplificación NTP principal y más severo, pero los administradores todavía deberían aplicar restrict noquery ampliamente y mantener el software NTP actualizado, ya que otros requests de modo control NTP o vulnerabilidades futuras en la implementación del protocolo podrían teóricamente abusarse de forma similar si la interfaz de diagnóstico/control permanece abierta a orígenes arbitrarios.
¿Qué rol juega el IP spoofing en la amplificación NTP? El IP spoofing es el mecanismo que redirige la respuesta del servidor NTP a la víctima en lugar de al atacante. Sin spoofing, la respuesta monlist amplificada regresaría a quien realmente envió la consulta —el atacante— sin brindar ningún beneficio contra un tercero.
¿Los ataques de amplificación NTP se pueden mitigar sin la adopción de BCP38 por cada red? Sí, parcialmente. El refuerzo del lado del servidor (deshabilitar monlist, restringir el acceso de consulta) elimina servidores individuales del pool de reflectores usables sin importar si la red del atacante filtra el tráfico falsificado. El scrubbing upstream y la capacidad de absorción distribuida pueden manejar las inundaciones volumétricas que sí ocurran. BCP38 sigue siendo la única corrección que previene el spoofing en sí en el origen, pero no es la única capa de defensa disponible.
Fuentes:
- US-CERT. “Alert TA14-013A: NTP Amplification Attacks Using CVE-2013-5211.” Enero de 2014.
- IETF. “Network Time Protocol Version 4: Protocol and Algorithms Specification.” RFC 5905. 2010.
- IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38). 2000.
- NTP.org. “NTP Security Notice: Vulnerabilities in ntpd prior to 4.2.7p26 (monlist).” 2014.
- CISA. “UDP-Based Amplification Attacks.”
- NIST SP 800-94. “Guide to Intrusion Detection and Prevention Systems (IDPS).”