El DDoS de GitHub de 2015 convirtió la inyección en ruta del Grea

Resumen

GitHub declaró que el ataque distribuido de denegación de servicio comenzó aproximadamente a las 02:00 UTC del 26 de marzo de 2015 y que utilizó navegadores de personas ajenas al conflicto para dirigir tráfico contra páginas alojadas en la plataforma. [1]
GreatFire situó el comienzo de una ofensiva previa contra sus propios servicios el 17 de marzo. Más tarde afirmó que JavaScript malicioso había sustituido recursos relacionados con Baidu Analytics y atribuyó la actividad a las autoridades chinas. Baidu negó que sus productos hubieran sido comprometidos. [7][8]
Citizen Lab y sus colaboradores describieron un sistema situado en la ruta de comunicaciones que podía interceptar determinadas solicitudes HTTP sin cifrar, introducir respuestas alternativas y hacer que navegadores fuera de China emitieran peticiones reiteradas. Denominaron a ese sistema Great Cannon. [2][3][4][5]
La evaluación de un probable operador estatal procede de investigaciones técnicas y de atribuciones formuladas por partes identificadas. No equivale a una determinación judicial ni demuestra una cadena individual de mando.
Los navegadores participantes no tenían que estar infectados de manera persistente. Ejecutaban código recibido durante una navegación ordinaria y enviaban conexiones desde sus direcciones reales; no se trataba de reflexión basada en direcciones IP falsificadas ni de la típica red de dispositivos previamente comprometidos. [6]
La validación de direcciones de origen continúa siendo indispensable contra el tráfico falsificado, pero no bloquea por sí sola solicitudes HTTP auténticas generadas por un navegador que ha recibido instrucciones manipuladas. [11][12][13][14][17]
El cifrado autenticado reduce de forma sustancial la posibilidad de sustituir silenciosamente una respuesta en tránsito. No elimina, sin embargo, todos los ataques de denegación de servicio, bloqueos, alteraciones de rutas, compromisos de extremos o abusos de código legítimamente servido. [15][16]
La responsabilidad debe distribuirse según el control efectivo: operadores de la ruta, proveedores de recursos externos, navegadores, GitHub, redes de tránsito y servicios de mitigación controlaban partes diferentes del sistema.
La enseñanza duradera es que los registros administrativos describen la identidad pretendida, mientras que las mediciones del sistema en funcionamiento demuestran qué contenido se entregó, por qué ruta, con qué protección y con qué consecuencias.

Cuando la fuente del tráfico no explica la intención

El ataque sufrido por GitHub en marzo de 2015 fue extraordinario no solo por su efecto sobre la disponibilidad. Su relevancia reside en el modo en que, según la reconstrucción pública, se transformó una actividad cotidiana —cargar un recurso web— en una fuente distribuida de solicitudes contra un tercero.

Una persona podía visitar una página sin intención de contactar con GitHub. El navegador solicitaba un recurso externo mediante HTTP sin cifrar. En algún punto de la ruta, un sistema con capacidad para observar el intercambio podía introducir una respuesta diferente de la esperada. El contenido sustituido incluía instrucciones que hacían que el navegador enviara peticiones repetidas hacia material alojado en GitHub. La conexión resultante procedía de una dirección real y era ejecutada por un navegador normal, pero no expresaba la voluntad del usuario.

Esa separación entre identidad técnica e intención humana altera el análisis. En una reflexión convencional, el atacante falsifica la dirección de la víctima para que un servicio intermediario responda contra ella. En una botnet tradicional, el tráfico procede de equipos que han sido comprometidos y permanecen bajo algún mecanismo de control. El Great Cannon descrito por los investigadores operaba de otro modo: aprovechaba una posición en la red para cambiar temporalmente el código recibido y convertir navegadores no involucrados en emisores de tráfico.

Confundir estos mecanismos conduce a medidas mal orientadas. Una dirección de origen válida no prueba que el usuario quisiera participar. La aparición de un nombre de dominio conocido en la solicitud original no demuestra que el servidor correspondiente entregara los bytes aceptados por el navegador. Y la disponibilidad de una ruta hacia GitHub no garantiza que el contenido recibido antes por el cliente conservara su integridad.

