Resumen
- Para un medio, perder al programa que recoge sus noticias no es una mejora de seguridad: dificulta que el buscador descubra su contenido.
- Para una cuenta de apuestas, perder una fuente de solicitudes sospechosas tampoco significó librarse de ellas. Cloudflare encontró los mismos rasgos llegando desde otros proveedores, sin identificar a su responsable.
El contador marcaba cero, pero las solicitudes sospechosas no habían terminado. En una cuenta de apuestas analizada por Cloudflare, dejaron de llegar desde Yandex.Cloud tras la interrupción del 8 de octubre. Empezaron a aparecer, con los mismos rasgos, desde otros proveedores rusos, entre ellos Radist y Selectel.
Para quien protegía ese sitio, mirar solo al proveedor caído habría sido engañoso. El cambio importante estaba en las peticiones que seguía recibiendo: se parecían a las anteriores, aunque venían de otra red. Cloudflare pudo relacionar esos patrones, no poner nombre a quien los enviaba.
Los medios de noticias tenían un motivo distinto para preocuparse por la misma interrupción. Necesitan que los programas de búsqueda recorran sus páginas: si esos visitantes no pasan, al buscador le cuesta descubrir los artículos. En la red de Yandex Search, eran precisamente esas visitas útiles las que dominaban el tráfico hacia las noticias antes de la caída.
El informe de Cloudflare del 14 de octubre permite ver los dos efectos sin confundirlos. Un medio quiere que su noticia aparezca en la búsqueda; un sitio de apuestas quiere frenar las solicitudes sospechosas. Reducir el número de bots no garantiza ninguna de las dos cosas. El estudio tampoco cuantifica lectores perdidos: mide solicitudes automáticas, no el público que llegó después.
La visita conocida llegó desde otra dirección
Casi todas las solicitudes de bots de Yandex.Cloud hacia el sector de apuestas se concentraban en aquella cuenta, repartidas entre sus nombres de host. Para seguirles la pista, Cloudflare comparó lo que pedían al sitio y cómo se presentaban.
Se repetían rutas y cabeceras poco comunes, además del texto personalizado que identifica al programa, llamado User-Agent. También coincidía una huella TLS JA4: un resumen de las características de su conexión cifrada. Los detalles aparecían juntos ante el mismo destinatario, justo cuando cambiaba la procedencia.
Esa coincidencia sostiene la explicación de que la actividad se trasladó. Una huella, por sí sola, no identifica a una persona. Ni siquiera el conjunto demuestra que Yandex dirigiera aquellas solicitudes, y el caso de una cuenta no describe el destino de todos los bots.
Tampoco hay que atribuir a esa cuenta el total del sector. En una medición más amplia, las solicitudes de bots rusos a cuentas de apuestas de la muestra pasaron de 167,7 millones antes del evento a 170,1 millones durante él, un 1,4% más. Esa cifra describe el conjunto observado de cuentas, no únicamente el caso anterior.
Lo que dejó de llegar también podía ser útil
El contraste estaba en Yandex Search. Cloudflare examinó dos sistemas autónomos: AS13238 para la búsqueda y AS200350 para la nube. Un ASN identifica una red, no las intenciones de cada programa que la utiliza.
Antes del incidente, cerca del 90% de las visitas de esa red a sitios de noticias correspondía a YandexBot indexando artículos. Era trabajo del buscador, no una multitud de lectores ni una medida de cuántas noticias dejaban de leerse.
La automatización dominaba el conjunto de la red de búsqueda: suponía el 99,5% de las solicitudes observadas. Dentro de esas solicitudes de bots, el 93,6% estaba verificado por Cloudflare, que exige identificación transparente y comportamiento no abusivo. Entre los visitantes figuraban YandexBot, YandexRenderResourcesBot y YandexImages, con tareas compatibles con recoger y representar páginas e imágenes.
La caída significaba menos rastreo y descubrimiento de contenidos en Yandex Search. Un editor puede querer que desaparezcan las sondas de vulnerabilidades sin querer perder la visita del buscador. Agrupar ambos fenómenos bajo «menos bots» oculta una diferencia con consecuencias prácticas.
Yandex había comunicado daños y paradas en sus instalaciones. Su declaración del 9 de octubre sitúa el ataque de drones a Sasovo en la noche del 7 al 8, con daños graves y cierre del centro, y el ataque a Kaluga en la mañana del 9, con parte de la infraestructura fuera de servicio. La actualización del 11 añade la parada de Vladímir. Es el relato de la empresa sobre sus centros; no resuelve quién dirigía las cargas alojadas.
Las mediciones de Cloudflare permiten seguir aquella interrupción, no comprobar la disponibilidad de hoy:
| Fecha de la observación | Tráfico respecto al nivel habitual |
|---|---|
| 11 de octubre | Búsqueda: 99% menos. Nube: 90% menos. |
| 13 de octubre | Ambas seguían entre un 86% y un 90% por debajo. |
| 14 de octubre, 18:00 UTC | Una observación posterior situaba el tráfico en el 85% de lo normal. |
Una nube compartida no tiene una sola intención
En Yandex.Cloud, alrededor del 95% de las solicitudes puntuadas eran bots, sin solicitudes de bots verificadas en la muestra. La verificación de Cloudflare aplica criterios específicos de identificación y comportamiento: carecer de ella no convierte automáticamente una aplicación en atacante.
Casi dos tercios de las solicitudes enviaban datos a sitios web. El software y las integraciones tenían peso, y la mayoría del tráfico del sector de software obtenía HTTP 200 antes y durante la interrupción. Una respuesta satisfactoria a nivel HTTP no prueba una intención legítima, pero ayuda a entender que allí también funcionaban aplicaciones corrientes.
Sí se redujeron categorías sospechosas: el tráfico de bots de AS200350 cayó aproximadamente un 40%; las sondas de complementos de WordPress, un 90%; las solicitudes reconocidas como escáneres, un 93%; y los bloqueos de clientes sobre tráfico Yandex.Cloud, un 70%. No son partes sumables de un mismo total. Describen lo que dejó de llegar desde un origen, sin demostrar por sí solas qué ocurrió después con cada operación.
Al ampliar la vista, la proporción mundial de solicitudes automáticas apenas cambió. La tabla por fechas del informe muestra un descenso mucho más claro entre las de origen ruso:
| Período | Bots sobre las solicitudes HTTP globales observadas | Bots sobre las solicitudes HTTP de origen ruso |
|---|---|---|
| Del 1 al 6 de octubre | 39,4% | 50,4% |
| 11 de octubre | 39,5% | 42,2% |
| 13 de octubre | 39,5% | 42,1% |
Cada columna tiene una base de comparación distinta. Ambas cuentan solicitudes, no personas ni operadores. Por eso no hay contradicción entre una cuota mundial casi estable, una caída regional y una cuenta que sigue recibiendo visitas sospechosas.
Radar ofrece el contexto de medición, pero el alcance sigue siendo el de Cloudflare. La empresa no encontró respaldo para la afirmación de que la interrupción paralizó la manipulación en redes sociales; tampoco descarta una relación más amplia sin datos externos a su red.
La Nota 65 de Lu Heng, sobre sistemas en funcionamiento y gobernanza de números de Internet, sirve aquí como analogía editorial, no como prueba del incidente: conviene atender al comportamiento antes que a la etiqueta. En este caso, la comprobación era concreta. Había que mirar qué seguía llegando al sitio. El cero del antiguo proveedor no bastaba.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para el Círculo Estratégico
Círculo Estratégico
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete al Círculo EstratégicoSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance





