Fecha de publicación: Julio 7, 2014
Fecha de modificación: Julio 7, 2014
Gravedad: ALTA
Última revisión: Revisión A.
Fuente: CSIRT Panamá
I. Descripción
Un ataque de amplificación o reflexión de servidor de nombres de dominio (DNS) es una forma popular de negación de servicio distribuida (DDoS), en que los atacantes utilizan los servidores DNS abiertos públicamente accesibles para inundar a la víctima con tráfico de respuesta de DNS.
La técnica principal consiste en que el atacante envía una petición de resolución de nombre a un servidor DNS abierto con una dirección de origen falsa, correspondiente a la dirección de la víctima. Cuando el servidor DNS envía la respuesta, ésta es enviada a la víctima, en vez de al solicitante (el atacante). Esto se conoce como reflexión DNS. El atacante normalmente enviará la mayor solicitud de información de zona posible, para maximizar el efecto.
La forma más común de este ataque implica a servidores DNS mal configurados para permitir la resolución recursiva sin restricciones para cualquier cliente en Internet (open resolver). También pueden implicar a servidores de nombres autoritarios que no proporcionan resolución recursiva, el método de ataque es similar al de resolver recursivos abiertos, pero es más difícil mitigar ya que incluso un servidor configurado con las mejores prácticas puede ser utilizado igualmente en un ataque. En el caso de servidores, autoritativos, la mitigación debe centrarse en el uso de limitación de velocidad de respuesta para restringir la cantidad de tráfico.
II. Impacto
Vector de acceso: A través de red.
Complejidad de Acceso: Media.
Autenticación: No requerida para explotarla.
Tipo de impacto: El servidor mal configurado que permite la resolución recursiva sin restricción para cualquier cliente (Open Resolver) puede ser explotado para participar en un ataque de negación distribuido (DDoS).
III. Detección
Existen múltiples herramientas públicas y gratuitas en la web para verificar los DNS de una red en busca de servidores DNS con resolución de nombres recursiva vulnerable. Estas herramientas realizan un barrido de toda la red y listan la dirección de cualquier servidor identificado.
http://www.dnsinspect.com
http://dns.measurement-factory.com/surveys/openresolvers.html
También se puede realizar la verificación de forma manual con la instrucción dig de la siguiente forma:
$ dig +short test.openresolver.com TXT @<servidor_dns>
Si no posee la instrucción dig, puede utilizar nslookup de la siguiente forma.
$nslookup
>server <servidor_dns>
>set type=TXT
>test.openresolver.com
III. Mitigación
Las configuraciones básicas en este documento se detallan únicamente para BIND9 y Microsoft DNS Server, ya que son los más utilizados. En caso de tener un servidor DNS diferente, deberá consultar la documentación de su vendedor para mayor información sobre las configuraciones.
Debido al volumen de tráfico masivo que puede ser producido por uno de estos ataques, a menudo es poco lo que la víctima puede hacer para detener un ataque de negación de servicio distribuido basado en amplificación DNS. Sin embargo, es posible reducir el número de servidores que pueden utilizarse por los atacantes para generar el volumen de tráfico, evitando que sus servidores sean intermediarios en este tipo de ataques.
– Verificación de IP de origen
Debido a la forma en que se ejecuta el ataque de amplificación por DNS, el primer paso en reducir la efectividad de este ataque está en que los proveedores de servicio rechacen cualquier tráfico DNS con direcciones falsas (IP Spoofing). El Network Working Group de la Internet Engineering Task Force lanzó BCP38 (Best Current Practice – Mejores Prácticas Actuales) y BCP84, documentos que describen cómo un proveedor de servicios de Internet puede filtrar el tráfico en su red para rechazar los paquetes con direcciones de origen no accesibles a través de la ruta del paquete actual. La implementación de las recomendaciones de este documento haría que un dispositivo de enrutamiento evalúe si es posible llegar a la dirección de origen del paquete mediante la interfaz que transmite el paquete. Si esto no es posible, se considera que el paquete tiene un a dirección de origen falsificada.
– Deshabilitar la recursión en DNS autoritativos.
Muchos de los servidores DNS actualmente desplegados en Internet proporcionan exclusivamente la resolución de nombres para un solo dominio. En estos sistemas, la resolución DNS para sistemas clientes privados puede ser proporcionada por otro servidor separado y el servidor autoritativo actúa únicamente como fuente de información de la zona DNS para clientes externos. Estos sistemas no necesitan apoyar una resolución recursiva de otros dominios en nombre de un cliente, por lo cual la resolución debe ser desactivada en la configuración.
Bind9
En las opciones globles, añadir lo siguiente:
Options{
allow-query-cache { none; };
recursion no;
};
Microsoft DNS Server
En la consola de Microsoft DNS Server
Click derecho en el servidor DNS e ir a Propiedades.
Ir a la pestaña de avanzado
En opciones de servidor, seleccionar “Desactivar recursión” y aceptar.
Limitar la recursión a clientes autorizados.
Para servidores DNS implementados dentro de una organización o proveedor de servicios de Internet, el resolver debe configurarse dentro de una organización o proveedor de servicios de Internet, el resolver debe configurarse para permitir consultas recursivas solamente a clientes autorizados. Normalmente estas solicitudes sólo deben provenir de los clientes dentro del intervalo de direcciones de red de la organización, recomendamos que los administradores de servidor restrinjan la recursividad sólo a estos clientes
Bind
En las opciones globales, incluir lo siguiente (como ejemplo):
acl redes_confiables {10.250.40.0/24; 10.252.41.0./24; };
options {
allow-query { any; };
allow-recursion { redes_confiables; };
};
Microsoft DNS Server
Actualmente no es posible restringir las consultas recursivas para un rango de direcciones particular en Microsoft DNS Server. Para aproximar la funcionalidad de las listas de control de acceso en el servidor DNS de Microsoft, debe configurarse internamente un servidor sólo-caché diferente para proporcionar resolución recursiva. Deben crearse reglas en el firewall para bloquear el acceso desde fuera de la red de la organización al servidor caché. El servidor DNS autoritativo tendría que estar alojado en un servidor independiente y con recursividad.
Limitar el número máximo de respuestas. (Response Rate Limiting, RRL)
BIND9 permite a un administrador limitar el número máximo de respuestas por segundo que son enviadas a un cliente desde el servidor DNS. Esta funcionalidad está diseñada para ser utilizada en los servidores DNS autoritativos solamente, ya que afecta el desempeño en resoluciones recursivas. Esta propiedad reduce la efectividad y el impacto de un ataque de amplificación de DNS, ya que reduce la cantidad de tráfico proveniente de otro servidor autoritativo, sin afectar el desempeño de los resolver recursivos internos.
BIND9
Esta característica está disponible desde la versión 9.8. Se debe añadir las siguientes líneas entre las opciones de las vistas autoritativas.
rate-limit {
responses-per-second 5;
window 5;
};
Microsoft DNS Server
Actualmente esta característica no está disponible para Microsoft DNS Server.
IV. Información adicional
http://www.team-cymru.org/ReadingRoom/Tips/dns.html
http://www.ietf.org/rfc/rfc5358.txt
http://openresolverproject.org
http://tools.ietf.org/html/bcp38
http://cert.inteco.es/extfrontinteco/img/File/intecocert/ManualesGuias/guia_de_seguridad_en_servicios_dns.pdf
V. Información de contacto
CSIRT PANAMA
Autoridad Nacional para la Innovación Gubernamental
E-Mail: info@cert.pa
Web: https://www.cert.pa
—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG v2.0.17 (MingW32)
mQENBE8C9KoBCAClkvrtdD08B1YgIntnK241GmWY7fRWtPn/QIEG1+TLokEuOhw+
Gq/lK/4NP9RzqpD57LcRUBiGgTmO/5C9xkhVmxz2jid0h03fLorC84rAk2pOjr0i
pbltETq9RCGhOWp13OV22x2yiIedBi05bzw3F+uLHhn9xKjmpBuZB6WO/TuD52DH
KRZtwSvoaa61vL0bGnIf3lNGWkALWEC3lGBppby4D05N2FNfgfOFr1yOpxTaRaDh
4kOnoAEWVzppkTPyqSOkwXmgdma8D9yqD41Ffu8ypGTv+OOVO7jDq8tx9wVZEU+w
pqBTzQcf0P0K7qO3igdHQxqHmqXsaJpbmvCBABEBAAG0KkNTSVJUIFBhbmFtYSAo
Q1NJUlQgUGFuYW1hKSA8aW5mb0BjZXJ0LnBhPokBOAQTAQIAIgUCTwL0qgIbDwYL
CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ2YlXchbysSSPSQgAooUy3qSR/YX2
H3USJ5VzrmnraHg5LIWRPIBD1PGrswjLE8hxdobPU/uzi9LWnEcDscfFVKM/K0Jt
bjeoESqCVFlpE0YXJWdDhy0m2WM410sDE2HVXbPhWGqrNeDb0VUV/LWag1yYTj5w
kkxma4Tk5TqlhgL5su2PpjtTdFSHYD4N+4mu7g1GhRrrpz+u7ZRm3b/WkAJg5FIg
U0MpPqUGAF5/pc02ZB10FdxDwWyXAkwYUN+zfLiKzKOrBGkEw9+jvFGU+z76P9Zk
1XJIexpmkBYTxc+TOclhAp/3HP4taoBHRMoR1q1YhdC++UgRSLmPLGn/AB707JzN
Q80++q2kWQ==
=JUYg
—–END PGP PUBLIC KEY BLOCK—–