Cuando se trata de DNS, Cricket Liu escribió literalmente el libro. Ha sido coautor de las cinco ediciones del libro «DNS and BIND» de O’Reilly, que generalmente se considera la guía definitiva sobre todo lo relacionado con el sistema de nombres de dominio. En la actualidad, Cricket es director de infraestructuras de Infoblox.
El sistema de nombres de dominio (DNS) es, sin duda, un componente fundamental de las redes informáticas, pero hay ocasiones en las que estas herramientas pueden utilizarse con fines ilícitos. En el New Tech Forum de esta semana, Cricket analiza el creciente problema de los ataques DDoS basados en el DNS y cómo afrontarlos. — Paul Venezia
Ataques DDoS basados en DNS: Cómo funcionan y cómo detenerlos
Los DDoS (ataques de denegación de servicio distribuidos) basados en DNS se han convertido en uno de los ataques destructivos más comunes en Internet. Pero, ¿cómo funcionan? ¿Y qué podemos hacer para defendernos de ellos?
En este artículo, describiré cómo los ataques DDoS explotan y tienen como objetivo la infraestructura DNS. También le mostraré lo que puede hacer para protegerse a sí mismo y a los demás.
El gran spoof
Generar un ataque DDoS utilizando la infraestructura DNS es notablemente sencillo: Los atacantes envían consultas a los servidores de nombres a través de Internet, y esos servidores de nombres devuelven las respuestas. Sin embargo, en lugar de enviar las consultas desde sus propias direcciones IP, los atacantes falsifican la dirección de su objetivo, que puede ser un servidor web, un router, otro servidor de nombres o casi cualquier nodo de Internet.
Falsificar las consultas DNS es especialmente fácil porque normalmente se realizan a través de UDP (el Protocolo de Datagramas de Usuario sin conexión). Enviar una consulta DNS desde una dirección IP arbitraria es tan sencillo y tiene más o menos el mismo efecto que escribir la dirección del remitente de otra persona en una tarjeta postal.
Simular las consultas no es suficiente para incapacitar a un objetivo, sin embargo. Si las respuestas a esas consultas no fueran más grandes que las propias consultas, un atacante haría igual de bien en inundar el objetivo con consultas falsas. No, para maximizar el daño al objetivo, cada consulta debería devolver una respuesta muy grande. Resulta que eso es muy fácil de instigar.
Desde la llegada de EDNS0, un conjunto de extensiones de DNS introducidas en 1999, los mensajes DNS basados en UDP han podido transportar muchos datos. Una respuesta puede ser de hasta 4.096 bytes. La mayoría de las consultas, en cambio, tienen menos de 100 bytes de longitud.
Hace tiempo, era relativamente difícil encontrar una respuesta tan grande en el espacio de nombres de Internet. Pero ahora que las organizaciones han empezado a desplegar DNSSEC, las Extensiones de Seguridad del DNS, es mucho más fácil. DNSSEC almacena claves criptográficas y firmas digitales en registros del espacio de nombres. Estos son positivamente enormes.
Puedes ver un ejemplo de una respuesta de la zona isc.org que contiene registros DNSSEC en mi blog. El tamaño de la respuesta es de 4.077 bytes, en comparación con una consulta de sólo 44 bytes.
Ahora, imagínese a los atacantes de todo Internet enviando esa consulta falsa desde la dirección IP de su servidor web a los servidores de nombres de isc.org. Por cada consulta de 44 bytes, su servidor web recibe una respuesta de 4.077 bytes, lo que supone un factor de amplificación de casi 93 veces.
Hagamos un cálculo rápido para saber hasta dónde puede llegar esto. Digamos que cada atacante tiene una conexión relativamente modesta de 1Mbps a Internet. Puede enviar unas 2.840 consultas de 44 bytes a través de ese enlace por segundo. Este flujo de consultas daría lugar a casi 93Mbps de respuestas que llegarían a su servidor web. Cada 11 atacantes representan 1Gbps.
¿Dónde encontrarían los atacantes antisociales 10 amigos para ayudarles a llevar a cabo un ataque? En realidad, no necesitan ninguno. Utilizarán una botnet de miles de ordenadores.
El efecto final es devastador. En su informe trimestral sobre ataques DDoS globales, Prolexic (una empresa de mitigación de ataques DDoS) informó de un reciente ataque basado en DNS contra un cliente que superó los 167 Gbps. Prolexic informó además de que el ancho de banda medio de los ataques DDoS había aumentado un 718%, hasta los 48 Gbps, en un solo trimestre.
¡Pero espere! ¿No podrían modificarse los servidores de nombres de isc.org para que reconocieran que se les está consultando una y otra vez por los mismos datos, desde la misma dirección IP? ¿No podrían aplastar el ataque?
Claro que pueden. Pero los servidores de nombres de isc.org no son los únicos que un atacante puede utilizar para amplificar su tráfico. Claro, hay otros servidores de nombres autorizados que el atacante podría utilizar, pero aún peor son los servidores de nombres recursivos abiertos.
Un servidor de nombres recursivo abierto es simplemente un servidor de nombres que procesará consultas recursivas desde cualquier dirección IP. Yo puedo enviarle esa consulta de datos de isc.org y me responderá, y tú puedes hacer lo mismo.
No debería haber muchos servidores de nombres recursivos abiertos en Internet. La función de un servidor de nombres recursivo es buscar datos en el espacio de nombres de Internet en nombre de los clientes DNS, como los de tu portátil o smartphone. Los administradores de red que configuran los servidores de nombres recursivos (como tu departamento de TI) suelen destinarlos a una comunidad concreta (por ejemplo, tú y tus compañeros de trabajo). A no ser que estén ejecutando servicios como OpenDNS o Google Public DNS, no pretenden que los utilicen los ciudadanos de Moldavia. Así que los administradores de espíritu público, preocupados por la seguridad y, sobre todo, competentes, configuran controles de acceso en sus servidores de nombres recursivos para limitar su uso a los sistemas autorizados.
Dado esto, ¿qué tan grande puede ser el problema de los servidores de nombres recursivos abiertos? Bastante grande. El Open Resolver Project ha recopilado una lista de 33 millones de servidores de nombres recursivos abiertos. Los piratas informáticos pueden lanzar consultas falsas a tantos de ellos como quieran para arrojar datos de isc.org a su servidor web, servidor de nombres o router de frontera hasta que se ahogue.
Así es como funcionan los ataques DDoS basados en DNS. Afortunadamente, tenemos algunas formas de combatirlos.
Cómo capear el temporal
La primera orden del día es instrumentar su infraestructura DNS, para saber cuándo está siendo atacada. Demasiadas organizaciones no tienen ni idea de cuál es su carga de consultas, por lo que nunca sabrán si están siendo atacadas en primer lugar.
Determinar su carga de consultas puede ser tan sencillo como utilizar el soporte de estadísticas incorporado en BIND. El servidor de nombres BIND volcará los datos a su archivo de estadísticas cuando ejecute rndc stats, por ejemplo, o en un intervalo de estadísticas configurable. Puedes examinar las estadísticas para ver la tasa de consultas, los errores de socket y otras indicaciones de un ataque. No se preocupe si no está seguro de cómo será un ataque todavía – parte del objetivo de monitorizar el DNS es establecer una línea de base, para que pueda identificar lo que es anormal.
A continuación, eche un vistazo a su infraestructura orientada a Internet. No se limite a sus servidores de nombres autoritativos externos; examine su infraestructura de switches y routers, sus cortafuegos y sus conexiones a Internet. Identifique cualquier punto único de fallo. Determine si puede eliminarlos fácilmente (y de forma rentable).
Si es posible, considere una amplia distribución geográfica de sus servidores de nombres autoritativos externos. Esto ayuda a evitar puntos únicos de fallo, por supuesto, pero también ayuda cuando no está bajo ataque. Un servidor de nombres recursivo que resuelva un nombre de dominio en una de sus zonas intentará consultar al servidor de nombres autoritativo más cercano, por lo que la distribución geográfica tenderá a proporcionar un mejor rendimiento a sus clientes y corresponsales. Si sus clientes están agrupados en determinadas zonas geográficas, intente colocar un servidor de nombres autoritativo cerca de ellos para proporcionar las respuestas más rápidas.
Tal vez la forma más básica de combatir los ataques DoS sea sobreprovisionar su infraestructura. La buena noticia es que sobreaprovisionar sus servidores de nombres no es necesariamente caro; un servidor de nombres capaz puede manejar decenas o incluso cientos de miles de consultas por segundo. ¿No está seguro de la capacidad de sus servidores de nombres? Puede utilizar herramientas de consulta como dnsperf para probar el rendimiento de sus servidores de nombre, preferiblemente utilizando una plataforma de prueba similar a sus servidores de nombre de producción en un laboratorio en lugar de los propios servidores de producción.
Decidir cuánto sobreaprovisionar sus servidores de nombre es subjetivo: ¿Cuál es el valor de su presencia en línea? ¿Hay otros componentes de su infraestructura de cara a Internet que fallarán antes que los servidores de nombres? Obviamente, es temerario gastar dinero para construir una infraestructura DNS de primera clase detrás de un enrutador de frontera o un cortafuegos que fallará mucho antes de que sus servidores de nombres ni siquiera empiecen a sudar.
Si el dinero no es un problema, podría ser útil saber que los ataques DDoS de última generación contra la infraestructura DNS pueden superar los 100Gbps.
Usar Anycast también puede ayudar a resistir un ataque DDoS. Anycast es una técnica que permite que varios servidores compartan una única dirección IP, y funciona especialmente bien con el DNS. De hecho, los servidores de nombres raíz de Internet han utilizado Anycast durante años para proporcionar datos de la zona raíz en todo el mundo al tiempo que permite que la lista de raíces quepa en un único mensaje DNS basado en UDP.
Para implementar Anycast, los hosts que soportan sus servidores de nombres tendrán que ejecutar un protocolo de enrutamiento dinámico, como OSPF o BGP. El proceso de enrutamiento anunciará a sus enrutadores vecinos una ruta a una nueva dirección IP virtual en la que su servidor de nombres escucha. El proceso de enrutamiento también debe ser lo suficientemente inteligente como para dejar de anunciar esa ruta si el servidor de nombres local deja de responder. Usted puede pegar su demonio de enrutamiento a la salud de su servidor de nombres utilizando código de su propia construcción – o puede comprar un producto que se encarga de eso por usted. NIOS de Infoblox, no por casualidad, incluye soporte para Anycast.
¿Cómo se defiende Anycast contra los ataques DDoS? Bien, digamos que tiene seis servidores de nombres externos en dos grupos Anycast (es decir, tres que comparten una dirección IP Anycast y tres que comparten otra). Cada grupo contiene un miembro en Estados Unidos, otro en Europa y otro en Asia. Un host que monte un ataque DDoS contra usted sólo puede enviar tráfico a -y por lo tanto sólo atacar- un miembro de cualquiera de los grupos desde cualquier punto de Internet a la vez. A menos que los atacantes puedan enviar suficiente tráfico desde América del Norte, Europa y Asia simultáneamente para inundar su infraestructura, no tendrán éxito.
Por último, hay una manera de aprovechar la amplia distribución geográfica y Anycast al mismo tiempo, sin un gasto de capital significativo: Utilizar un proveedor de DNS basado en la nube. Empresas como Dyn y Neustar gestionan sus propios servidores de nombres Anycast en centros de datos de todo el mundo. Usted les paga por alojar sus zonas y responder a las consultas de sus datos. Y puedes seguir manteniendo el control directo sobre los datos de tus zonas pidiendo a un proveedor que configure sus servidores de nombres como secundarios para tus zonas, cargando los datos desde un servidor de nombres maestro que designes y gestiones internamente. Sólo asegúrese de que ejecuta el maestro oculto (es decir, sin ningún registro NS que apunte a él), o corre el riesgo de que un atacante se dirija a él como un único punto de fallo.
Una palabra de precaución al utilizar proveedores de DNS basados en la nube: La mayoría le facturan, al menos en parte, en función del número de consultas que reciben sus servidores de nombres para los datos de sus zonas. En un ataque DDoS, esas consultas podrían aumentar drásticamente (completamente fuera de su control y en absoluto para su beneficio), así que asegúrese de que tienen una disposición para hacer frente a los ataques DDoS sin pasar el costo del tráfico a usted.
Cómo evitar convertirse en un cómplice de los ataques DDoS
Ahora usted sabe cómo configurar su infraestructura DNS para resistir un ataque DDoS. Sin embargo, es casi igual de importante asegurarse de que no es cómplice de un ataque DDoS contra otra persona.
¿Recuerda la descripción de cómo los servidores DNS pueden amplificar el tráfico? Los atacantes pueden utilizar tanto los servidores de nombres recursivos abiertos como los servidores de nombres autoritativos como amplificadores, enviando consultas falsas que hacen que los servidores de nombres envíen respuestas más de 100 veces mayores que la consulta a objetivos arbitrarios en Internet. Ahora, por supuesto, usted no quiere ser el objetivo de tal ataque, pero tampoco quiere ser cómplice. El ataque utiliza los recursos de sus servidores de nombres, así como su ancho de banda. Si el objetivo toma medidas para bloquear el tráfico de su servidor de nombres a su red, entonces después de que el ataque termine, el objetivo puede no ser capaz de resolver nombres de dominio en sus zonas.
Si ejecuta un servidor de nombres recursivo abierto, la solución es simple: No lo haga. Hay muy pocas organizaciones que tienen alguna justificación para ejecutar un servidor de nombres abierto a las consultas recursivas. Los DNS públicos de Google y OpenDNS son dos que me vienen a la mente, pero si estás leyendo esto, supongo que probablemente no eres ellos. El resto de nosotros deberíamos aplicar controles de acceso a nuestros servidores de nombres recursivos para asegurarnos de que sólo los utilizan los consultores autorizados. Eso probablemente significa limitar las consultas DNS a las direcciones IP de nuestras redes internas, lo cual es fácil de hacer en cualquier implementación de servidor de nombres que se precie. (El servidor DNS de Microsoft no admite controles de acceso basados en direcciones IP en las consultas. Lea lo que quiera en eso.)
¿Pero qué pasa si ejecuta un servidor de nombres autoritativo? Obviamente, no puede limitar las direcciones IP de las que aceptará consultas – o no mucho, de todos modos (podría denegar consultas de direcciones IP obviamente falsas, como las direcciones RFC 1918). Pero puedes limitar las respuestas.
Dos veteranos «sombreros blancos» de Internet, Paul Vixie y Vernon Schryver, se dieron cuenta de que los ataques DDoS que utilizan servidores de nombres autorizados para la amplificación muestran ciertos patrones de consulta. En particular, los atacantes envían a los servidores de nombres la misma consulta desde la misma dirección IP falsa (o bloque de direcciones) una y otra vez, buscando la máxima amplificación. Ningún servidor de nombres recursivo que se comporte bien haría eso. Habría almacenado la respuesta en la caché y no habría vuelto a preguntar hasta que hubiera transcurrido el tiempo de vida de los registros en la respuesta.
Vixie y Schryver idearon un mecanismo inteligente, llamado Response Rate Limiting (RRL), que permite a un servidor de nombres autoritativo hacer un seguimiento de las veces que ha enviado la misma respuesta al mismo consultante. Si esa tasa supera algún umbral configurable, el servidor de nombres dejará de enviar esa respuesta al consultante durante un periodo determinado. Si el consultante deja de acribillar al servidor de nombres autorizado con la misma pregunta, el servidor de nombres autorizado dejará de silenciar esa respuesta. El resultado es que el servidor de nombres autoritativo nunca enviará ninguna respuesta a un querier a un ritmo superior al umbral, lo que lo hace inútil en un ataque DDoS.
RRL se incorporó a los servidores de nombres BIND en la versión 9.9.4, y algunas otras implementaciones de servidores de nombres ahora lo soportan, incluyendo NSD y Knot. A medida que la gente actualice sus servidores de nombres a versiones más nuevas o a nuevas implementaciones que soporten RRL, esto debería dificultar gradualmente que los atacantes utilicen la infraestructura DNS como amplificadores.
Espero que esta discusión le haya ayudado a entender cómo la infraestructura de DNS es objetivo y explotada en los ataques DDoS, y cómo puede resistir mejor los ataques DDoS y asegurarse de que sus servidores de nombres, sin saberlo, no participen en uno.
New Tech Forum proporciona un medio para explorar y discutir la tecnología empresarial emergente con una profundidad y amplitud sin precedentes. La selección es subjetiva, basada en nuestra elección de las tecnologías que consideramos importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta material de marketing para su publicación y se reserva el derecho de editar todos los contenidos aportados. Envíe todas las consultas a [email protected].
Este artículo, «La guía definitiva para prevenir ataques DDoS basados en DNS», fue publicado originalmente en InfoWorld.com. Para conocer las últimas noticias sobre tecnología empresarial, siga a InfoWorld.com en Twitter.