Ciberataques DrDoS basados en el protocolo NTP

Una vez analizados los ciberataques de denegación de servicio (DoS) junto con algunas de sus variantes en el artículo “DrDoS: características y funcionamiento”, en este nuevo artículo, se va a abordar cómo el protocolo NTP es utilizado como una herramienta para desarrollar un ciberataque DoS en su variante DrDoS.

NTP

El Protocolo para Sincronización Horaria (NTP, Network Time Protocol), es un protocolo que permite la sincronización temporal de los distintos dispositivos interconectados en el ámbito de configuración de este servicio. Trabaja con UDP por el puerto 123 y es ampliamente utilizado en redes a escala mundial, tanto internas como públicas. Su importancia radica en que la falta de sincronización horaria, por un tiempo prolongado en un sistema, afecta a la consistencia e integridad de la información, lo que conlleva graves repercusiones en ámbitos como es el financiero, productivo, legal y un largo etcétera.

- Figura 1. Esquema de funcionamiento de NTP. -

Un ejemplo, son los sistemas de bases de datos en donde una sincronización horaria incorrecta en la consolidación de registros ocasionaría errores en la aceptación y validación de transacciones o daría lugar a resultados incorrectos, desactualizados o simplemente errores en el motor de búsqueda al hacer consultas.

Los sistemas de firma electrónica también son otro claro ejemplo, ya que estos incluyen un dato temporal en los documentos y registros electrónicos, y de comprobarse que ese dato de fecha y hora es incorrecto, la firma aplicada quedaría invalidada directamente.

Vector de ataque

El protocolo NTP presenta vulnerabilidades relacionadas con ciertos comandos utilizados para la gestión y supervisión del propio protocolo, y para poder configurar y evaluar el estado de un servidor NTP. Entre estos comandos se encuentran:

• El comando “monlist” (MON_GETLIST), que al ejecutarlo, devuelve una lista con los últimos 600 dispositivos que se hayan comunicado con el servidor más recientemente. De esta forma, una petición que se lanza contra el servidor NTP con un tamaño ínfimo, alrededor de 250 bytes, provoca una respuesta que puede alcanzar un tamaño 200 veces superior.
• El comando “readvar”, que al ejecutarlo, devuelve las variables utilizadas por el demonio del servicio NTP junto con sus valores. En este caso, la respuesta del servidor consta de más de un paquete, dado que este comando devuelve una iteración sobre el rango de asociaciones de las variables utilizadas, y su tamaño puede llegar a ser 30 veces superior al de origen.

Ante lo expuesto, un operador malintencionado puede realizar peticiones GET_MONLIST o “readvar” a un servidor NTP, falsificando la dirección IP origen real de la petición, con la dirección IP del equipo que se quiere inutilizar, reflejando así el ciberataque. El resultado, es que el equipo víctima, sin haberlo solicitado, recibe las respuestas NTP con una amplificación de 30 o 200 veces, según el tipo de consulta. A esto se suma, que si estas peticiones se realizan desde una botnet, el equipo víctima sufriría una extenuación de sus recursos, por lo que la inundación de respuestas NTP que le llegan, afectará a la disponibilidad de los servicios que requieran conectividad ofrecidos por él.

- Figura 2. Esquema de ataque DrDoS NTP. -

Estas vulnerabilidades conocidas, afectan a los servidores NTP que monten una versión anterior a 4.2.7p26 y mantengan la configuración por defecto resultante de la instalación predeterminada, ya que las versiones específicas para la plataforma de Microsoft Windows estuvieron disponibles a partir de la versión 4.3.8p8.

Prevención

En primer lugar, para comprobar si la función monlist está activada, podemos utilizar el siguiente comando desde un dispositivo Linux:

ntpdc -n -c monlist [IP del servidor NTP]

Si la salida del comando es una lista de dispositivos, monlist estará activado y por tanto, el servidor será vulnerable.

Por otro lado, respecto a la función “readvar”, se puede verificar si el servidor está afectado, analizando la salida de la ejecución del siguiente comando:

ntpq -c rv [IP del servidor NTP]

Si se obtiene un error por tiempo de conexión agotado, el servidor está protegido correctamente. En caso contrario, es vulnerable.

Aunque un servidor propio NTP sea vulnerable, es posible evitar que sea utilizado para participar en un ciberataque DrDoS. Para ello, se recomiendan las siguientes medidas:

• Actualización de la versión del demonio de NTP. En versiones posteriores a la 4.2.7p26 liberadas, el comando “monlist” está deshabilitado. Se puede comprobar la versión del demonio NTP en servicio utilizando el comando “ntpdc” con el argumento “--version”. O recurrir a un programa de escaneado de sistemas como puede ser el conocido programa “nmap”, utilizando los modificadores que incorpora la herramienta. En el caso de “nmap” podría ejecutarse el comando ntpd siguiente:

sudo nmap -sU -pU:123 -Pn -n --script=ntp-monlist <server-IP>

