El DDoS de Spamhaus de 2013 convirtió la recursión DNS abierta en

Resumen

Entre el 18 y el 27 de marzo de 2013, Spamhaus y después parte de la infraestructura utilizada para protegerlo afrontaron una campaña DDoS cuya evolución debe reconstruirse por fases y puntos de observación, no como un único flujo medido uniformemente. [1][2]
Cloudflare comunicó observaciones de aproximadamente 10, 75–90, 120 y 300 Gbit/s, además de más de 30.000 resolutores participantes; esas cifras pertenecen a su perspectiva operativa y no constituyen una medición universal de Internet. [1][2]
La ruta ejecutable combinó consultas UDP con una dirección de origen falsificada, resolutores recursivos expuestos, respuestas amplificadas y enlaces compartidos de acceso, tránsito, peering o mitigación. [4][5][6]
Un resolutor recursivo atiende consultas de clientes y no debe confundirse con un servidor autoritativo que publica datos de las zonas bajo su responsabilidad; el defecto central fue la recursión accesible a clientes arbitrarios, no la mera existencia de servidores DNS. [4][10]
RFC 5358 y BCP 38/84 ya documentaban antes del incidente dos controles diferentes: restringir la recursión y validar las direcciones de origen en los bordes de red correspondientes. [4][5][6]
La interrupción del sitio web y de redes de apoyo no demuestra que los datos distribuidos de las listas DNSBL de Spamhaus dejaran de estar disponibles en todo el mundo; cada afirmación de continuidad debe identificar servicio, ruta, lugar y periodo de observación. [3]
“Casi rompió Internet” fue un encuadre publicitario, no una constatación de caída global, y el expediente público no permite inventar una interrupción concreta de un punto de intercambio, un autor definitivo, conocimiento previo de cada operador ni un reparto causal completo. [2][3]
La prueba de responsabilidad es operativa: cerrar recursión no prevista, impedir la salida de paquetes con origen falsificado, documentar decisiones de anycast y enrutamiento, conservar evidencias de coordinación y comprobar desde fuera que la reparación persiste. [14][15][16][17][18][19]

1. Un incidente de infraestructura, no una leyenda de volumen

El valor duradero del ataque contra Spamhaus no reside en decidir qué cifra produjo el titular más llamativo. Reside en que hizo visible una cadena distribuida de decisiones técnicas. Un equipo emitía consultas pequeñas con una dirección IP falsa. Una red permitía que esos paquetes salieran. Un resolutor recursivo aceptaba preguntas de clientes que no debía atender. La respuesta, mayor que la consulta, viajaba hacia la dirección de la víctima. Miles de rutas independientes terminaban concentrándose en enlaces compartidos, emplazamientos de mitigación o conexiones de proveedores.

Cada uno de esos pasos era ejecutado por infraestructura real. No dependía de que todas las organizaciones participantes compartieran una intención ni de que conocieran la campaña. Tampoco exigía que un solo resolutor o una sola red de acceso aportara un volumen extraordinario. La potencia aparecía al sumar configuraciones localmente toleradas: recursión abierta, paquetes falsificados, respuestas voluminosas y rutas capaces de transportar la carga hasta un cuello de botella remoto.

Por eso la responsabilidad no puede asignarse únicamente mediante etiquetas institucionales. Ser víctima, proveedor, operador de un resolutor, red de acceso, transportista, punto de intercambio o plataforma de mitigación describe una posición general. La pregunta probatoria es más precisa: ¿qué elemento podía configurar ese operador?, ¿qué comportamiento mostraba durante el periodo relevante?, ¿qué cambio realizó y qué medición demuestra que el cambio sobrevivió a reinicios, conmutaciones y modificaciones de ruta?

El análisis tampoco requiere aprobar o desaprobar el papel de Spamhaus ni su política de listas de bloqueo. La cuestión de infraestructura permanece aunque desaparezca toda valoración sobre la organización atacada. La recursión expuesta seguía siendo una capacidad utilizable por terceros; la falsificación de origen seguía permitiendo dirigir respuestas hacia otra dirección; y los enlaces compartidos seguían absorbiendo un coste generado fuera de la relación entre atacante y objetivo.

Esta perspectiva obliga a separar tres clases de afirmaciones. La primera describe lo observado: tráfico, rutas, servicios inaccesibles y respuestas DNS. La segunda identifica un control técnicamente disponible: listas de acceso, validación de origen, límites de respuesta, capacidad de mitigación o cambios de anuncio. La tercera atribuye responsabilidad jurídica, intención o conocimiento. Las fuentes disponibles respaldan con mayor solidez las dos primeras que la tercera. Confundirlas produciría una narración más rotunda, pero menos verificable.

2. Un registro temporal acotado: del 18 al 27 de marzo

El episodio examinado se limita a la campaña desarrollada entre el 18 y el 27 de marzo de 2013. Cloudflare relató que Spamhaus solicitó protección después de que un ataque saturara su conexión y dejara su sitio web fuera de alcance. En esa fase inicial, Cloudflare informó de unos 10 Gbit/s y, posteriormente, de oleadas de aproximadamente 75 a 90 Gbit/s, atribuidas en gran medida a reflexión mediante resolutores DNS recursivos abiertos. [1]

La secuencia no terminó en la dirección original del cliente protegido. El relato posterior de Cloudflare situó una escalada hacia 120 Gbit/s y describió tráfico que alcanzaba o presionaba partes de la infraestructura de proveedores y superficies relacionadas con la interconexión. En ese contexto apareció también la cifra de 300 Gbit/s. [2] Las cuatro magnitudes —10, 75–90, 120 y 300 Gbit/s— deben permanecer vinculadas a Cloudflare y al punto desde el cual esa empresa dijo observarlas.