Por eso el episodio debe entenderse como una prueba de responsabilidad de infraestructura. La pregunta decisiva no es únicamente quién figuraba como propietario de una dirección, un dominio o un servicio. Es quién podía observar, alterar, autenticar, ejecutar, filtrar o registrar el tráfico en cada etapa, y qué evidencia podía aportar después.

Lo que permite afirmar el registro público

La declaración de GitHub ofrece el punto de partida más directo para delimitar el incidente. La empresa indicó que el ataque comenzó aproximadamente a las 02:00 UTC del jueves 26 de marzo de 2015. Lo describió como el mayor DDoS de la historia de GitHub hasta ese momento y señaló que combinaba vectores conocidos con técnicas sofisticadas que utilizaban navegadores de personas ajenas al ataque para inundar el servicio. También afirmó que la información disponible le hacía pensar que el objetivo era presionarla para retirar una clase determinada de contenido. [1]

Esa declaración acredita la observación de GitHub como operador de la plataforma afectada. No proporciona una medición completa del volumen, el número exacto de navegadores participantes, el coste económico total, una relación exhaustiva de usuarios afectados ni un instante preciso de recuperación. Tampoco identifica a una persona que hubiera ordenado la operación. La interpretación de GitHub sobre la finalidad de la presión es relevante, pero no convierte la atribución en un hecho judicialmente establecido.

GreatFire aportó otra cronología. La organización afirmó que sus servicios sufrían una gran avalancha de solicitudes desde el 17 de marzo. Posteriormente describió código malicioso que dirigía navegadores hacia contenidos de GreatFire y dos páginas alojadas en GitHub. Según su relato, recursos asociados con Baidu Analytics habían sido sustituidos, y la organización atribuyó los ataques a las autoridades chinas. En esa misma secuencia quedó registrada la negativa de Baidu a que sus productos hubieran sido comprometidos. [7][8]

La diferencia entre esas proposiciones es esencial. Que un navegador recibiera código presentado como un recurso relacionado con Baidu no demuestra que Baidu lo hubiera servido conscientemente ni que sus sistemas de origen hubieran sido penetrados. La hipótesis de una sustitución en ruta explica precisamente cómo un editor legítimo puede parecer la fuente de bytes que niega haber emitido. El relato de GreatFire y la negativa de Baidu deben permanecer juntos porque describen posiciones distintas ante una cuestión técnica todavía más específica: dónde se produjo la alteración.

La investigación de Citizen Lab, el International Computer Science Institute, UC Berkeley, Princeton y otros colaboradores constituye la reconstrucción técnica pública más sólida. Los investigadores distinguieron el Great Cannon del Great Firewall, aunque señalaron similitudes de código y localización en red. Sus mediciones indicaron que el sistema podía seleccionar solicitudes HTTP sin cifrar, interceptarlas e introducir contenido que provocaba nuevas solicitudes desde navegadores situados fuera de China.

El análisis recurrió a observaciones del comportamiento, pruebas desde diferentes puntos y características laterales para acotar la ubicación y naturaleza del sistema. [2][3][4][5]

Ese trabajo respaldó la evaluación de que el operador probablemente estaba vinculado al Gobierno chino. La formulación importa: es una atribución técnica con un nivel de confianza, no una sentencia ni la revelación de una orden individual. El método permite localizar capacidad y comparar hipótesis; no rellena por sí solo todas las lagunas institucionales.

El registro público establece, por tanto, una cadena limitada pero contundente. Existía tráfico web de terceros sin protección autenticada. Los investigadores observaron una capacidad de sustitución selectiva en la ruta. Navegadores que aceptaban el contenido generado enviaban solicitudes contra objetivos designados. GitHub registró un ataque grave contra su disponibilidad. GreatFire y los investigadores formularon atribuciones con bases y perspectivas diferentes. Baidu negó el compromiso de sus productos. Otros detalles operativos permanecen desconocidos.

La manipulación en ruta como núcleo de responsabilidad

La parte decisiva del mecanismo se encuentra entre el recurso solicitado y el contenido que finalmente ejecuta el navegador. Una página puede incluir un script, un contador o un componente analítico alojado por un tercero. Si la solicitud y la respuesta viajan por HTTP sin cifrar, el navegador no recibe una garantía criptográfica de que los bytes provengan del origen esperado y hayan permanecido intactos.

