El Protocolo de Tiempo de Red (NTP) mantiene en silencio sincronizados los relojes de internet, y durante casi toda su vida nadie lo consideró peligroso. Entonces los atacantes descubrieron su comando MONLIST — una función de diagnóstico que devuelve las últimas 600 direcciones que consultaron un servidor NTP. Una diminuta petición de 234 bytes puede disparar hasta 48 KB de respuesta: una ratio de amplificación de 556x. Dirige esa respuesta a una víctima falsificando su dirección, multiplícalo por miles de servidores NTP abiertos, y un atacante modesto genera una inundación aplastante.
El patrón del ataque
- El atacante envía peticiones MONLIST a miles de servidores NTP mal configurados, falsificando la IP de la víctima como origen.
- Cada servidor envía diligentemente su gran respuesta a la víctima, que nunca la pidió.
- La inundación es difícil de filtrar porque parece tráfico legítimo de servidores NTP.
- No es teórico: Cloudflare mitigó un ataque de amplificación NTP de ~400 Gbps en 2014.
La solución para los operadores de servidores NTP
Si ejecutas un servidor NTP, eres parte de la solución. Actualiza a NTP 4.2.7p26 o posterior, que desactiva MONLIST por defecto. Si no puedes actualizar, añade 'noquery' a las líneas restrict de tu ntp.conf. Y si no ejecutas un servidor NTP a propósito, corta por firewall el UDP/123 de la internet pública por completo — un servidor NTP abierto no intencionado es un arma apuntando a desconocidos.
La amplificación es un problema de responsabilidad compartida
Cada servidor NTP, DNS o Memcached mal configurado en internet es munición para un ataque contra otra persona. Blindar tus propios servicios no es solo autoprotección — reduce el arsenal disponible para los atacantes a nivel global.
Dónde encaja un proxy inverso — y dónde no
Sé preciso con el alcance. La amplificación NTP es una inundación de paquetes UDP de capa de red, así que la inundación en sí debe detenerse aguas arriba — en la red de tu hosting o proveedor de tránsito, idealmente con validación de dirección de origen BCP38. Un proxy inverso como Akarguard no limpia UDP y no lo afirma. Lo que aporta es privacidad del origen: como tu tráfico web se resuelve al edge de Akarguard, la IP real de tu servidor permanece oculta, así que una inundación amplificada no tiene objetivo directo y tu origen nunca tiene que procesarla. Para los paquetes volumétricos brutos, lo que importa es la capacidad de tu proveedor de red, no el proxy.