No hay base para convertir esas cifras en una única curva homogénea que represente todo Internet. Una medición próxima a la interfaz del cliente no es idéntica a una medición dentro de una red de mitigación. Tampoco lo es una observación en un enlace de tránsito o en una interfaz que conduce hacia redes interconectadas. Pueden referirse a fases, destinos operativos y dominios de fallo diferentes. Sin relojes sincronizados, metodología compartida y datos independientes de todos los caminos relevantes, sumar o comparar esas observaciones como si fueran equivalentes introduciría una precisión inexistente.

El desplazamiento del tráfico también modifica la pregunta sobre el servicio afectado. Al principio, el hecho visible fue la saturación de la conexión de Spamhaus y la inaccesibilidad de su web. Más tarde, la presión descrita alcanzó infraestructura utilizada para transportar o mitigar el tráfico. Eso amplió el conjunto de operadores implicados, pero no prueba que cada proveedor, enlace o punto de intercambio sufriera la misma condición. La presencia de tráfico en una superficie compartida no demuestra por sí sola una caída de toda esa infraestructura.

Spamhaus indicó posteriormente que sus datos distribuidos contra el spam continuaron disponibles mientras eran atacados el sitio web, hosts, socios DNS y otros servicios de apoyo. [3] Esa afirmación permite separar el plano de publicación web del plano distribuido de datos. No autoriza a afirmar que cada usuario, región o ruta tuvo una experiencia perfecta, pero sí impide equiparar automáticamente la caída de una web con la desaparición mundial de las respuestas DNSBL.

La cronología acotada preserva además los límites de atribución. Una comunicación posterior sobre una detención constituye contexto, no una sentencia técnica capaz de identificar el origen de cada paquete o cerrar todas las cuestiones jurídicas. [3] En este análisis no se adjudica identidad definitiva al atacante, no se infiere responsabilidad legal individual y no se atribuye a un operador conocimiento que las fuentes no documentan.

3. Qué midió Cloudflare y qué no puede deducirse

Las tasas comunicadas durante un DDoS siempre pertenecen a un lugar. Pueden representar tráfico recibido en una interfaz, tráfico descartado, una estimación agregada de varios emplazamientos, capacidad solicitada a proveedores o paquetes dirigidos a una dirección concreta. Sin el denominador, el intervalo y la topología, el número conserva valor descriptivo, pero no ofrece una imagen completa del sistema.

Cloudflare situó en su primer relato una fase cercana a 10 Gbit/s y oleadas posteriores de 75 a 90 Gbit/s. También describió el uso de resolutores recursivos expuestos y más de 30.000 participantes observados. [1] En su narración posterior aparecieron 120 Gbit/s y el máximo de 300 Gbit/s dentro de una perspectiva más próxima a proveedores e interconexiones. [2] Son datos relevantes precisamente cuando se mantienen atribuidos; dejan de ser rigurosos si se presentan como un termómetro universal de Internet.

El número de resolutores requiere la misma cautela. “Más de 30.000” representa el conjunto que Cloudflare dijo ver participar en el patrón observado. No es necesariamente un censo de todos los resolutores que respondieron durante toda la campaña. Tampoco revela por sí solo cuántos sistemas autónomos los alojaban, si varias direcciones pertenecían al mismo operador, cuánto tráfico aportó cada uno o qué conocimiento tenían sus responsables. Una dirección que envía una respuesta demuestra comportamiento de red, no intención.

La estimación de amplificación cercana a cien también estaba asociada a una forma concreta de consulta y respuesta descrita por Cloudflare. [1][2] La relación entre bytes enviados por quien inicia la consulta y bytes dirigidos a la víctima depende del nombre solicitado, el tipo de consulta, los datos disponibles, la presencia de extensiones DNS, el transporte, la fragmentación y las políticas del servidor. Por tanto, no debe tratarse como constante de todos los paquetes DNS ni de todos los momentos de la campaña.

La frase según la cual el ataque “casi rompió Internet” forma parte del encuadre publicitario contemporáneo, incluido el titular utilizado por Cloudflare. [2] No equivale a una medición de caída global. Las fuentes no establecen que la red mundial dejara de funcionar, que un intercambio concreto sufriera una interrupción total ni que todos los usuarios experimentaran degradación. Es posible que tráfico de esa escala afectara a terceros en caminos compartidos, pero la magnitud y distribución completa de ese impacto no están documentadas aquí.

Una práctica responsable consiste en adjuntar a cada cifra cinco datos: observador, interfaz o capa, intervalo temporal, método de agregación y límite de inferencia. Para 2013, el expediente público permite conservar las cifras de Cloudflare y explicar su contexto. No permite fabricar un mapa completo de tráfico por AS, determinar un máximo mundial o repartir porcentajes causales entre cada resolutor, red de acceso, tránsito y proveedor.

4. La ruta ejecutable de la reflexión DNS

El mecanismo comenzaba con una falsedad en la cabecera IP. Quien originaba la consulta UDP sustituía su propia dirección por la dirección de Spamhaus o por otra dirección perteneciente a la infraestructura hacia la que deseaba dirigir las respuestas. Como UDP no establece previamente una conexión equivalente a la de TCP, el servidor receptor podía contestar a la dirección declarada sin comprobar mediante un intercambio inicial que allí estuviera realmente el solicitante.

La consulta pequeña llegaba a un resolutor recursivo disponible para clientes arbitrarios. El resolutor realizaba o recuperaba la búsqueda, componía una respuesta y la enviaba a la supuesta fuente. La víctima no había formulado la pregunta, pero recibía la contestación. Repetido a través de muchos resolutores, el mecanismo convertía un flujo saliente relativamente pequeño en un conjunto de respuestas mayores que convergían sobre el objetivo.

Cloudflare informó de consultas vinculadas a datos de ripe.net, de más de 30.000 resolutores participantes y de una relación de amplificación próxima a cien para la forma de consulta y respuesta que observó. [1][2] Esas observaciones describen con claridad el mecanismo, aunque no identifiquen todos los paquetes ni todas las redes de origen. La amplificación explica la asimetría; la distribución explica por qué ninguna fuente individual tenía que sostener por sí sola el volumen final.

La ruta no terminaba necesariamente en un servidor de aplicaciones. Una respuesta reflejada podía entrar por tránsito, peering o un emplazamiento anycast, atravesar un sistema de limpieza y consumir capacidad antes de llegar al servicio protegido. El cuello de botella podía encontrarse en la conexión del cliente, en una interfaz de proveedor, en una ruta hacia un centro de mitigación o en otro recurso compartido. Esto ayuda a entender por qué un ataque iniciado contra una organización podía trasladar costes operativos hacia redes que no participaban en la controversia.

Sin embargo, observar una respuesta reflejada no revela la máquina que generó originalmente la consulta falsa. La dirección visible corresponde a la víctima suplantada. Para acercarse al origen real se necesitan registros en la red desde la cual salió la consulta, telemetría de borde, pruebas de filtrado y correlación temporal. Los registros del resolutor pueden demostrar que recibió la solicitud y qué respuesta produjo, pero normalmente no pueden certificar que la fuente inscrita en el paquete fuera auténtica.

La ruta ejecutable, por tanto, contiene al menos cuatro controles distintos: el equipo que emite la consulta, la red que decide si permite salir una fuente imposible, el resolutor que decide a quién presta recursión y las redes que transportan o mitigan las respuestas. Añadir capacidad en el último tramo puede proteger un servicio, pero no corrige los dos fallos situados aguas arriba. Cerrar un resolutor reduce reflectores, pero no impide otras formas de abuso si la red de origen continúa admitiendo falsificación.

5. DNS recursivo y DNS autoritativo no son lo mismo

Un servidor autoritativo publica información correspondiente a las zonas de las que es responsable. Responde basándose en esa autoridad delegada. Un resolutor recursivo, en cambio, atiende la pregunta de un cliente, consulta la jerarquía DNS cuando es necesario, conserva resultados en caché y devuelve una respuesta resuelta. La arquitectura básica de DNS mantiene conceptualmente separadas esas funciones. [10]

Un mismo equipo o producto puede ejecutar ambas, pero la convivencia no elimina la distinción operacional. Si una máquina autoritativa también acepta recursión de cualquier dirección de Internet, su operador ha creado una segunda superficie. La exposición relevante no es “tener DNS público”, condición necesaria para numerosos servicios, sino permitir que usuarios no previstos utilicen la función recursiva.

La confusión tiene consecuencias para la atribución. Afirmar que “los servidores DNS amplificaron el ataque” resulta demasiado amplio. Puede insinuar que todos los operadores autoritativos comparten el defecto de los resolutores abiertos o que hacer pública una zona equivale a ofrecer recursión. El análisis correcto pregunta qué rol respondió, si el cliente estaba autorizado y qué política produjo el comportamiento.

RFC 5358 ya describía en 2008 el uso de servidores recursivos abiertos como reflectores y recomendaba limitar la recursión a los clientes que debían recibirla. [4] El objetivo no era retirar de Internet las respuestas autoritativas legítimas. Era establecer un límite de servicio: las consultas recursivas destinadas a una población interna, abonados o clientes definidos no debían estar disponibles para cualquier solicitante externo.

La prueba de cumplimiento debe realizarse desde más de una posición. Un chequeo interno confirma que los clientes previstos siguen resolviendo. Una prueba externa comprueba que direcciones no autorizadas no obtienen recursión. También deben examinarse IPv4, IPv6, UDP, TCP, interfaces secundarias, nodos de respaldo y sistemas desplegados durante una conmutación. Un inventario que enumera el servidor principal pero omite una réplica antigua deja una capacidad explotable.

Los registros útiles incluyen la configuración de escucha, las listas de clientes permitidos, la separación de roles cuando exista, las versiones desplegadas y el resultado fechado de pruebas externas. Las métricas de consultas y tamaños de respuesta pueden revelar abuso, pero no sustituyen la frontera de acceso. Un límite de tasa reduce el daño de ciertos patrones; no convierte en adecuada una política que sigue ofreciendo recursión a clientes arbitrarios.

También debe respetarse el límite de control. El operador del resolutor puede decidir a quién responde y cómo limita el servicio, pero no administra necesariamente la red distante que dejó salir el paquete falso. Del mismo modo, la red de acceso puede impedir la falsificación sin poder cambiar las listas de acceso del resolutor remoto. Cuando una misma entidad gestiona ambos componentes, asume ambas tareas, aunque las pruebas de reparación sigan siendo diferentes.

6. La falsificación de origen en los bordes de red

BCP 38, publicado como RFC 2827, asigna un control práctico a la red situada cerca del origen: rechazar el tráfico de un cliente o segmento cuando la dirección de origen no pertenece al conjunto que legítimamente puede aparecer en esa interfaz. [5] Desde la perspectiva del proveedor se habla de filtrado de ingreso en el borde del cliente; para el resto de Internet, el resultado es protección de egreso, porque el paquete falsificado no abandona la red que podía identificarlo.

Ese lugar importa. En el borde de acceso suele existir una relación conocida entre interfaz, cliente y prefijos asignados. Cuanto más se aleja el paquete, más difícil puede resultar decidir si una fuente es imposible únicamente a partir de la topología visible. No es razonable atribuir automáticamente a todo transportista que toca un paquete la misma capacidad probatoria que tenía la red conectada directamente al emisor.

BCP 84, publicado como RFC 3704, adapta la validación a entornos multihomed y a rutas asimétricas. [6] La existencia de asimetría no convierte en inevitable la ausencia de filtrado. Obliga a elegir mecanismos compatibles con la topología: listas por interfaz, comprobaciones de ruta inversa con distintos grados de aceptación u otras políticas capaces de permitir fuentes legítimas sin abrir el paso a direcciones imposibles.

La responsabilidad es compartida, pero no indiferenciada. El cliente debe declarar correctamente qué prefijos puede originar. El proveedor debe incorporar esa información al control del borde, mantenerla cuando cambian las rutas y comprobar que las excepciones no se convierten en agujeros permanentes. Si existe más de un proveedor, cada enlace necesita una política coherente con las rutas y fuentes válidas que puede transportar.

La evidencia debe descender hasta la interfaz. Una declaración general de adhesión a buenas prácticas no demuestra que el filtro estuviera activo en el puerto relevante. Son más útiles los registros de prefijos permitidos, la modalidad de validación, las excepciones por asimetría, los contadores de descarte, las pruebas autorizadas con fuentes inválidas, el historial de cambios y la respuesta dada a avisos de abuso. La dificultad persistente de desplegar validación de origen hace que esa evidencia resulte más necesaria, no menos. [15]

RFC 5358 y BCP 38/84 actúan sobre extremos diferentes de la misma trayectoria. Restringir recursión retira el reflector disponible para usuarios arbitrarios. Validar el origen impide que la consulta falsificada llegue a un reflector. [4][5][6] Ninguno de esos controles reemplaza al otro. Si solo se cierra un resolutor, la red todavía puede exportar tráfico suplantado hacia otros servicios. Si solo se filtra una red de acceso, los resolutores expuestos continúan disponibles para consultas falsificadas emitidas desde otros lugares.

Una reparación auditable debe demostrar el comportamiento después del cambio. No basta con instalar una regla y cerrar el ticket. Cambios de prefijo, nuevas conexiones, migraciones de equipo y conmutaciones pueden alterar la validez de la política. La prueba debe repetirse desde puntos representativos y conservar su fecha, alcance, resultado y limitaciones.

7. Amplificación, tamaño de respuesta y controles complementarios

La reflexión y la amplificación son conceptos relacionados, pero no idénticos. Hay reflexión cuando un servicio envía su respuesta a una víctima cuya dirección fue colocada falsamente en la solicitud. Hay amplificación cuando la respuesta contiene más bytes que el estímulo enviado por quien inicia el abuso. La primera oculta la ruta directa y desvía tráfico; la segunda multiplica el coste soportado por el destino.

Las extensiones de DNS permiten comunicar capacidades y manejar respuestas mayores que las admitidas por el formato UDP original. RFC 6891 describe EDNS(0), una pieza importante para el funcionamiento moderno del protocolo. [11] Su existencia no es, por sí sola, una mala configuración. Sin embargo, el tamaño de las respuestas y la posibilidad de obtenerlas mediante una fuente falsificada influyen en la utilidad de un servicio como amplificador. El control responsable debe preservar las funciones legítimas sin ignorar el abuso de respuestas grandes.

El comportamiento de UDP a través de traductores de direcciones también requiere mantener estados y tiempos adecuados, como documenta RFC 4787. [12] Ese material no identifica culpables en el incidente de Spamhaus. Ayuda a recordar que la ruta real puede atravesar equipos que modifican o mantienen asociaciones de tráfico y que una inferencia sobre el origen o la persistencia no debe basarse en una imagen demasiado simple del transporte.

La disponibilidad de datos en caché plantea otro problema diferente. RFC 8767, posterior al incidente, describe el uso de datos obsoletos para mantener respuestas durante ciertos fallos de actualización. [13] Es una referencia útil para pensar en continuidad de servicio, no un control que pueda atribuirse retrospectivamente a todos los operadores de 2013. Tampoco convierte una respuesta de caché en prueba de que todos los componentes aguas arriba estaban disponibles.

Otros mecanismos posteriores ofrecen defensa en profundidad. DNS Cookies puede proporcionar resistencia adicional frente a algunas interacciones falsificadas cuando los extremos compatibles lo utilizan. [7] La reducción de respuestas a consultas ANY disminuye una forma de respuesta históricamente atractiva para amplificación. [8] La arquitectura de servicios autoritativos grandes incorpora consideraciones de resiliencia, distribución y operación a escala. [9] Ninguna de estas medidas sustituye la necesidad básica de limitar recursión no prevista y bloquear direcciones de origen falsas.

Es esencial respetar la cronología. RFC 5358 y BCP 38/84 son evidencia anterior al ataque de que las categorías fundamentales de control ya estaban documentadas. [4][5][6] RFC 7873, RFC 8482, RFC 8767 y RFC 9199 son referencias posteriores. [7][8][9][13] Sirven para comparar cómo puede verificarse hoy una defensa y para mostrar la evolución técnica; no prueban que cada mecanismo existiera, estuviera desplegado o pudiera exigirse de forma idéntica durante marzo de 2013.

El análisis de tamaños también debe evitar una causalidad excesiva. Una respuesta grande puede contribuir al volumen, pero la capacidad destructiva aparece cuando se combina con falsificación, accesibilidad y repetición distribuida. Concentrarse solo en el factor de amplificación podría ocultar que una respuesta, grande o pequeña, no habría llegado a la víctima si el origen falso se hubiera bloqueado o el resolutor hubiera rechazado al cliente no autorizado.

8. Cómo el descuido local se convierte en una externalidad

Desde dentro de una organización, un resolutor abierto puede parecer un detalle heredado. Atiende algunas consultas externas, consume una cantidad limitada de ancho de banda y quizá no genera alarmas. Una red de acceso que permite paquetes falsificados puede percibir un flujo disperso y de baja tasa. Cada operador observa una fracción. La víctima recibe la suma.

Cloudflare dijo haber visto más de 30.000 resolutores participantes. [1] Aunque cada uno emitiera una parte modesta, la ejecución paralela permitía que miles de respuestas convergieran sobre los mismos destinos. La relación de amplificación observada aumentaba la asimetría: el esfuerzo saliente de quien enviaba las consultas era menor que el volumen recibido por la víctima o por la infraestructura de mitigación.

La externalidad aparece porque el beneficio o ahorro local y el coste remoto recaen en entidades distintas. Dejar un servicio sin restringir puede ahorrar una revisión de configuración. No desplegar validación de origen puede evitar trabajo de inventario y gestión de excepciones. Sin embargo, el ancho de banda, la respuesta de incidentes, la capacidad de limpieza, la coordinación con proveedores y la degradación de rutas son pagados por otras redes.