• Deshabilitar la función “monlist” o “readvar”. Es una alternativa en el caso de que no fuera posible la medida anterior y que conlleva evaluar el impacto que pueda tener la necesidad de supervisar los dispositivos conectados al servidor NTP.
  • Para deshabilitar la función “monlist” se ha de modificar el archivo “/etc/ntp.conf” para añadir la línea “disable monitor” y luego reiniciar el servicio.
  • Para deshabilitar la función “readvar”, se ha de editar el archivo de texto “/etc/ntp.conf” para introducir las siguientes líneas:

restrict default ignore
disable bclient

Si la supervisión es imprescindible, se puede optar por limitar el origen de las peticiones a segmentos de red concretos. De esta forma, se reduciría el nivel de exposición del servidor NTP y el riesgo de explotación por parte de un atacante externo. Para ello, se editará el archivo de configuración “/etc/ntp.conf” añadiendo las líneas siguientes, según las restricciones a aplicar:

restrict default noquery #para restringirlo completamente
restrict localhost #para restringirlo solo al propio servidor
restrict (red a monitorizar) netmask (mascara de red) #para restringirlo a una red específica
restrict (Dirección IP) #para restringirlo a una ip específica

• Desplegar los servidores NTP detrás de cortafuegos. El firewall debe configurarse con reglas que detecten y filtren peticiones dirigidas por UDP al puerto del servidor NTP y que disponga de una configuración antispoofing de IP.
• Limitar la visibilidad del servidor NTP en Internet. Para que el servidor no sea «público», mediante el filtrado de direcciones IP. Esta medida puede ser establecida a través de reglas de filtrado en el cortafuegos.
• Solicitar al proveedor de servicios de Internet (ISP) filtros antispoofing. Estos proveedores pueden rechazar tráfico NTP con direcciones falsificadas, no accesibles a través de la ruta real del paquete. Esto evitará que el servidor NTP propio reciba y atienda peticiones que sean susceptibles de ser un DrDoS.
• Definir un protocolo de actuación para incidentes de DrDoS por NTP. Para reducir el impacto que pueda ocasionar la pérdida de la sincronización horaria en el sistema, se deben disponer de pautas concretas sobre cómo identificar estos ataques y cómo actuar si se producen. La improvisación en las acciones que se emprendan para atajar estos incidentes puede acarrear problemas y fallos en otros componentes.

Detección y evidencias

Para detectar si un servidor NTP propio está siendo partícipe en un ataque de denegación de servicio reflejado, es necesario prestar atención al rendimiento de los servidores de sincronización horaria en cuanto a sobrecarga de proceso y uso intensivo de sus recursos. También hay que fijarse en que haya tráfico UDP inusual e intenso en el puerto 123.

Asimismo, también conviene que se habiliten en el servidor NTP la recolección de estadísticas para su consulta y análisis en este tipo de situaciones, que se recogen en el archivo “/var/log/ntpstats”.

Respuestas y recomendaciones

Si se confirman los indicios y se considera que se está produciendo un ataque de denegación de servicio sobre los servidores NTP propios, hay que actuar rápido y aplicar el protocolo de actuación y gestión de incidentes que se haya definido previamente:

• Habilitar un servicio NTP alternativo. En caso de que el servidor NTP quede fuera de servicio y ello afecte a otros componentes del sistema, es recomendable sustituir temporalmente la configuración habitual por una alternativa que puede ser un pool global de servidores NTP. Haciendo esto se evitará que otros servicios que dependen del servidor propio de NTP fallen o se produzcan problemas de inconsistencia temporal de los datos. En ntppool.org se puede encontrar varios servidores globales que pueden ser utilizados como fuente horaria alternativa.

w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

En caso de tratarse de un sistema Linux, se añadirán los siguientes parámetros en el archivo de texto alojado en la siguiente ruta "/var/lib/ntp/ntp.drift".

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

• Recopilar la mayor cantidad de datos posible sobre el incidente. Se tendrá que realizar una investigación para identificar direcciones IP de origen y destino, puertos y posibles direcciones URL.
• Bloquear y filtrar tráfico no deseado. Los datos recopilados anteriormente podrán ser utilizados para configurar reglas de filtrado en cortafuegos y enrutadores y así, impedir que lleguen peticiones al servidor NTP propio. También es conveniente contactar con el proveedor de Internet y de hosting para que puedan aplicar en su ámbito filtros que bloqueen la inundación de tráfico no autorizado.
• Obtener asistencia técnica. Bien con los proveedores de servicios técnicos de TI que tuvieran contratados o a través de los centros de respuesta a incidentes de seguridad (CERT) de carácter público de referencia, como es INCIBE-CERT.

Una vez que el ataque haya cesado, hay que verificar que el servicio se haya restablecido con normalidad y la configuración horaria sea la habitual. También, se deben analizar las causas que lo han provocado y, como ante cualquier otro delito tecnológico, comunicar a las autoridades el suceso.