Un sistema situado en la ruta puede observar solicitudes seleccionadas e intentar responder antes que el servidor legítimo o introducir una respuesta que el cliente acepte. El navegador, al interpretar ese contenido como el recurso solicitado, ejecuta sus instrucciones. Las posteriores conexiones contra GitHub son técnicamente válidas: tienen una dirección de origen coherente y atraviesan la pila normal del cliente. Lo anómalo se encuentra en la instrucción recibida, no necesariamente en la dirección de red utilizada para cumplirla.

Conviene distinguir al menos tres identidades. La primera es la identidad nominal del recurso: el nombre de dominio, la resolución DNS y la dirección a la que el navegador pretendía acceder. La segunda es la identidad del emisor real de los bytes aceptados. En HTTP sin protección, ambas identidades pueden divergir sin que el navegador disponga de una prueba criptográfica concluyente. La tercera es la identidad del cliente que después contacta con GitHub. Su dirección demuestra el origen de la conexión, pero no quién creó la instrucción ni si el usuario consintió la acción.

Esta distinción explica por qué el caso no se reduce a un incidente genérico de seguridad informática. La superficie de control era la propia infraestructura de entrega: la posición en el tránsito, la capacidad para modificar respuestas, la ausencia de autenticación del recurso, el comportamiento del navegador y la resiliencia del destino. Si se eliminan de la explicación el tránsito, la integridad de las respuestas y la continuidad del alojamiento, desaparece la tesis principal.

También surge una exigencia de cadena de custodia. Para reconstruir un episodio semejante hay que conservar qué recurso se solicitó, por qué ruta aproximada circuló, qué respuesta llegó a distintos observadores, qué protección de transporte estaba activa, qué diferencias temporales aparecieron entre respuestas y qué hizo el navegador después. Sin esa secuencia, palabras como «ataque», «compromiso» o «interceptación» pueden describir una preocupación legítima, pero no identifican el punto de control.

La primacía del sistema en funcionamiento

El principio de primacía del código en ejecución ofrece aquí una guía particularmente útil. Un registro DNS, una asignación de direcciones, una entrada de directorio, un contrato de alojamiento o una página de estado expresan relaciones previstas. Son documentos valiosos, pero no gobiernan por sí mismos la realidad material de una comunicación.

En 2015, un navegador podía resolver el nombre esperado, enviar la solicitud al destino previsto y, aun así, ejecutar bytes introducidos en el recorrido. La capa administrativa seguía pareciendo coherente mientras el resultado operativo se apartaba de ella. La responsabilidad exige reconciliar las dos capas: qué debía ocurrir según los registros y qué ocurrió realmente según las mediciones.

Esto no rebaja la importancia de DNS, BGP, los registros de direcciones, los certificados o las relaciones de tránsito. Todos ellos ayudan a delimitar expectativas y posibles trayectorias. Pero su valor aumenta cuando pueden relacionarse con capturas, hashes de respuestas, validación criptográfica, tiempos comparables y observaciones desde redes distintas. Un registro de recursos funciona como libro mayor; no constituye por sí solo un veredicto sobre el origen de cada byte.

La perspectiva de la realidad operativa evita también convertir el análisis en propaganda. No es necesario respaldar a GitHub, GreatFire, Baidu, un Gobierno o una política universal de cifrado para formular las preguntas correctas. ¿Quién podía alterar tráfico sin cifrar? ¿Quién podía advertir que dos clientes recibían contenidos diferentes? ¿Qué actor podía autenticar un recurso? ¿Quién controlaba la capacidad del borde, la clasificación de solicitudes o la continuidad del alojamiento? ¿Qué registros eran verificables por terceros?

La legitimidad técnica no proviene simplemente de la cercanía geográfica, de la propiedad declarada de una red o de una autorización imposible de inspeccionar. Proviene de controles observables, registros precisos y capacidad para demostrar lo ocurrido. En el Great Cannon, esa diferencia entre autoridad declarada y comportamiento efectivo no era periférica: era el centro del incidente.

Por qué la validación de origen no bastaba

La validación de direcciones de origen es una defensa fundamental contra ataques que dependen de direcciones falsificadas. Las recomendaciones BCP 38 y posteriores describen filtros destinados a impedir que una red emita tráfico con direcciones que no deberían originarse detrás de una interfaz. Las mejoras basadas en rutas factibles buscan aplicar esa validación en entornos con múltiples caminos sin descartar tráfico legítimo. Las orientaciones de NIST integran estas prácticas con seguridad de encaminamiento y mitigación de DDoS. [12][13][14][17]

Estas medidas limitan la reflexión y la amplificación basadas en suplantación. También mejoran la calidad probatoria de la dirección de origen al reducir una clase conocida de falsificación. Su despliegue sigue siendo una obligación operativa importante.

No obstante, el tráfico descrito en el caso Great Cannon poseía otra propiedad. El navegador establecía conexiones genuinas desde la dirección que le correspondía. Un filtro podía comprobar correctamente que la dirección era topológicamente plausible y permitir el tráfico. La conducta dañina procedía del código que ordenaba las solicitudes, no de un campo IP manipulado.

Eso no vuelve inútil la validación de origen. Un ataque puede combinar varios vectores, y eliminar tráfico falsificado libera capacidad para contener otros. Lo que impide es atribuir a un único control un alcance que no tiene. BCP 38 combate la falsificación; no autentica código web, no verifica la intención del usuario y no distingue por sí solo una solicitud inducida de una navegación voluntaria.

Una matriz responsable de controles debe vincular cada medida con la propiedad que modifica. La validación de origen limita la suplantación. El cifrado autenticado protege la integridad entre extremos autenticados. Las políticas del navegador restringen ejecución y contenido mixto. La clasificación del borde controla consumo y frecuencia. La ingeniería de tráfico y los servicios de limpieza protegen disponibilidad. Ninguna pieza cubre todo el recorrido.

Cifrado autenticado: una barrera importante, no una solución universal

La exposición técnica dependía de recursos entregados sin una garantía autenticada de integridad. TLS crea un canal cifrado y autenticado diseñado para impedir que un intermediario lea, modifique o falsifique mensajes sin ser detectado dentro de su modelo de amenazas. RFC 7258, por su parte, considera la vigilancia generalizada y la subversión del tráfico problemas que el diseño de protocolos debe tratar como ataques. TLS 1.3 sistematizó más tarde propiedades de autenticación e integridad relevantes para este análisis. [15][16]

Cuando un navegador valida correctamente una conexión TLS con el origen previsto, un sistema en ruta no puede sustituir libremente la respuesta y producir un resultado aceptable sin derrotar la autenticación, comprometer un extremo o explotar otra dependencia de confianza. En vez de ejecutarse silenciosamente, una modificación directa debería provocar un fallo verificable. Esa diferencia incrementa de manera considerable el coste de la inyección.

Pero el límite debe quedar igual de claro. HTTPS no impide que se descarten conexiones ni que se bloquee un destino. No evita una denegación volumétrica, una manipulación de rutas, el análisis de patrones, el compromiso del servidor o la distribución de código dañino desde un origen legítimamente autenticado. Tampoco garantiza que todas las dependencias de una página estén protegidas ni corrige automáticamente configuraciones deficientes.

Por tanto, la conclusión no es «un control habría resuelto todo». La afirmación sostenible es más precisa: la autenticación del transporte reduce la oportunidad de sustituir sin aviso una respuesta HTTP en tránsito. Un inventario de seguridad debería mostrar qué scripts podían ejecutarse, qué esquemas de transporte utilizaban, qué certificados se esperaban, cómo se trataba el contenido mixto y qué señales producía un fallo.

GitHub y el límite del operador víctima

GitHub controlaba la infraestructura sometida a presión. Podía clasificar solicitudes, ajustar límites, distribuir capacidad, activar filtros, coordinarse con proveedores de mitigación, proteger repositorios y comunicar el estado del servicio. No podía modificar directamente una respuesta remota alterada en una ruta ajena.

Una publicación anterior de GitHub sobre defensas contra DDoS describió un enfoque por capas que incluía ajustes de la pila de red, límites en balanceadores, equipos de filtrado y colaboración con un proveedor externo. [9] Ese material aporta contexto de diseño, pero no demuestra que cada medida estuviera activa, configurada de la misma forma o resultara eficaz durante marzo de 2015.

Un registro completo del lado de GitHub habría incluido las rutas solicitadas, la distribución de redes de origen, el comportamiento de las conexiones, la carga del borde y de las aplicaciones, los cambios de filtrado, las entregas al proveedor de mitigación, las tasas de error y el efecto para usuarios legítimos. Las fuentes públicas no revelan todos esos detalles, de modo que no es posible reconstruir un volumen completo ni una cronología exacta de recuperación.

La clasificación era especialmente difícil porque las peticiones podían parecer solicitudes HTTP ordinarias. Bloquear de forma agresiva una dirección tras una ráfaga podía perjudicar a usuarios que compartieran red o traducción de direcciones. Los desafíos automáticos podían imponer costes de accesibilidad. Servir repetidamente respuestas caras podía aumentar la carga. Retirar el contenido atacado quizá redujera la presión, pero también permitiría que el atacante influyera en la política de alojamiento mediante coste operativo.

La responsabilidad de GitHub consiste, por ello, en demostrar cómo sus controles protegieron la continuidad y limitaron daños colaterales, no en responder por una manipulación remota que no controlaba. La elección de alojar material no fue la causa de red del ataque. El hecho técnico relevante fue el uso de tráfico inducido para imponer una condición sobre la disponibilidad.

Operadores de ruta: poder técnico y carga probatoria

Una posición en la ruta concede capacidades que no poseen el usuario ni el destino: observar solicitudes sin cifrar, seleccionar flujos y potencialmente introducir respuestas. Cuando una infraestructura dispone de funciones de inspección o alteración, su operador debería poder identificar qué política las autoriza, qué sistemas las ejecutan, qué roles pueden cambiarlas y qué registros muestran su activación.

Una negativa categórica sin datos técnicos es menos útil que registros verificables. Sin embargo, tampoco sería correcto responsabilizar automáticamente a cada red que transportó algún tramo. Las rutas cruzan múltiples dominios administrativos, pueden cambiar durante el incidente y contienen enlaces internos que los colectores públicos no ven. La obligación debe seguir al control efectivo, no a la mera proximidad.

Los datos BGP pueden mostrar qué sistemas autónomos anunciaban y propagaban alcanzabilidad y qué recorridos observaron determinados colectores. No suelen demostrar por sí solos dónde se sustituyó contenido de aplicación. Del mismo modo, una base registral de direcciones identifica una asignación y contactos administrativos, pero no prueba qué equipo generó una respuesta, quién lo controlaba en ese momento ni si participó en una carrera de respuestas.

La interconexión y el tránsito añaden restricciones comerciales a la transparencia, aunque la confidencialidad no elimina la necesidad de trazabilidad interna. Es posible conservar identificadores de interfaces, instantáneas de rutas, cambios de configuración, aprobaciones y hashes de registros sin publicar una topología completa. La responsabilidad exige que la evidencia exista y pueda someterse a una comprobación delimitada.

Esta es la diferencia entre tratar un registro como soberano y tratarlo como libro mayor. El registro señala dónde buscar y quién debería responder. La medición del sistema en funcionamiento determina qué ocurrió.

Editores de recursos externos y dependencias ejecutables

La reconstrucción señala recursos de terceros solicitados mediante HTTP. Eso sitúa a sus editores y a las páginas que los integraban dentro del mapa de control, pero no los convierte automáticamente en participantes conscientes.

El editor controla si ofrece transporte autenticado, cómo gestiona versiones, cachés y cambios, y cómo investiga contenidos divergentes. La página que incorpora el recurso decide si introduce una dependencia sin cifrar capaz de ejecutar código. El navegador aplica políticas de origen, certificados y contenido mixto.

La negativa de Baidu debe permanecer visible en este punto. [8] Si la sustitución ocurrió en la ruta, el origen podía registrar una respuesta legítima mientras algunos clientes recibían otra. La investigación debe comparar registros del servidor, respuestas captadas desde varios lugares, protección del transporte y hashes de contenido. No debe convertir la mera presencia del nombre de Baidu en prueba de colaboración consciente.

Los controles de integridad de subrecursos y las políticas de seguridad de contenido pueden resultar útiles, aunque dependen de una configuración correcta y tienen límites con contenido dinámico. Un inventario de dependencias debería registrar el dominio, el esquema de transporte, el propietario, la función, la capacidad de ejecución, el método de actualización y el comportamiento en caso de fallo. Un script externo merece un nivel de control superior al de un recurso pasivo.

La falta de capacidad del usuario es especialmente importante. Quienes generaron solicitudes no eligieron necesariamente el destino ni comprendieron que su ancho de banda estaba siendo utilizado. Atribuirles responsabilidad principal desplazaría el análisis desde los actores que controlaban la ruta, el recurso, el entorno de ejecución y el borde afectado hacia quienes apenas podían observar el fenómeno.