La distribución también diluye las señales tradicionales. Ningún resolutor tiene que ser indispensable. Retirar uno quizá apenas modifica la oleada. Ninguna red de acceso tiene que originar por sí sola un caudal enorme. Por eso una política basada únicamente en perseguir al “mayor contribuyente” deja intacta la condición estructural. La responsabilidad opera por cobertura: qué porcentaje de la flota de resolutores está cerrado, qué proporción de bordes valida el origen y cuántas excepciones permanecen sin revisar.

Este patrón transforma la configuración en un problema de continuidad colectiva. La exactitud de los registros importa tanto como el tamaño de la red. Un inventario que omite direcciones antiguas, equipos adquiridos o resolutores de respaldo ofrece una imagen tranquilizadora pero falsa. Una base de prefijos desactualizada puede permitir fuentes imposibles o bloquear tráfico legítimo. La reparación requiere conocimiento operativo de los recursos realmente activos.

Los estudios y mediciones posteriores ayudan a examinar la persistencia de defensas incompletas y la dinámica de los ataques DNS. [18][19] Deben utilizarse como instrumentos de comparación y verificación actual, no como un sustituto de los datos de 2013. El hecho de que una exposición siga observándose años después no demuestra automáticamente qué operador estaba expuesto durante el episodio de Spamhaus.

Una métrica responsable incluye denominadores. “Cerramos cien resolutores” dice poco si la organización administra diez mil y no sabe cuántos faltan. “Bloqueamos un millón de paquetes” tampoco demuestra cobertura si no identifica los bordes probados. Son más informativos el porcentaje de activos examinados, las interfaces cubiertas, los protocolos evaluados, las excepciones abiertas y el resultado de una comprobación externa posterior.

9. Anycast, BGP, peering y tránsito

Anycast permite anunciar un mismo servicio desde varios emplazamientos para que BGP seleccione, según las políticas y rutas visibles, el destino al que llegará el tráfico. En un DDoS, esta distribución puede repartir carga y acercar la capacidad de absorción a distintos puntos de entrada. Pero anycast no crea capacidad infinita ni garantiza que la carga se distribuya de manera uniforme.

El resultado depende de anuncios, preferencias locales, relaciones de peering, rutas de tránsito, capacidad física y ubicación de los emisores. Dos sitios anycast pueden recibir cantidades muy distintas porque BGP selecciona caminos según políticas, no según un conocimiento global del espacio libre. Un emplazamiento puede tener servidores disponibles y, aun así, quedar aislado por la saturación de un enlace anterior. Otro puede absorber más tráfico debido a la forma en que se propagan los anuncios.

Cloudflare controlaba su diseño anycast, sus decisiones de mitigación, los cambios de ruta que ejecutaba y la precisión con la que describía sus observaciones. [1][2] Sus proveedores controlaban capacidad, políticas y coordinación en sus propios enlaces. Los pares y operadores de tránsito controlaban sus interfaces y respuestas de congestión. Un punto de intercambio controlaba su infraestructura compartida y sus procedimientos operativos. Estas responsabilidades son reales, pero no autorizan a adjudicar volumen o fallo a una entidad sin evidencia del camino específico.

Cuando el tráfico se desplaza desde una dirección de cliente hacia la infraestructura que sostiene la mitigación, cambia el dominio de fallo. El servicio protegido puede continuar respondiendo en algunos lugares mientras un enlace proveedor sufre presión en otro. Las métricas de la plataforma de mitigación pueden mostrar lo que atravesó sus sistemas, mientras que las de un operador de tránsito describen otra parte. Ambas pueden ser correctas sin representar el mismo universo.

Por eso no debe inventarse una caída de un intercambio. La mención de enlaces orientados a interconexión o de tráfico que afecta a proveedores no demuestra por sí misma que toda una plataforma de intercambio quedara fuera de servicio. [2][16][18] Hacer esa afirmación exigiría telemetría del puerto o de la infraestructura, periodos precisos, síntomas reproducibles y confirmación del operador correspondiente.

La evidencia útil incluye anuncios BGP antes, durante y después del incidente; comunidades y preferencias aplicadas; sitios que anunciaban el prefijo; volúmenes por interfaz; capacidad de tránsito y peering; decisiones de desvío; sesiones modificadas; registros de coordinación; y pruebas de recuperación. Estos datos permiten explicar por qué el tráfico llegó a un lugar determinado sin confundir la ruta seleccionada con una atribución del origen del ataque.

La responsabilidad de continuidad exige además observar las consecuencias de cada mitigación. Retirar un anuncio puede aliviar un enlace y desplazar carga hacia otro. Cambiar la preferencia puede proteger una región y sobrecargar otra. El éxito no se demuestra únicamente porque el servicio reaparezca desde un punto de prueba. Debe comprobarse que la solución no exportó de forma inadvertida un perjuicio evitable a otra parte del sistema.

10. Sitio web, redes de apoyo y datos DNSBL distribuidos

La inaccesibilidad del sitio web de Spamhaus es un hecho concreto descrito en el relato inicial de Cloudflare. [1] Significa que, desde los puntos relevantes, la conexión o el servicio web no podía atender normalmente. No significa por sí misma que todos los productos, datos y funciones de Spamhaus compartieran el mismo destino.

Una web pública entrega páginas, explicaciones, datos de contacto y comunicaciones operativas. Las listas basadas en DNS utilizan consultas y una infraestructura distribuida diferente. Pueden existir servidores autoritativos, réplicas, cachés y rutas que continúan entregando datos aunque el portal web esté interrumpido. Spamhaus señaló que sus datos distribuidos contra el spam permanecieron disponibles mientras el sitio, hosts, socios DNS y servicios de soporte afrontaban ataques. [3]

La conclusión debe mantenerse estrecha. Esa declaración respalda la continuidad general del plano distribuido de datos según Spamhaus. No demuestra que cada usuario obtuviera respuesta sin retraso ni que todas las regiones conservaran idéntico acceso. Tampoco permite descartar interrupciones locales. Del mismo modo, la caída del sitio no permite afirmar que el filtrado mundial de correo dejara de funcionar.

