Resumen
- Confirmado:El 21 de octubre de 2016, DYN informó de ataques DDoS contra su infraestructura de DNS gestionado. Su comunicado público indicó que la primera oleada comenzó alrededor de las 7:00 a.m. hora del Este, afectó a los usuarios dirigidos a los servidores de DYN en la costa este de EE.UU. y se mitigó aproximadamente dos horas después. Una segunda oleada, más global, comenzó justo antes del mediodía y se mitigó en poco más de una hora. DYN afirmó que una tercera oleada fue mitigada sin afectar a los clientes.
- Observado:ThousandEyes midió altas tasas de fallos en las consultas DNS desde sus puntos de observación globales e informó de que alrededor del 75 % de esos puntos enviaron consultas que no obtuvieron respuesta de los servidores de DYN en el momento álgido del ataque. También observó aproximadamente 1 200 sitios y servicios afectados entre los que supervisaban sus clientes, y comprobó que muchos clientes vulnerables utilizaban únicamente los servidores de nombres de DYN en lugar de recurrir a varios proveedores de DNS.
- Atribución limitada:DYN declaró que los análisis de Flashpoint y Akamai confirmaron que una de las fuentes del tráfico fueron dispositivos infectados por Mirai. El Departamento de Justicia de EE.UU. (DOJ) anunció posteriormente las declaraciones de culpabilidad de los creadores de Mirai y otro caso de culpabilidad por parte de un individuo cuyo ataque con una botnet variante de Mirai el 21 de octubre de 2016 afectó a DYN y dejó sitios como Sony, Twitter, Amazon, PayPal, Tumblr, Netflix y Southern New Hampshire University inaccesibles o con interrupciones durante varias horas. El registro público no prueba que un único actor, una sola botnet o un solo vector de ataque explique todo el tráfico que DYN vio ese día.
- Evaluación:El incidente fue un fallo de dependencia de modo común. DYN controlaba su plataforma de DNS gestionado, sus socios de mitigación, las comunicaciones y la arquitectura de su infraestructura. Los clientes controlaban si su DNS autoritativo estaba diversificado entre proveedores y si las prácticas de TTL, conmutación por error y supervisión estaban a la altura de sus propias afirmaciones de disponibilidad. Los fabricantes de IoT, propietarios de dispositivos, ISP, reguladores y atacantes controlaban distintas partes del problema de la botnet.
El DNS falló antes de que lo hiciera la aplicación web
Normalmente, un usuario percibe el DNS solo cuando falla. El nombre del sitio parece correcto. El navegador funciona. La conexión del usuario puede ser estable. La aplicación de destino puede seguir ejecutándose. Sin embargo, si la ruta del DNS autoritativo no puede responder, el servicio puede desaparecer como si los propios servidores hubieran dejado de existir. Eso es lo que hizo tan desconcertante el incidente de DYN. Muchos servicios no estaban necesariamente rotos en su propia capa de aplicación. Sus nombres no podían resolverse con la suficiente fiabilidad para que los usuarios llegaran a ellos.
El incidente de octubre de 2016 se sitúa en la intersección de dos formas de externalización. En primer lugar, muchas empresas digitales externalizaron el DNS autoritativo a un proveedor gestionado porque este podía ofrecer alcance global mediante anycast, dirección de tráfico, experiencia operativa y preparación frente a DDoS que muchos clientes no podían construir por sí mismos de forma rentable. En segundo lugar, millones de hogares y organizaciones habían colocado dispositivos conectados inseguros en la internet pública, a menudo con credenciales predeterminadas débiles o rutas de actualización deficientes. Mirai convirtió esa segunda opción de externalización en tráfico de ataque contra la primera.
El propio comunicado de DYN, conservado en una copia pública en PDF de laDeclaración de DYN sobre el ataque DDoS del 21/10/2016, indicaba que la empresa sufrió ataques DDoS contra su infraestructura de DNS gestionado. Describía una primera oleada que comenzó alrededor de las 7:00 a.m. hora del Este, una restauración unas dos horas después, una segunda oleada más global justo antes del mediodía, restauración hacia la 1:00 p.m. y una tercera oleada que DYN afirmó haber mitigado sin afectar a los clientes. DYN también afirmó que en ningún momento se produjo una interrupción total del sistema y que algunos usuarios, como los que accedían a los sitios afectados desde la costa oeste de EE.UU. durante la primera oleada, habrían podido acceder sin problemas.
Ese detalle es importante. El incidente no fue una interrupción binaria y limpia en la que todos los clientes de DYN desaparecieron en todas partes. Fue un fallo de disponibilidad condicionado por la geografía, el anycast, el comportamiento de los resolutores, el tiempo de vida (TTL), la configuración del dominio del cliente y la intensidad cambiante del tráfico DDoS. Eso dificultó la comunicación. Un cliente podía probar desde una red y ver éxito mientras que otros usuarios veían fallos. Un propietario de una plataforma podía tener servidores de aplicaciones en buen estado y aun así recibir quejas de que el servicio no funcionaba. Un usuario podía esperar hasta que caducara una respuesta DNS almacenada en caché y luego, de repente, perder el acceso.
La dependencia compartida se reflejaba en las mediciones
El análisis de ThousandEyes,El ataque DDoS a la infraestructura DNS de DYN, proporciona la explicación pública más clara de la dependencia del lado del cliente. Su monitorización observó tres fases: impacto inicial concentrado en la costa este de EE.UU., un impacto global más amplio y una mitigación posterior con ataques residuales o blackholing. En el punto álgido del ataque, aproximadamente tres cuartas partes de sus puntos de observación globales enviaron consultas DNS que quedaron sin respuesta por parte de los servidores de DYN. También informó de unos 1 200 sitios y servicios afectados entre los dominios que sus clientes supervisaban.
La cuestión técnica era simple pero grave. DYN ejecutaba servidores autoritativos para los dominios de los clientes. Si un resolutor no disponía ya de una respuesta fresca en caché y no podía contactar con los servidores autoritativos de DYN, no podía obtener la dirección necesaria para conectarse. Unos valores de tiempo de vida (TTL) más cortos pueden hacer que la gestión del tráfico sea más ágil en operaciones normales, pero también hacen que los usuarios dependan con más frecuencia de una resolución autoritativa exitosa. Un TTL bajo no es malo en sí mismo; es una solución de compromiso. Durante un evento de DDoS contra un proveedor de DNS, puede acortar el tiempo entre «la caché aún sabe adónde ir» y «el resolutor debe preguntar de nuevo a la autoridad inaccesible».
ThousandEyes también describió la popularidad de DYN para la dirección de tráfico. El DNS gestionado no era una mera guía telefónica estática. Ayudaba a los grandes servicios a dirigir a los usuarios hacia centros de datos cercanos, desviar tráfico y optimizar el rendimiento. Eso significa que el producto que mejoraba la resiliencia y la velocidad en condiciones normales también se convirtió en una dependencia cuyo deterioro podía afectar a muchos clientes a la vez. Cuanto más sólida era la propuesta de valor del proveedor, más atractivo resultaba como plano de control compartido.
El hallazgo más importante de ThousandEyes en materia de responsabilidad fue la arquitectura de los clientes. Muchos clientes afectados de DYN utilizaban únicamente los servidores de nombres de DYN en lugar de diversificar entre varios proveedores de DNS. El análisis contrastaba a los clientes con un único proveedor de DNS gestionado con Amazon.com, que utilizaba más de un proveedor y experimentaba tiempos de carga más lentos en lugar del mismo patrón de indisponibilidad total observado por muchos otros. Eso no significa que todos los clientes pudieran haber pasado a un DNS multiproveedor de la noche a la mañana. Significa que el riesgo era arquitectónico, visible y, en parte, controlado por los clientes.
Lanoticia de AP reflejada por el Chicago Sun-Timescaptó la experiencia del público: efectos en cadena para los usuarios que intentaban acceder a sitios web populares en Estados Unidos y Europa, con Twitter, Netflix y la PlayStation Network de Sony entre los servicios aparentemente afectados. Elreportaje contemporáneo del Guardianenumeraba Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News y grandes periódicos entre los servicios que se notificaron como fuera de línea o degradados. Estos reportajes son útiles para evaluar el alcance y la percepción pública; no prueban que cada servicio nombrado experimentara el mismo modo de fallo técnico o la misma duración.
El fallo de modo común se oculta dentro de un DNS «redundante»
El DNS incorpora redundancia en su diseño. Los dominios enumeran varios servidores de nombres. Los resolutores pueden probar alternativas. Los servidores autoritativos pueden estar geográficamente dispersos. El problema es que la redundancia puede ser formal sin ser independiente frente a fallos.
LaRFC 2182afirma desde 1997 que una razón principal para disponer de varios servidores DNS es mantener la información de zona disponible incluso cuando un servidor no es accesible, y que los servidores secundarios deben estar geográfica y topológicamente dispersos. Advierte contra configuraciones en las que todos los servidores comparten el mismo modo de fallo local. En lenguaje corriente: tener varios servidores de nombres no basta si fallan juntos.
El caso DYN trasladó ese principio de la ubicación física a la dependencia del proveedor. Un cliente podía enumerar varios servidores de nombres de DYN y seguir teniendo un único proveedor, una relación comercial, una ruta de soporte operativo, un conjunto de credenciales de gestión de DNS y una exposición única a un ataque importante contra ese proveedor. Desde la perspectiva del dominio, esos servidores de nombres pueden parecer diversos. Desde la perspectiva de la responsabilidad, siguen formando parte de una dependencia común del proveedor.
El artículoLa falta de redundancia en la resolución DNS de los principales sitios web y serviciosexaminó la concentración y diversificación del DNS tras el incidente de DYN. Encontró una concentración creciente entre un pequeño número de proveedores de DNS y una fuerte tendencia a que los dominios no utilizaran múltiples proveedores de gestión de DNS. En su muestra, la proporción de dominios que utilizaban un solo proveedor era de aproximadamente entre el 91 % y el 93 % antes del ataque, y descendió del 92,2 % al 89,4 % entre octubre y noviembre de 2016. Entre los clientes de DYN, la proporción de dominios no diversificados cayó bruscamente tras el incidente y siguió disminuyendo hasta mayo de 2017.
Esas cifras deben tratarse como hallazgos de investigación dentro de un conjunto de datos concreto, no como un censo exacto de todo internet. Aun así, respaldan la lección práctica. El DNS hacía posible la diversificación entre proveedores, pero muchos clientes habían optado por la simplicidad operativa en lugar de la independencia frente a fallos. Eso no es irracional. El DNS autoritativo multiproveedor introduce complejidad: datos de zona coherentes, firma DNSSEC y gestión de claves, comportamiento de las comprobaciones de estado, diferencias en la dirección de tráfico, retrasos de propagación, riesgo de cerebro dividido, supervisión y responsabilidad contractual. El coste de la diversidad es real. El ataque a DYN demostró que el coste de no diversificar también puede volverse real, y puede llegar a través de un proveedor en lugar de la propia infraestructura del cliente.
El anycast es potente, pero no es magia
La infraestructura de DYN, como la de muchas plataformas globales de DNS, utilizaba anycast. El anycast permite que múltiples ubicaciones anuncien la misma dirección IP para que el enrutamiento de internet envíe al resolutor a una instancia cercana o preferida. Mejora la latencia y absorbe muchos fallos locales porque el tráfico puede desplazarse por la red. Es una de las razones por las que los proveedores de DNS gestionado pueden ofrecer un amplio alcance y una respuesta rápida.
El anycast no hace que la capacidad sea infinita. Puede distribuir el tráfico, pero también puede distribuir la presión del ataque. Si el ataque es lo bastante grande, amplio o dirigido de forma que congestione los enlaces ascendentes, el peering o los prefijos compartidos, las ubicaciones anycast pueden fallar a la vez o fluctuar de forma compleja. ThousandEyes observó que muchas consultas no conseguían atravesar los proveedores de internet de DYN o el borde de su red, y que los servidores de nombres dentro de la misma constelación y grupo mostraron un rendimiento correlacionado. Esa observación no demuestra que el diseño interno de DYN fuera negligente. Muestra por qué «tener múltiples puntos de presencia» no es lo mismo que «tener disponibilidad independiente en todas las condiciones plausibles de DDoS».
El comunicado de DYN decía que practicaban escenarios, tenían libros de procedimientos, utilizaban socios de mitigación e iniciaron la gestión de incidentes y la comunicación con los clientes. También decía que los ataques estaban muy distribuidos, implicaban decenas de millones de direcciones IP discretas asociadas con Mirai y utilizaban múltiples vectores y ubicaciones de internet. No se debe juzgar a un proveedor como si la mitigación de DDoS fuera una simple cuestión de comprar suficiente ancho de banda. Los ataques distribuidos muy grandes generan errores de medición, tormentas de reintentos, tráfico colateral, inestabilidad de rutas y difíciles compromisos entre filtrar el tráfico de ataque y preservar las consultas legítimas.
Aun así, los clientes compran DNS gestionado porque el proveedor afirma tener experiencia precisamente en este ámbito operativo. DYN poseía, por tanto, la responsabilidad del lado del proveedor en materia de resiliencia: planificación de capacidad, coordinación con los proveedores de tránsito, arquitectura anycast, diseño de la constelación de servidores de nombres, comunicación de estado, soporte al cliente, preparación de los socios de mitigación y evidencias posteriores al incidente. Un relato de responsabilidad justo puede mantener ambas ideas a la vez. El ataque fue malicioso y de gran envergadura. El negocio de DYN era mantener el DNS autoritativo accesible en condiciones hostiles.
Mirai trasladó el riesgo de los dispositivos de consumo a la infraestructura
Mirai hizo que el ataque fuera culturalmente memorable porque la botnet se construyó en gran medida a partir de dispositivos comunes conectados a internet: cámaras, enrutadores, grabadores de vídeo digital y sistemas integrados similares. Elartículo de USENIX Understanding the Mirai Botnetdescribe Mirai como compuesta principalmente por dispositivos integrados y de IoT, y afirma que creció hasta un pico de unos 600 000 infecciones. El artículo sostiene que la simplicidad del método de infección y el rápido crecimiento demostraron que técnicas relativamente poco sofisticadas podían comprometer suficientes dispositivos de gama baja como para amenazar objetivos bien defendidos.
El anuncio de 2017 del Departamento de Justicia sobre Mirai,El Departamento de Justicia anuncia cargos y declaraciones de culpabilidad en tres casos de delitos informáticos relacionados con importantes ataques DDoS, señaló que Paras Jha, Josiah White y Dalton Norman se declararon culpables de operar la botnet Mirai, que tenía como objetivo dispositivos IoT como cámaras inalámbricas, enrutadores y grabadores de vídeo digital. El DOJ afirmó que Mirai llegó a estar compuesta por cientos de miles de dispositivos comprometidos en su punto álgido, y que la implicación de los creadores originales con la variante original de Mirai terminó cuando Jha publicó el código fuente en un foro criminal en otoño de 2016. Desde entonces, según el DOJ, otros actores utilizaron variantes de Mirai en otros ataques.
El anuncio de 2020 del Departamento de Justicia,Un individuo se declara culpable de participar en un ciberataque del Internet de las Cosas en 2016, relacionó más directamente una botnet variante de Mirai con el día de DYN. Señaló que un individuo, antes menor de edad, se declaró culpable en relación con un ciberataque de octubre de 2016. Según el DOJ, dicho individuo y otros utilizaron una botnet para lanzar varios ataques DDoS el 21 de octubre de 2016 con el objetivo de sacar de línea la PlayStation Network de Sony; los ataques afectaron a DYN, lo que provocó que sitios como Sony, Twitter, Amazon, PayPal, Tumblr, Netflix y Southern New Hampshire University resultaran inaccesibles o intermitentes durante varias horas.
Ese historial de atribución debe utilizarse con cautela. No dice que el actor juvenil fuera la única causa de todos los impactos en DYN, ni significa que toda la combinación de tráfico de DYN procediera de una sola botnet. DYN mismo dijo que una fuente del tráfico de ataque eran dispositivos infectados por Mirai. El proveedor también describió múltiples vectores y ubicaciones de internet. La conclusión más segura es que Mirai y sus variantes estuvieron materialmente implicados, y que la capa de conducta delictiva es independiente de la capa de arquitectura de resiliencia.
Laalerta de CISA sobre la amenaza Miraiadvirtió de que el malware Mirai escaneaba en busca de dispositivos IoT vulnerables y de que la publicación del código fuente de Mirai aumentaba el riesgo de más botnets. El posterior informe del Departamento de Comercio y Seguridad Nacional alojado por el NIST,Mejora de la resiliencia del ecosistema de Internet y las comunicaciones frente a botnets y otras amenazas automatizadas y distribuidas, enmarcó el problema como algo que afecta a todo el ecosistema: los ataques distribuidos automatizados son globales, las herramientas eficaces no se utilizan ampliamente, los productos deben protegerse a lo largo de todo su ciclo de vida, los incentivos no están alineados y ninguna comunidad de partes interesadas puede resolver el problema por sí sola.
Ese encuadre de ecosistema encaja mejor con el incidente de DYN que una estrecha historia de culpas. Los atacantes abusaron de dispositivos que no les pertenecían. Los fabricantes de dispositivos habían comercializado a menudo productos de bajo coste sin controles sólidos de actualización, identidad y ciclo de vida. Los propietarios de dispositivos rara vez entendían que una cámara o un grabador en un armario pudiera participar en un ataque contra la infraestructura de DNS. Los ISP tenían una visibilidad parcial del tráfico de dispositivos infectados, pero con incentivos contradictorios y limitaciones prácticas. Los proveedores de DNS veían el ataque cuando llegaba a su perímetro. Los clientes lo veían cuando sus nombres dejaban de resolverse. Los usuarios solo lo veían como un sitio que no cargaba.
La posteriorLínea de base de capacidades de ciberseguridad para dispositivos IoT NISTIR 8259Ano existía en 2016 y no debe interpretarse como una obligación legal retroactiva para DYN. Sigue siendo útil como evidencia de lo que el ecosistema aprendió a valorar: identificación del dispositivo, configuración segura, protección de datos, acceso lógico, capacidad de actualización de software, conciencia del estado de ciberseguridad y documentación. Mirai tuvo éxito porque demasiados dispositivos no podían gestionarse como participantes responsables de internet.
El control de los clientes era real, pero desigual
Los clientes de DNS gestionado no eran meros espectadores pasivos. El propietario del dominio controla las decisiones de delegación, la selección del proveedor, la supervisión, la política de TTL, el diseño de conmutación por error y si los servicios críticos pueden sobrevivir a la pérdida de un proveedor de DNS. Sin embargo, el control no era igual para todos los clientes. Una gran plataforma con un equipo de infraestructura experimentado podía utilizar múltiples proveedores autoritativos, autoalojar parte de la pila, mantener la automatización de la coherencia y probar la resolución desde muchas redes. Un pequeño editor, minorista, proveedor de software, organización sin ánimo de lucro o servicio municipal podría haber contratado DNS gestionado precisamente para evitar necesitar esa capacidad.
Aquí es donde la dependencia de los servicios en la nube se convierte en un problema de responsabilidad. Un proveedor puede vender experiencia, pero los clientes aún deben decidir qué nivel de fallo del proveedor pueden tolerar. La pregunta no es «¿debería cada sitio web gestionar una red de DNS global a medida?». Eso sería económicamente absurdo. La pregunta es si las promesas de disponibilidad del cliente coinciden con su mapa de dependencias. Una empresa que considera la accesibilidad en línea como crítica para su misión debería saber si un único proveedor de DNS gestionado constituye un punto único de fallo. Debería saber con qué rapidez puede cambiar la delegación en el registrador, cuánto tiempo vivirán los registros NS en caché, si un proveedor secundario tiene una zona actualizada, si DNSSEC seguirá validando y si la conmutación por error puede probarse sin crear un incidente público.
Para las organizaciones más pequeñas, la respuesta práctica puede no ser una arquitectura multiproveedor perfecta. Podría ser un plan de recuperación más limitado: un segundo proveedor configurado para los registros más importantes, TTL más largos para los activos estables cuando proceda, credenciales del registrador accesibles para más de una persona de confianza, páginas de estado fuera de banda, información de contacto de emergencia almacenada en caché y una supervisión que distinga el fallo de resolución de DNS del fallo de la aplicación. Esto es menos elegante que una diversidad totalmente automatizada, pero sigue siendo mejor que descubrir la dependencia durante un incidente global del proveedor.
El riesgo también se extiende a los usuarios finales. Un mercado, editor, proveedor de SaaS o servicio de pago que queda inaccesible traslada los costes a anunciantes, vendedores, equipos de soporte, contratistas y clientes. El usuario no puede ver si la causa raíz es DNS, DDoS, alojamiento en la nube, enrutamiento del ISP o un error de la aplicación. Simplemente no puede realizar transacciones. Dado que el DNS gestionado se sitúa tan temprano en la ruta, su fallo puede hacer que toda la redundancia posterior sea irrelevante hasta que se restablezca la resolución de nombres.
La comunicación tenía que atender a dos públicos
DYN tenía dos problemas de comunicación. Tenía que informar a sus clientes directos de lo que ocurría y de lo que podían esperar. También tenía que comunicarse con la comunidad de internet en general porque la interrupción era visible mucho más allá de la base de clientes contratados de DYN. Los usuarios públicos, periodistas, reguladores, pares de infraestructura y competidores tenían interés en comprender si el evento era una interrupción selectiva de la plataforma, una inestabilidad más amplia de internet, una emergencia de botnet o un problema de concentración del DNS.
El comunicado de DYN ofreció una cuidada narrativa como proveedor: no fue generalizada en todo el sistema, varió según la región, hubo dos oleadas que afectaron a clientes, una tercera intentona mitigada, se activó la gestión de incidentes, participaron socios de mitigación, se confirmó a Mirai como una fuente de tráfico y se reservaron más detalles para preservar las defensas futuras. Ese equilibrio es defendible. Un proveedor de DDoS no debería publicar un plan completo de mitigación durante un ataque activo o repetible.
Sin embargo, los clientes necesitaban algo más que tranquilidad. Necesitaban apoyo para la toma de decisiones. ¿Debían cambiar de proveedor de DNS de inmediato? ¿Debían modificar los TTL? ¿Debían comunicar avisos de interrupción a sus propios clientes? ¿Se retrasó la propagación de las zonas? ¿Estaban afectadas todas las regiones? ¿Estaban intactos los registros DNS de los clientes? ¿Qué grupos de servidores de nombres estaban degradados? ¿Se esperaba que el problema se repitiera? Cuanto más se vende un proveedor como infraestructura de internet, más se convierte la comunicación de estado en parte del servicio.
El incidente también demostró por qué los clientes necesitan una supervisión independiente. La página de estado de un proveedor puede ir con retraso o simplificar. Las comprobaciones de las propias aplicaciones del cliente pueden pasar por alto el fallo de DNS si se ejecutan desde una red con cachés aún válidas. La supervisión debe poner a prueba la consulta autoritativa, la resolución recursiva desde múltiples regiones, la accesibilidad de la aplicación y los fallos específicos de cada dependencia. El análisis público de ThousandEyes fue eficaz porque separó el fallo de las consultas DNS de la sensación general de los usuarios de que «internet no funciona».
Las cachés, los reintentos y la preparación modificaron la forma del daño
El fallo del DNS no se experimenta de manera uniforme porque la capa recursiva se sitúa entre los usuarios y los proveedores autoritativos. Si un resolutor recursivo ya tiene una respuesta válida en caché, un usuario puede seguir accediendo a un servicio incluso cuando los servidores autoritativos están afectados. Si la respuesta en caché caduca, o si el resolutor no tiene respuesta, ese mismo servicio puede volverse repentinamente inaccesible desde esa red. Por tanto, dos usuarios en la misma ciudad pueden informar de resultados diferentes porque sus resolutores, cachés y el momento de la consulta difieren.
Ese comportamiento complica tanto la atribución de culpa como la respuesta. El propietario de un servicio puede observar sus servidores de origen y ver un estado normal. Un proveedor de DNS gestionado puede ver una mezcla de tráfico de ataque, reintentos legítimos de los resolutores, efectos de cachés obsoletas y cambios de ruta. Los operadores recursivos pueden aumentar la presión de consultas al reintentar cuando las respuestas expiran. Los usuarios ven una accesibilidad intermitente y pueden suponer que la aplicación está rota. La narrativa pública se convierte en «los sitios web importantes no funcionan», mientras que la realidad técnica se parece más a «algunos resolutores no pueden obtener o actualizar respuestas autoritativas para ciertos dominios durante ciertos intervalos».
Elvistazo rápido al ataque a DYNde RIPE Labs utilizó las mediciones de RIPE Atlas para observar el evento desde sondas distribuidas. Una nota complementaria de RIPE Labs,Especulando sobre DDoS de DNS, destacó que el tráfico de reintentos recursivos puede agravar el impacto y que distinguir el tráfico DNS legítimo del tráfico de ataque durante un DDoS basado en el protocolo DNS puede ser difícil. No se trata de juicios legales sobre DYN. Explican por qué la mitigación de DDoS de DNS es más complicada que bloquear una única fuente hostil o añadir un único servidor de respaldo.
Investigaciones posteriores al incidente hicieron la misma observación desde otro ángulo. El artículoWhen the Dike Breaks: Dissecting DNS Defenses During DDoSsostiene que el almacenamiento en caché es un factor importante en la resiliencia del DNS y que las distintas capas del DNS pueden experimentar los DDoS de manera muy diferente. El artículo utiliza el incidente de DYN como ejemplo de una interrupción visible que afectó a los dominios que utilizaban DYN como proveedor de DNS, al tiempo que señala que otros objetivos de DNS, como los servidores raíz, habían absorbido ataques sin interrupciones de servicio visibles. La lección no es que una capa del DNS sea segura y otra débil. Es que la arquitectura, el almacenamiento en caché, la diversidad, el volumen de tráfico y la práctica del operador se combinan para determinar el impacto público.
Para un cliente de DNS gestionado, esto significa que la preparación debe incluir algo más que el nombre de un proveedor en un registro de riesgos. El cliente necesita saber qué registros son lo bastante estables para una vida de caché más larga, qué registros requieren dirección dinámica, qué resolutores recursivos son importantes para sus usuarios y cómo las respuestas obsoletas podrían afectar a una conmutación por error. También necesita decidir si un cambio de emergencia en el TTL es útil antes de un incidente o mayormente simbólico después de que las cachés ya contengan el valor antiguo. Los cambios en el DNS dependen del tiempo; un plan de recuperación que asuma una propagación global instantánea no es un plan de recuperación.
Las guías generales sobre DDoS refuerzan la misma disciplina operativa. Lacolección de guías sobre denegación de serviciodel Centro Nacional de Ciberseguridad del Reino Unido (NCSC) enmarca la preparación en torno a cuatro prácticas: comprender el servicio, comprender las defensas, crear un plan de respuesta y poner a prueba la respuesta. La guíaEntendiendo los ataques de denegación de serviciode CISA explica el problema básico de disponibilidad: los usuarios legítimos no pueden acceder a los sistemas de información, dispositivos o recursos de red. La posterior guía de CISA, FBI y MS-ISACEntendiendo y respondiendo a los ataques distribuidos de denegación de servicioabarca más que el DNS, pero el principio encaja: las organizaciones necesitan preparación previa, coordinación con los proveedores de servicios, líneas base de tráfico, procedimientos de respuesta y planes de comunicación.
Esas prácticas ponen de manifiesto una verdad incómoda sobre las dependencias en la nube. Un cliente puede externalizar la operación del DNS, pero no puede externalizar el conocimiento de cómo el fallo del DNS afecta a su propio negocio. DYN podía mitigar los ataques contra su infraestructura; no podía conocer el estado degradado aceptable para cada cliente. Un banco, un mercado, un editor, una universidad, una red de juegos y un portal de citas hospitalarias tienen diferente tolerancia a una resolución lenta, respuestas obsoletas y pérdida de accesibilidad regional. El plan de continuidad del cliente debe traducir el estado del proveedor en decisiones de negocio: si notificar a los usuarios, cambiar de canal, suspender transacciones, fallar en modo abierto, fallar en modo cerrado o aceptar una accesibilidad parcial hasta que el DNS se estabilice.
Para DYN, el mismo principio de preparación funciona en dirección contraria. Un proveedor de DNS gestionado debe comprender que un evento DDoS contra su propia infraestructura no es solo un incidente técnico dentro de su red. Es una crisis simultánea para los clientes. Los clientes necesitan suficiente información para evitar empeorar el evento improvisando cambios de delegación, acortando TTL, moviendo zonas de manera inconsistente o saturando el soporte. Los procedimientos del proveedor deben incluir, por tanto, mitigación, segmentación de clientes, precisión en el estado y orientación para clientes con diferentes niveles de sofisticación en DNS.
El incidente de octubre de 2016 fue dañino en parte porque reveló la fragilidad de la capa de preparación compartida. Los ingenieros de DNS entendían el almacenamiento en caché, el anycast y la resolución autoritativa. Muchos líderes empresariales y usuarios no. Algunos clientes entendían la diversidad de proveedores. Muchos no la habían implementado. Los expertos en seguridad de IoT entendían los riesgos de las credenciales predeterminadas y las flotas de dispositivos no gestionados. Millones de dispositivos ya estaban expuestos. Un fallo de modo común es a menudo lo que ocurre cuando el conocimiento especializado existe en comunidades separadas pero no se ha convertido en compromisos operativos compartidos.
El límite legal es más estrecho que la lección operativa
El registro público establece la actividad maliciosa de DDoS, la interrupción del servicio de DYN, los problemas de accesibilidad de los clientes, la implicación de Mirai y las posteriores declaraciones de culpabilidad. No establece que DYN incumpliera un contrato concreto, que todos los clientes afectados carecieran de una arquitectura razonable, que todos los fabricantes de IoT violaran un deber legal o que todas las pérdidas puedan atribuirse a un único acusado. Las condiciones de los contratos individuales de DYN, los acuerdos de nivel de servicio con los clientes, las pólizas de seguro y las dependencias de terceros no son públicas de manera que respalden conclusiones legales generales.
Ese límite no debería debilitar la lección operativa. La hace más clara. La culpa legal es específica de cada foro. El control operativo es visible en las decisiones de diseño. DYN controlaba la resiliencia y las comunicaciones a nivel de proveedor. Los clientes controlaban la diversificación del proveedor de DNS y la planificación de la continuidad. Los fabricantes de IoT controlaban las credenciales predeterminadas, las rutas de actualización y el soporte del ciclo de vida. Los propietarios de dispositivos controlaban el despliegue y el refuerzo básico solo en la medida en que los productos lo hacían factible. Los ISP y las empresas de seguridad controlaban la detección, notificación y opciones de mitigación. Los gobiernos controlaban los incentivos, las normas, la respuesta policial y la coordinación público-privada.
El incidente pertenece al análisis de responsabilidad porque ninguna capa podía arreglar el fallo completo. Un cliente con un DNS multiproveedor perfecto aún podría sufrir una botnet masiva en otra parte de su infraestructura. Una línea de productos IoT bien construida no diversificaría el DNS autoritativo de un cliente. Un proveedor de DNS brillante aún podría enfrentarse a un tráfico hostil sin precedentes procedente de dispositivos que no vendió. Un informe gubernamental podría recomendar la seguridad del ciclo de vida, pero no reemplazar instantáneamente millones de dispositivos expuestos. El fallo de modo común surgió del acoplamiento entre estas capas.
La señal del mercado tras el incidente
Un mes después del ataque, Oracle anunció que había acordado adquirir DYN. Elcomunicado de prensade Oracle describió a DYN como un proveedor líder de rendimiento de internet y DNS en la nube, afirmó que su red realizaba 40 000 millones de decisiones de optimización de tráfico al día para más de 3 500 clientes empresariales, y nombró clientes como Netflix, Twitter, Pfizer y CNBC. La adquisición no debe interpretarse como una consecuencia del ataque sin pruebas; el comunicado no afirmó tal cosa. Sigue siendo un contexto útil para el papel de DYN en el mercado. No era un servicio de nicho para aficionados. Era una gran plataforma de DNS gestionado para empresas digitales de alto perfil.
Esa posición en el mercado es la razón por la que el incidente sigue importando. La concentración en la nube suele generar beneficios reales: mejor experiencia, mayor alcance global, mitigación más rápida, personal especializado y economías de escala. También cambia el modo de fallo. Cuando muchos clientes convergen en el mismo proveedor, sus afirmaciones independientes de continuidad de negocio pueden correlacionarse. Una plataforma puede externalizar una función y seguir siendo responsable de las consecuencias de la arquitectura de externalización.
El informe de 2018 del Departamento de Comercio y Seguridad Nacional argumentó que los incentivos del mercado no estaban alineados en favor de la resiliencia frente a botnets. Un problema de incentivos similar existía en el lado del cliente del DNS gestionado. El DNS con un solo proveedor es más sencillo de adquirir, configurar, supervisar y mantener. El DNS multiproveedor reduce el riesgo de modo común pero aumenta la complejidad de ingeniería y la probabilidad de configuración incorrecta. El cliente que evita esa complejidad puede no ser penalizado nunca en tiempos normales. La penalización aparece solo cuando un proveedor falla bajo presión, y para entonces muchos clientes pueden experimentar el mismo evento a la vez.
Pruebas prácticas de responsabilidad
El caso DYN proporciona a los directivos varias pruebas que siguen siendo útiles.
Dependencia del DNS autoritativo:¿Qué proveedor responde por cada dominio y subdominio crítico? ¿Todos los servidores de nombres listados son operados por el mismo proveedor o a través del mismo plano de control de enrutamiento y gestión? ¿Qué servicios fallan si ese proveedor no es accesible desde una región importante?
Independencia del proveedor:¿Existe un segundo proveedor de DNS autoritativo con datos de zona actualizados? Si es así, ¿es realmente independiente en red, plano de control, credenciales, ruta de soporte y mitigación de DDoS? Si no, ¿ha aceptado la organización conscientemente el riesgo de un solo proveedor?
Estrategia de TTL y caché:¿Reflejan los TTL del DNS la necesidad real de agilidad de la organización frente a la tolerancia a las interrupciones? ¿Se otorga suficiente vida de caché a los registros más estables para reducir la dependencia evitable de consultas autoritativas frecuentes durante problemas transitorios del proveedor?
DNSSEC y control de cambios:Si DNSSEC está habilitado, ¿pueden las firmas, claves y registros DS sobrevivir a una operación multiproveedor o a un cambio de emergencia de proveedor? Si no, el modo de fallo seguro puede ser fallar de forma segura, lo que sigue significando que los usuarios no pueden acceder al servicio.
Supervisión:¿Puede la organización distinguir entre un fallo del DNS autoritativo, problemas del resolutor recursivo, problemas de CDN, fallo del origen y fallo de la aplicación? ¿Se ejecutan pruebas desde suficientes redes y regiones para detectar un problema de anycast o de DNS regional?
Recuperación del registrador:¿Están documentadas, protegidas y disponibles durante un incidente las credenciales del registrador, los bloqueos de registro, los contactos de emergencia y los procedimientos de cambio de delegación? Un proveedor de DNS de respaldo no sirve si nadie puede cambiar la delegación de forma segura.
Comunicaciones del proveedor:¿Proporciona el proveedor de DNS gestionado detalles de estado al nivel que los clientes necesitan para tomar decisiones, sin exponer los métodos defensivos? ¿Están diseñadas las rutas de soporte al cliente para un evento de impacto simultáneo en el que muchos clientes piden ayuda a la vez?
Exposición a botnets:Para las organizaciones que fabrican, despliegan o gestionan dispositivos conectados, ¿están diseñadas las credenciales predeterminadas, la actualización segura, la identidad del dispositivo, la notificación de vulnerabilidades y el soporte al final de la vida útil para evitar que la flota de dispositivos se convierta en capacidad de DDoS de terceros?
Estas pruebas no son purismo de ingeniería abstracto. Son la forma en que el propietario de un dominio aprende si «tenemos servidores de nombres redundantes» significa una verdadera independencia frente a fallos o simplemente varios nombres de host dentro de la dependencia de un único proveedor.
La lección duradera
DYN no demostró que el DNS gestionado sea malo. Lo contrario se acerca más a la verdad: el DNS gestionado existe porque la disponibilidad del DNS es difícil, especializada y está globalmente expuesta. Muchos clientes serían menos resilientes si se vieran obligados a gestionar su propia infraestructura autoritativa sin experiencia. El incidente demostró que la externalización no borra la arquitectura. Traslada parte de la arquitectura a un proveedor y luego obliga al cliente a decidir si el proveedor es un componente o una dependencia de modo común.
Tampoco Mirai demostró que se pueda culpar únicamente al IoT de consumo de cada interrupción de infraestructura. Demostró que los dispositivos de borde inseguros pueden agruparse hasta formar una fuerza lo bastante grande como para amenazar los servicios centrales. Los hogares y empresas que poseían esos dispositivos no tenían intención de atacar a DYN. Puede que los fabricantes de dispositivos no imaginaran sus productos como piezas de infraestructura de internet. Pero la internet pública los convirtió en partícipes de todos modos.
La memoria responsable del incidente DYN debe, por tanto, estar estratificada. Actores delictivos lanzaron ataques. DYN defendió una plataforma de DNS de alto valor bajo un tráfico hostil extremo y aún así experimentó interrupciones que afectaron a los clientes. Muchos clientes dependían de un único proveedor para el DNS autoritativo y descubrieron que varios servidores de nombres no siempre significan diversidad de proveedores. Los fabricantes y propietarios de dispositivos IoT habían permitido que dispositivos débiles se convirtieran en recursos de ataque. Los gobiernos y organismos de normalización enmarcaron posteriormente la resiliencia frente a botnets como un problema de mercado y de ecosistema, no solo como una cuestión de castigar a un atacante.
La lección práctica es clara: la accesibilidad depende del aburrido plano de control. Una empresa puede construir servidores de aplicaciones redundantes, múltiples nubes, regiones activo-activo y una sofisticada respuesta a incidentes, para luego desaparecer de los navegadores de los usuarios si su dependencia del DNS autoritativo es de un solo proveedor y este no es accesible. La delegación de DNS es poder. Tratarla como una línea de adquisición de bajo riesgo es la receta para que un servicio gestionado se convierta en un fallo de modo común.