Navegadores y contención del abuso

El navegador decide qué código ejecutar y qué acciones de red permitir. Aplica la política del mismo origen, valida certificados, trata el contenido mixto y administra solicitudes en segundo plano. Estas decisiones se distribuyen entre estándares, fabricantes, desarrolladores y configuraciones locales.

No existe una regla trivial que separe toda repetición maliciosa del comportamiento legítimo. Las aplicaciones modernas realizan múltiples solicitudes asíncronas, sincronizan datos y cargan recursos de diversos orígenes. Un límite demasiado estricto rompe servicios normales; uno excesivamente permisivo facilita el abuso.

El caso sugiere varias líneas de defensa: transporte autenticado por defecto, restricciones claras al contenido mixto, aislamiento de actividad inesperada, límites adaptativos sobre solicitudes repetitivas y mejores instrumentos para detectar diferencias entre lo servido por un origen y lo recibido por el cliente. La evidencia debe incluir versión del navegador, políticas activas y conducta observada.

Estas medidas no trasladan toda la responsabilidad al fabricante. Un navegador no puede obligar a una red a entregar paquetes, garantizar la honestidad de un origen comprometido ni absorber el tráfico que llega a GitHub. Sí puede reducir la facilidad con la que código introducido de manera silenciosa utiliza al usuario como fuente temporal de solicitudes.

Mitigar sin confundir mecanismos

Las orientaciones generales sobre DDoS abarcan agotamiento de recursos, amplificación, diseño de protocolos y defensa operacional. [11] Sirven para construir resiliencia, pero no demuestran por sí mismas el vector exacto de 2015.

Las solicitudes inducidas exigían protección en varias capas. La red podía distribuir o filtrar tráfico. La capa de transporte podía limitar presión de conexiones. La aplicación podía identificar rutas costosas y patrones repetitivos. El almacenamiento en caché podía reducir trabajo seguro y repetido. Los operadores podían coordinar cambios de ruta y servicios de limpieza.

Cada intervención tenía costes potenciales. El filtrado podía excluir a personas legítimas. Los límites podían castigar redes compartidas. Una migración de tráfico podía saturar otro punto. Los desafíos podían afectar privacidad o accesibilidad. Un registro responsable debía enlazar cada decisión con un indicador, un responsable, un efecto esperado, un resultado observado y una condición de reversión.

Los proveedores de mitigación también custodian evidencia crítica: tráfico antes y después del filtrado, clasificaciones, cambios de rutas y capacidad de limpieza. La contratación externa no elimina la obligación del cliente de comprender las medidas aplicadas. Los acuerdos deberían garantizar acceso a datos del incidente, integridad temporal, conservación suficiente y cooperación técnica posterior.

La respuesta de GitHub no debe calificarse como heroica ni negligente sobre la base de detalles que no son públicos. Lo que puede exigirse es una arquitectura de evidencia capaz de mostrar qué medidas redujeron el daño, qué falsos positivos provocaron y cómo se preservó la continuidad sin sacrificar automáticamente el contenido atacado.

Separar atribución y respuesta operativa

La mitigación no puede esperar a que exista certeza política. GitHub tenía que responder al tráfico y a los efectos sobre el servicio con independencia de quién operara el sistema de inyección. Los investigadores podían analizar después similitudes de código, ubicación, selección de objetivos y comportamiento. Ambas líneas se relacionan, pero no deben confundirse.

Las decisiones operativas pueden basarse en propiedades observables: rutas solicitadas, tasas, distribución de fuentes, encabezados, coste de respuesta y salud del servicio. No necesitan una atribución geopolítica definitiva. A la inversa, que un filtro funcione no demuestra quién patrocinó el ataque.

Citizen Lab aportó valor precisamente porque describió mecanismos y mediciones, no solo una etiqueta política. [2][3] Las publicaciones académicas y técnicas relacionadas añadieron contrastes sobre la conducta de la inyección. [4][5][6] Aun así, la localización técnica y las similitudes no revelan una orden personal ni sustituyen un procedimiento de adjudicación.

GreatFire expresó la atribución de una organización afectada. [7][8] GitHub comunicó su interpretación de la presión ejercida contra contenido alojado. [1] Baidu negó el compromiso de sus productos. Una reconstrucción rigurosa conserva estas voces por separado, sin fabricar un consenso más amplio del que permiten las fuentes.