Una evaluación de disponibilidad debería separar al menos cinco objetos: HTTP del sitio público, DNS autoritativo, consultas DNSBL, actualización de datos y servicios auxiliares. Cada uno necesita puntos de prueba, marcas temporales, códigos de respuesta, latencia, frescura y rutas observadas. Un indicador general en verde o rojo no reemplaza esa descomposición.

También importa el lugar de la observación. Un servicio puede responder desde una red y fallar desde otra debido a la selección BGP, congestión o filtrado. La continuidad distribuida no es una propiedad binaria inferible desde un solo monitor. Para sostener una afirmación amplia se requieren sondas en regiones y operadores distintos, además de una definición explícita del servicio evaluado.

Spamhaus controlaba la arquitectura de sus servicios y la precisión de sus comunicaciones de recuperación. Cloudflare controlaba la mitigación de las direcciones y rutas que aceptaba proteger. Los proveedores controlaban los caminos de apoyo. Ninguno de ellos administraba por ese hecho los resolutores remotos o los bordes que permitían fuentes falsificadas. Mantener separadas esas competencias evita atribuir al propietario del servicio defectos situados en redes ajenas.

La continuidad no exculpa el ataque ni minimiza el daño. Una red de datos que sigue respondiendo puede depender de personal sometido a presión, proveedores que cambian rutas y capacidad adicional desplegada con urgencia. La conclusión correcta no es que “nada ocurrió”, sino que el impacto debe localizarse con precisión y que la resiliencia de una capa no prueba la salud de todas las demás.

11. Responsabilidad según el control práctico

El operador de un resolutor controla el software, las interfaces de escucha, los clientes autorizados, la caché, los límites y la separación entre función recursiva y autoritativa. Su evidencia principal es la política de acceso y el comportamiento observado desde redes autorizadas y no autorizadas. Si el resolutor responde recursivamente a cualquier dirección, existe una capacidad concreta que puede repararse.

La red de acceso controla la aceptación del tráfico procedente de clientes. Su obligación técnica se centra en impedir que salgan fuentes incompatibles con la interfaz o los prefijos autorizados. En redes multihomed, el control debe acomodar asimetrías sin abandonar la validación. [5][6] El operador debe poder mostrar la política aplicada al borde concreto, no solo una declaración corporativa.

Un proveedor de tránsito puede ejercer el mismo control cuando conoce la relación entre el cliente y sus prefijos. Más lejos del origen, su capacidad de identificar una fuente falsa puede disminuir. La responsabilidad no se deduce simplemente de que un paquete aparezca en su red. Deben examinarse el tipo de relación, la interfaz, la información disponible y las medidas que el operador podía ejecutar sin destruir tráfico legítimo.

Cloudflare controlaba su plataforma de mitigación, distribución anycast, filtrado, anuncios, coordinación con pares y proveedores, así como la formulación de sus cifras públicas. [1][2] Que fuera víctima indirecta o defensor no elimina esas competencias; tampoco la convierte en responsable de resolutores o redes de origen que no administraba. Su prueba de reparación se relaciona con capacidad, rutas, continuidad y exactitud de medición.

Los operadores de peering e intercambio controlan puertos, políticas y respuesta operativa dentro de su ámbito. No deben recibir una atribución de culpa simplemente porque una ruta plausible pase por su infraestructura. Para afirmar saturación, caída o contribución causal hacen falta datos específicos de interfaz y tiempo. La prudencia es especialmente importante cuando los titulares contemporáneos transforman una presión localizada en una metáfora sobre Internet entero.

Spamhaus controlaba su diseño de servicio, la distribución de datos, sus dependencias y sus comunicaciones. No controlaba resolutores externos ni redes que admitían suplantación. Su responsabilidad de continuidad consiste en diseñar tolerancia a fallos, distinguir servicios afectados, comunicar límites y probar recuperación. Esa tarea es diferente de impedir la reflexión en sistemas de terceros.

Las organizaciones cuyos equipos originaron consultas controlarían esos equipos y su acceso, pero el expediente disponible no presenta una distribución completa ni permite inferir conocimiento individual. No debe suponerse que todo operador de un resolutor sabía que participaba, ni que la ignorancia elimina la obligación de gestionar una configuración expuesta. Conocimiento, capacidad y efecto son elementos distintos.

La responsabilidad más defendible sigue una secuencia: identificar el comportamiento; localizar el componente; determinar quién podía modificarlo; examinar qué estándar o práctica era aplicable en ese momento; verificar el cambio; y conservar las incertidumbres que permanecen. Esta secuencia evita convertir la pertenencia institucional en sustituto de pruebas.

12. Lo que ya existía en 2013 y lo que llegó después

En marzo de 2013, los dos controles fundamentales no eran desconocidos. RFC 5358 llevaba desde 2008 describiendo la reflexión mediante resolutores recursivos abiertos y recomendando limitar el servicio a clientes previstos. [4] BCP 38 llevaba desde 2000 asignando filtrado a los bordes donde podían identificarse fuentes no legítimas. [5] BCP 84 había ampliado ese marco para redes multihomed y rutas asimétricas. [6]

Estos textos demuestran que las categorías de reparación estaban documentadas antes del ataque: cerrar la recursión arbitraria y evitar la exportación de paquetes falsificados. No demuestran quién había desplegado cada medida, qué conocimiento tenía un operador concreto ni qué paquete atravesó qué interfaz. Una norma anterior constituye evidencia de disponibilidad conceptual y operativa; no sustituye la comprobación del sistema en funcionamiento.

Las referencias posteriores deben manejarse con una función distinta. DNS Cookies, las respuestas mínimas a ANY y la arquitectura de servicios autoritativos de gran escala aportan mecanismos y criterios de diseño posteriores. [7][8][9] La posibilidad de servir datos obsoletos bajo condiciones definidas también pertenece a una evolución posterior de la continuidad DNS. [13] No es legítimo proyectar estos elementos hacia atrás como si todos hubieran estado disponibles en la misma forma en 2013.

