Del 8 al 11 de octubre de 2026, Yandex perdió tres centros de datos: Sasovo y Vladimir se detuvieron completamente, Kaluga funcionó con degradación. Yandex Cloud entró en modo de emergencia y aconsejó a los clientes activar sus propios planes de recuperación ante desastres. Lo más interesante sucedió después. Cloudflare analizó qué pasó con los bots que habitaban en esta nube y vio: no desaparecieron, sino que en un día se mudaron a otros anfitriones. Y permanecieron reconocibles por la misma huella TLS JA4. Para todos los que se dedican al scraping y la automatización, este es un raro experimento natural en dos cuestiones: qué hacer cuando la infraestructura falla y por qué el cambio de IP y de hosting no cambia la "identidad" del bot.
Qué pasó con Yandex
Según BleepingComputer, Yandex informó sobre el daño a tres centros de datos debido a ataques de drones. Yandex no nombró al culpable; los medios, citando a la BBC, vinculan los ataques con Ucrania. La cronología es la siguiente:
- 8 de octubre — Sasovo (región de Riazán): incendio, el sitio se detuvo completamente;
- 9 de octubre — Kaluga: funcionamiento con degradación, no parada total;
- 11 de octubre — Vladimir: detenido completamente.
En la página de estado de Yandex Cloud, parte de los servicios (consola, API, IAM, bases de datos, S3, Kubernetes) permaneció accesible con problemas de rendimiento, Compute y AI Studio funcionaron parcialmente. La empresa escribió que no podía proporcionar plazos confiables para la recuperación, considera que la configuración restante de recursos es inestable y recomienda a los clientes utilizar planes alternativos de recuperación ante desastres. No había plazos de recuperación ni claridad sobre la posible pérdida de datos en el momento de la publicación de BleepingComputer (12 de octubre).
Lo que vio Cloudflare: el tráfico cayó, los bots no
El 14 de octubre, Cloudflare publicó un análisis del incidente desde su red. Números clave:
- El 11 de octubre, el tráfico de la red de Yandex Search (AS13238) cayó un 99% de lo normal, de Yandex.Cloud (AS200350) — un 90%;
- El 99,5% de las solicitudes de AS13238 antes del incidente eran automáticas, y el 93,6% de las solicitudes de bots eran crawlers verificados de Yandex. Esta red proporcionaba alrededor del 7% de todas las solicitudes de bots desde IP rusas;
- En Yandex.Cloud, alrededor del 95% de las solicitudes evaluadas eran de bots, y ninguna de ellas era verificada. Esto representa alrededor del 2% del tráfico de bots ruso;
- El tráfico de bots de Yandex.Cloud disminuyó aproximadamente un 40%, el escaneo de plugins de WordPress desde esta red — un 90%.
Y luego lo principal. Casi todas las solicitudes de bots de Yandex.Cloud estaban dirigidas a una cuenta de cliente de Cloudflare en el ámbito de los juegos de azar. Justo después de la falla del 8 de octubre, las solicitudes de Yandex.Cloud hacia ella cayeron a cero — y de inmediato aparecieron solicitudes idénticas de redes de otros anfitriones rusos, Radist y Selectel. Con la misma huella TLS JA4, los mismos caminos y encabezados raros y las mismas cadenas de User-Agent no estándar. El resultado de la semana: el tráfico de bots ruso a cuentas de juegos de azar no cayó, sino que aumentó — de 167,7 a 170,1 millones de solicitudes (+1,4%).
La conclusión de Cloudflare se formuló de manera contundente: la infraestructura física es estática, y la automatización maliciosa está diseñada para mudarse. La caída en el volumen de tráfico HTTP muestra el incidente, pero no significa que los bots se detuvieron.
La versión ruidosa y los datos: por qué "los bots se callaron" resultó ser una exageración
Paralelamente, el Centro Ucraniano de Contrarrestar la Desinformación (CPD) afirmó que después del ataque a Sasovo, el número de mensajes de cuentas sospechosas en Facebook y Telegram cayó un 83,6% en un día — de 4,032 a 660. Pero, como analizó TechRadar, ya el 10 de octubre la actividad volvió a 4,585 mensajes, y el 11 de octubre superó el nivel previo al ataque. Cloudflare no encontró un cambio notable: el tráfico de bots desde IP rusas hacia los endpoints de "post, respuesta, like" de una red social solo disminuyó un 5,7%. Graphika tampoco vio pérdida de cuentas activas en las comunidades monitoreadas. La investigadora Renée DiResta en Lawfare calificó la historia de hermosa, pero más parecida a una ficción que a un hecho.
Una lección separada para los analistas: el 8 de octubre, los bancos, el retail, los operadores y los medios de comunicación en toda Rusia fallaron, por lo que cualquier caída en la "actividad" ese día no puede atribuirse sin reservas a los bots. El tráfico agregado puede ser engañoso.
Lección uno: IP y hosting no son la identidad del bot
Cloudflare reconoció la conexión "Yandex.Cloud → Radist/Selectel" no por las direcciones — las direcciones y ASN cambiaron completamente. Lo reconoció por el comportamiento y la huella del cliente:
- JA4 — hash de TLS ClientHello: conjunto de cifrados, extensiones, versiones del protocolo. Describe el programa, no la red. El mismo script de Python en un nuevo servidor da el mismo JA4;
- caminos y encabezados raros — orden y conjunto de encabezados HTTP que no se encuentran en navegadores comunes;
- User-Agent propio — cadena única que en sí misma sirve como etiqueta.
Conclusión práctica para el scraping legal: cambiar de centro de datos o grupo de IP no te convierte en "nuevo" para el anti-bot, si todo el stack del cliente permanece igual. Y viceversa: si tu crawler se presenta honestamente, se comporta con cuidado y no ataca endpoints sensibles, una huella estable no es un problema. El problema surge cuando el stack parece algo que no existe entre los usuarios reales: Chrome declarado con una huella TLS de la biblioteca requests, un UA exótico, encabezados no estándar. Detalles sobre cómo funciona esta capa de detección, lo hemos escrito en el análisis JA4 y el fingerprinting TLS en el scraping.
Observe otro detalle: los bots se mudaron de un centro de datos a otros centros de datos. Para Cloudflare, sigue siendo la misma categoría de ASN de hosting, a la que muchos sitios ya desconfían por adelantado. La red es diferente, pero el perfil de riesgo es el mismo.
Lección dos: la infraestructura debe poder trasladarse en horas
Los atacantes se mudaron en un día porque su automatización es inherentemente portátil. Los equipos honestos que recopilan precios, monitorean resultados o realizan análisis necesitan esa portabilidad no menos. La recomendación de Yandex Cloud "utilice planes alternativos de recuperación ante desastres" es buena solo cuando ya existe un plan. Lista mínima de verificación:
- Código y configuraciones — fuera de la nube. El repositorio, las imágenes de contenedores, las variables de entorno deben estar organizadas de tal manera que se pueda desplegar el scraper en otro anfitrión con un solo comando.
- Segundo anfitrión por adelantado. Cuenta, pago y servidor de prueba con un proveedor alternativo en otra jurisdicción y región. Registrarse y pasar la verificación el día del incidente es demasiado tarde.
- Capa de salida separada de los cálculos. Si las solicitudes a los sitios objetivo van a través de un proveedor de proxy, en lugar de directamente desde la IP del servidor, la mudanza de cálculos no cambia ni la geolocalización, ni el tipo de IP, ni el historial de sesiones. El servidor se puede trasladar, pero para el sitio sigues siendo el mismo cliente.
- Datos y colas — con replicación. Los resultados del scraping y el estado de las tareas se copian en otro almacenamiento, de lo contrario, después de un incidente, tendrás que comenzar el scraping desde cero.
- Proveedor de respaldo — realmente diferente. El hosting de respaldo o el proveedor de proxy no debe ser la misma infraestructura bajo otra marca. Cómo verificar esto en proxies, lo discutimos en el material sobre por qué un proveedor de proxy de respaldo puede ser el mismo grupo.
- Alarma de entrenamiento. Una vez por trimestre, levante el scraper en un sitio de respaldo y ejecute una tarea real. Un plan que nunca se ha ejecutado, generalmente no funciona en la práctica.
Qué tipo de proxy resuelve qué en tal situación
Los proxies no salvan de una mala huella — esto se ve en el ejemplo del análisis de Cloudflare. Sin embargo, desvinculan la "identidad" de tus solicitudes de dónde se ejecuta físicamente el código:
- Proxies residenciales — para sitios donde los ASN de hosting se cortan por adelantado o reciben CAPTCHA. Al trasladar el servidor, la salida permanece en IP domésticas del país necesario.
- Proxies de centros de datos — para API y sitios leales, donde la velocidad y el precio son importantes. También deben mantenerse con un proveedor independiente de tu nube, para que un incidente de hosting no lleve consigo las IP de salida.
Sin embargo, los proxies son solo una capa. Si el stack TLS, los encabezados y el comportamiento de tu cliente se destacan, serán reconocidos en cualquier IP, como reconocieron a los bots que se mudaron a Radist y Selectel.
Qué significa esto para los propietarios de sitios web
Cloudflare también hace la conclusión opuesta: ASN y volumen de tráfico son un indicador poco fiable de un bot. El bloqueo de una "mala" red funciona hasta el primer traslado. Es más confiable observar el comportamiento: huellas JA4 comunes entre diferentes redes, frecuencia anómala de solicitudes y reglas WAF en endpoints sensibles, independientemente de la procedencia de la solicitud. La otra cara de la moneda también existe: el 40,5% de los clientes de Cloudflare respondieron al crawler de Yandex con un código 403, y el tráfico de las redes de Yandex hacia sitios de noticias durante el incidente cayó un 44% — lo que significa que la indexación legítima fue la más afectada.
Conclusión
El incidente de Yandex se convirtió en una prueba viva de dos verdades simples. Primera: la infraestructura puede desaparecer en un día, y gana quien sabe trasladarla en horas, — con el código fuera de la nube, un segundo anfitrión y una capa de salida que no esté atada al servidor. Segunda: para el anti-bot, tú eres tu stack de cliente, no tu IP. Un nuevo centro de datos con el mismo JA4 y el mismo User-Agent es el mismo bot en una nueva dirección. Construye el scraping de tal manera que pueda sobrevivir a un cambio de plataforma y aún así se vea igual de ordenado en cualquier IP.