Evidencia mínima para una respuesta verificable

Un incidente comparable requiere un expediente enlazado que permita comprobar afirmaciones sin conservar indiscriminadamente la actividad privada de los usuarios.

Identidad y tiempo

Debe existir un identificador estable del suceso, acompañado de horas UTC, fuentes de reloj, desviaciones conocidas y retrasos de recopilación. Es necesario distinguir primera observación, confirmación, medidas de mitigación, estabilización y cierre. Los artefactos exportados deben conservar hashes y transformaciones documentadas.

Recurso y transporte

La evidencia debe incluir URL solicitada, esquema, nombre, resolución, origen esperado, certificados cuando correspondan, encabezados, hash del contenido y decisión del navegador. Cuando sea legalmente posible, conviene conservar muestras tanto de la respuesta alterada como de la legítima. El nombre solicitado no debe tratarse como prueba automática de los bytes recibidos.

Observación desde varias redes

Solicitar el mismo recurso desde lugares y proveedores diferentes permite comparar respuestas, tiempos y metadatos. Una divergencia entre puntos de observación reduce el conjunto de posibles lugares de alteración. Si una respuesta anómala llega antes que otra coherente con el origen, la secuencia puede respaldar una hipótesis de carrera, aunque no la convierte automáticamente en certeza.

Ejecución en el navegador

Deben registrarse el comportamiento del script, los destinos contactados, el patrón de repetición, la versión del navegador, las políticas relevantes y la necesidad o ausencia de acción del usuario. La ejecución temporal de código no debe etiquetarse como compromiso persistente sin evidencia.

Telemetría del destino

El operador afectado debe preservar salud del borde y de la aplicación, rutas más solicitadas, medidas de filtrado, coordinación externa, errores, latencia y efectos colaterales. Cada acción debe vincularse con un cambio medido.

Control del operador

Los sistemas capaces de inspeccionar o alterar tráfico requieren registros de autorización, configuración, despliegue, accesos y cambios. Los operadores que nieguen encontrarse en el punto de control deberían poder delimitar su verdadera posición con evidencia, no solo con declaraciones generales.

Atribución y límites

Los hechos observados, las inferencias y los niveles de confianza deben figurar por separado. Toda afirmación externa necesita atribución. Los datos posteriores pueden actualizar una hipótesis, pero no deben reescribir silenciosamente lo que se conocía durante el incidente.

Privacidad y conservación

Las capturas de red y trazas del navegador pueden contener información sensible. La recopilación debe ser proporcional, con acceso restringido, minimización, plazos definidos y capacidad de corregir conclusiones. Proteger la privacidad no implica renunciar a toda evidencia; conservar evidencia no autoriza la retención ilimitada de actividad ajena.

Incentivos y continuidad operacional

Los costes no recaen siempre sobre quien controla la medida preventiva. Un editor puede mantener un recurso heredado sin cifrar mientras el riesgo de sustitución lo soportan usuarios y objetivos. Un operador de tránsito puede carecer de incentivos comerciales para conservar registros detallados. Una plataforma puede pagar por absorber solicitudes generadas por navegadores que no controla.

Los contratos pueden reducir estas asimetrías. Los acuerdos de alojamiento y mitigación pueden exigir acceso a datos, conservación, registro de cambios de ruta y cooperación en pruebas. La adquisición de recursos externos puede exigir entrega autenticada e inventarios de dependencias. Las políticas del navegador pueden hacer más visible el contenido inseguro.

Sin embargo, un contrato sigue siendo un registro de intención. Su cumplimiento se demuestra con el comportamiento real. La misma regla se aplica a una declaración de seguridad, una asignación de direcciones o una política de tránsito: su autoridad depende de que pueda contrastarse con lo que la infraestructura ejecutó.

La continuidad de GitHub tenía además una dimensión de control sobre el alojamiento. Si una campaña puede imponer la retirada de contenido mediante costes de disponibilidad, la resiliencia técnica afecta la autonomía de la plataforma. Esto no vuelve incuestionable cada decisión editorial; significa que alojar el contenido no fue la causa técnica de la inyección y no debe presentarse como tal.

Los episodios posteriores no deben fusionarse con 2015