La documentación operacional de RIPE proporciona criterios contemporáneos para la higiene de enrutamiento y la operación verificable. [14] MANRS examina por qué la validación de direcciones de origen continúa siendo un problema de despliegue. [15] Materiales presentados en RIPE y DNS-OARC documentan la carga operacional de la amplificación y métodos para localizar o corregir resolutores expuestos. [16][17] La investigación académica y las mediciones posteriores permiten comparar patrones, persistencia y eficacia de defensas. [18][19]

El uso correcto de esas fuentes es comparativo. Ayudan a preguntar qué pruebas puede producir hoy un operador: inventarios completos, políticas de recursión, test de spoofing, registros de límites, avisos por AS, coordinación de tránsito y comprobaciones posteriores. No reescriben el expediente del 18 al 27 de marzo. Si un mecanismo fue publicado después, solo puede presentarse como orientación posterior.

Este criterio evita dos errores opuestos. El primero sería absolver toda omisión de 2013 alegando que la defensa moderna aún no existía, aunque RFC 5358 y BCP 38/84 ya documentaban medidas centrales. El segundo sería juzgar a los operadores de 2013 con cada herramienta desarrollada años después. La evaluación justa distingue controles anteriores, información pública disponible, estado real de despliegue y mejoras posteriores.

13. Un programa verificable de reparación

Una reparación sólida comienza con un inventario fechado. Cada resolutor debe asociarse con dirección, interfaz, versión, propietario operativo, función, población de clientes, configuración y dependencia de respaldo. Las direcciones IPv4 e IPv6 deben incluirse. También los nodos de contingencia, equipos heredados y servicios incorporados por adquisiciones. El inventario debe representar lo que realmente escucha en la red, no solo lo que figura en una base administrativa.

Después se prueba la frontera de recursión. Desde una red no autorizada, el sistema no debe prestar el servicio recursivo previsto para clientes internos. Desde una red autorizada, la resolución debe continuar. Las pruebas deben cubrir UDP, TCP, familias de direcciones, interfaces secundarias y escenarios de conmutación. Se conservan hora, origen del test, resultado, configuración y población evaluada.

El segundo bloque verifica el origen. Para cada segmento o cliente se documentan los prefijos permitidos y el mecanismo aplicado. Se realizan pruebas autorizadas con fuentes imposibles para confirmar que los paquetes no abandonan el borde. En multihoming se evalúa que las rutas asimétricas legítimas no queden bloqueadas y que la flexibilidad necesaria no se convierta en aceptación universal. [5][6]

Las excepciones necesitan propietario, justificación, compensación, caducidad y nueva prueba. Una excepción sin fecha de revisión tiende a convertirse en configuración permanente. Una política correcta en el papel puede quedar obsoleta tras una reasignación de prefijos, un cambio de proveedor o una actualización de topología.

La telemetría debe relacionar ambos planos. Los registros de resolutores pueden mostrar tasas de consulta, nombres y tipos relevantes, tamaños de respuesta, truncamiento y acciones de limitación, respetando al mismo tiempo la minimización de datos. La telemetría de borde puede mostrar descartes por interfaz y política. Los registros de flujo y ruta ayudan a localizar por dónde entraron las respuestas y qué enlaces recibieron presión.

Un aviso de abuso útil debe contener intervalo horario en UTC, protocolo, direcciones pertinentes, muestra de paquetes, método de observación, tamaños y un identificador de caso. Una lista desnuda de direcciones obliga al receptor a reconstruir el contexto y dificulta distinguir una exposición actual de un dato antiguo. Los materiales operativos posteriores de RIPE y DNS-OARC ofrecen referencias para mejorar esa coordinación. [16][17][19]

La mitigación anycast requiere su propio registro. Debe quedar constancia de qué sitios anunciaban el servicio, qué rutas cambiaron, dónde apareció congestión, qué capacidad estaba disponible y qué coordinación se realizó con pares o tránsito. La recuperación se prueba desde redes diversas. Si la carga se desplazó, se comprueba que el alivio de un enlace no creó un fallo no observado en otro.

El propietario del servicio separa indicadores. Disponibilidad web, salud del DNS autoritativo, respuestas DNSBL, frescura de datos y funcionamiento de servicios auxiliares no se condensan en una única marca. En un incidente, las comunicaciones deben nombrar el endpoint, el área geográfica, el intervalo y el método de prueba. Esta disciplina habría impedido convertir la inaccesibilidad del sitio de Spamhaus en una afirmación no demostrada sobre el filtrado global.

La reparación se cierra mediante una prueba independiente de la configuración que causó el problema. Si se modificó una lista de acceso, se comprueba desde fuera. Si se añadió filtrado, se intenta emitir una fuente inválida bajo autorización. Si cambió el enrutamiento, se observan anuncios y rutas. Si aumentó capacidad, se verifica el comportamiento del servicio y de los enlaces anteriores. El cierre administrativo sin reproducción técnica no basta.

La cobertura debe publicarse con cuidado: activos examinados, porcentaje de la flota, métodos, fechas, excepciones y zonas ciegas. Las mediciones posteriores y la investigación pueden orientar el muestreo, pero ninguna tendencia general sustituye los datos del operador. [14][15][18][19] La responsabilidad se demuestra en el sistema que realmente ejecuta los paquetes.

14. Límites del expediente y prudencia jurídica

El mecanismo de reflexión está bien respaldado. También lo están las cifras que Cloudflare atribuyó a sus propias observaciones, siempre que conserven ese contexto. [1][2] Lo que no existe es una visión sincronizada de todas las redes que permita declarar un máximo universal, una distribución completa por AS o un porcentaje causal exacto para cada participante.

No está documentado aquí cuánto tráfico aportó cada resolutor. Tampoco cuántos operadores corrigieron la exposición, qué sabían antes de recibir un aviso o cuánto tardaron en actuar. Una configuración abierta demuestra capacidad y comportamiento; no demuestra por sí sola conocimiento del ataque, intención de ayudarlo ni responsabilidad legal.

El impacto sobre terceros permanece incompleto. Es razonable reconocer que una inundación distribuida sobre rutas compartidas puede generar congestión para partes ajenas a la disputa. No es razonable cuantificar ese perjuicio, identificar a todos los afectados o afirmar una caída concreta sin mediciones. Los materiales de presentaciones y estudios posteriores ayudan a entender los riesgos de amplificación, pero no rellenan los huecos de este episodio. [16][18]

También se desconoce la distribución completa de los equipos que generaron las consultas falsificadas. Las respuestas observadas identifican reflectores, no necesariamente los emisores originales. Sin registros próximos al origen, correlación fiable y evidencia adicional, el camino anterior al resolutor permanece oculto.

La notificación posterior de una detención aporta contexto histórico, pero no resuelve por sí sola la autoría técnica de cada fase, ni permite trasladar una imputación o sospecha a una conclusión jurídica general. [3] Este artículo no identifica un atacante definitivo, no asigna responsabilidad penal y no infiere un reparto legal entre organizaciones.

La causalidad también debe dividirse. La recursión expuesta habilitó respuestas a clientes arbitrarios. La falta de validación permitió que las consultas llevaran una fuente falsa. La amplificación aumentó el volumen. El enrutamiento y la interconexión determinaron dónde se concentró. La capacidad y la mitigación influyeron en el resultado de cada servicio. Ningún elemento aislado explica toda la campaña, pero ello no significa que todos compartan la misma responsabilidad.

La forma responsable de presentar la incertidumbre no es eliminar la conclusión. Es ajustar su alcance. Puede afirmarse qué control tenía cada clase de operador y qué evidencia permitiría verificarlo. Puede afirmarse que los fallos independientes se combinaron. No puede afirmarse quién sabía qué, qué red produjo cada fracción, qué intercambio sufrió una caída o qué proporción de daño corresponde legalmente a cada parte.

15. La prueba final de responsabilidad de red

La campaña de Spamhaus convirtió una abstracción en una prueba observable. Un operador de resolutores podía mostrar si la recursión estaba restringida. Una red de acceso podía demostrar si rechazaba fuentes imposibles. Una plataforma de mitigación podía documentar dónde recibía tráfico, cómo distribuía carga y qué rutas cambiaba. Un proveedor podía conservar registros de capacidad y coordinación. El propietario del servicio podía distinguir qué plano permanecía disponible.

Ninguna de esas pruebas depende de una declaración de prestigio, de una etiqueta comunitaria ni de una postura moral sobre las listas de Spamhaus. Depende de configuraciones, paquetes, rutas, inventarios, horarios y comprobaciones externas. La infraestructura obtiene credibilidad cuando sus registros describen con exactitud lo que está funcionando y cuando la continuidad puede verificarse.

La primera pregunta es de capacidad: ¿podía el operador cambiar el tramo relevante? Para el resolutor, la respuesta afecta a clientes permitidos y roles. Para la red de origen, a validación de direcciones. Para Cloudflare, a anycast, mitigación, anuncios y precisión de las mediciones. Para Spamhaus, a arquitectura y comunicación de servicios. Para pares, tránsito e intercambios, a sus propias interfaces y procedimientos, siempre dentro del alcance que demuestren los datos.

La segunda pregunta es de evidencia: ¿puede el operador mostrar el estado anterior, el cambio y el resultado? Un archivo de configuración aislado no prueba que fuera el desplegado. Un contador sin interfaz no sitúa el comportamiento. Un test interno no prueba el cierre externo. Una afirmación de disponibilidad desde un solo lugar no representa todas las rutas. La evidencia adquiere fuerza cuando varias observaciones independientes coinciden.

La tercera pregunta es de continuidad: ¿la reparación preservó el servicio legítimo sin trasladar un coste evitable? Cerrar recursión debe mantener resolución para clientes previstos. La validación de origen debe respetar multihoming legítimo. Un cambio BGP debe evitar crear otro cuello de botella. La mitigación debe comprobarse en el plano web, DNS y de datos, no solo en una interfaz.

La cuarta pregunta es de repetibilidad: ¿el control seguirá funcionando tras un reinicio, una conmutación, una adquisición o un cambio de proveedor? La respuesta exige pruebas periódicas y tras modificaciones relevantes. La configuración de marzo puede dejar de representar la red de abril. Un inventario preciso y una validación recurrente transforman una corrección puntual en responsabilidad operativa.

El incidente no demostró que Internet entero estuviera a punto de romperse. Demostró algo más concreto y útil: muchas omisiones pequeñas podían reunirse en una inundación que ningún participante local percibía en su totalidad. Las cifras de Cloudflare describen la escala vista desde su infraestructura; no autorizan una conclusión mundial. [1][2]

Tampoco demostró que todos los servicios de Spamhaus desaparecieran. La web y redes de apoyo sufrieron interrupciones, mientras la organización afirmó que sus datos distribuidos continuaron disponibles. [3] Esa diferencia es esencial para una evaluación seria de continuidad.

La conclusión final es deliberadamente práctica. Limitar recursión, validar direcciones de origen, controlar respuestas, documentar anycast, conservar cambios BGP, registrar coordinación y verificar desde fuera son acciones observables. Cuando un operador puede realizarlas, la responsabilidad consiste en ejecutarlas y demostrar su eficacia. Cuando las fuentes no permiten atribuir identidad, conocimiento, caída o porcentaje causal, la respuesta correcta es conservar el desconocimiento.

El DDoS de marzo de 2013 sigue siendo relevante porque unió DNS, filtrado de origen, amplificación, interconexión y continuidad en una misma trayectoria ejecutable. La prueba no pregunta quién posee la narrativa más convincente. Pregunta quién controlaba cada paso, qué podía probar y si la reparación impidió que una configuración local siguiera exportando daño hacia el resto de la red.

El DDoS de Spamhaus de 2013 convirtió la recursión DNS abierta en una prueba de responsabilidad de red