Informes posteriores describieron nuevas apariciones de herramientas denominadas Great Cannon. [10][18] Esa continuidad nominal justifica invertir en detección duradera, transporte autenticado y cooperación entre operadores. No demuestra que todos los episodios compartieran infraestructura, objetivos, responsables o cadena de mando.

La secuencia de marzo de 2015 tiene fechas, víctimas, observaciones y afirmaciones propias. Los análisis posteriores aportan contexto y muestran que la técnica conservó relevancia, pero no deben fundirse con GitHub en un incidente único. La recurrencia es una razón para mejorar controles, no una licencia para borrar diferencias probatorias.

Un estándar práctico de responsabilidad

El caso permite formular un estándar operativo para infraestructuras expuestas a inyección en ruta y tráfico inducido.

Autenticar todo recurso ejecutable. Los scripts y dependencias capaces de iniciar acciones de red no deberían viajar por canales que permitan sustitución silenciosa.
Medir desde varias redes. Los registros del origen no muestran necesariamente lo que recibió cada cliente. Comparar hashes, tiempos y respuestas desde rutas diferentes ayuda a localizar divergencias.
Asignar control por capas. Deben identificarse responsables distintos para publicación del recurso, DNS, encaminamiento, tránsito, ejecución en navegador, borde del destino, mitigación y comunicación.
Conservar evidencia vinculada a acciones. Cada filtro, cambio de ruta o ajuste de capacidad necesita hora, responsable, motivo, efecto esperado, resultado y criterio de reversión.
Mantener visible la incertidumbre de atribución. Una localización técnica puede sustentar una evaluación firme sin demostrar una orden individual. El lenguaje público debe respetar esa diferencia.
No tratar al usuario enrolado como atacante voluntario. La mitigación debe reducir bloqueos colaterales y reconocer que la dirección real del cliente no revela quién creó la instrucción.
Probar continuidad bajo carga. Los ejercicios deben medir clasificación, capacidad limpia, saturación, falsos positivos y comportamiento de reversión, no limitarse a verificar listas de contacto.
Contrastar registros con ejecución. DNS, certificados, rutas y contratos describen expectativas. Su valor probatorio aparece cuando coinciden —o dejan de coincidir— con la entrega observada.
Separar integridad, disponibilidad y atribución. Un control que protege una propiedad no debe presentarse como solución automática para las otras.
Preservar la identidad de cada incidente. Los acontecimientos posteriores pueden modificar una evaluación, pero no deben confundirse con los hechos y límites de marzo de 2015.

Conclusión

El DDoS contra GitHub en 2015 fue una prueba de responsabilidad de red porque el punto de control descrito por las investigaciones se encontraba entre el recurso que el navegador pretendía obtener y el código que terminó ejecutando. El ataque aprovechó clientes ordinarios, direcciones reales y rutas compartidas. Expuso la insuficiencia de tratar los nombres de dominio, las direcciones de origen o los registros administrativos como descripciones completas del comportamiento de Internet.

La conclusión pública debe mantenerse acotada. GitHub sufrió un gran ataque dirigido contra contenido alojado. GreatFire relató una fase anterior y relacionada desde su posición de víctima. Investigadores observaron un sistema capaz de introducir respuestas en tráfico HTTP seleccionado y formularon una evaluación sobre su operador probable. GreatFire atribuyó la actividad a autoridades chinas; Baidu negó que sus productos hubieran sido comprometidos. No existe en estas fuentes una resolución adjudicada sobre responsabilidad estatal, una cadena personal de mando ni cifras completas de volumen, usuarios, pérdidas o recuperación.

La responsabilidad sigue al control. Los operadores de ruta deben poder demostrar qué sistemas tenían capacidad de alteración y qué registros conservaron. Los editores de recursos deben gestionar dependencias ejecutables y entrega autenticada. Los navegadores deben reducir el enrolamiento silencioso. GitHub y sus socios de mitigación deben relacionar sus decisiones con resultados medidos. Investigadores y autoridades deben distinguir observación, inferencia y atribución.

La regla duradera es exigente: la infraestructura debe juzgarse por el contenido, las rutas y la continuidad que produjo realmente. Los registros indican la autoridad prevista. El sistema en funcionamiento revela si esa autoridad se mantuvo. Cuando un ataque explota la distancia entre ambas capas, la responsabilidad empieza por hacer visible esa distancia.

El DDoS de GitHub de 2015 convirtió la inyección en ruta del Great Cannon en una prueba de responsabilidad de red