Yandex: los bots no cayeron, migraron a otros proveedores

Un apagón de red no apaga a los bots

Entre el 7 y el 11 de octubre, tres instalaciones de Yandex en Rusia (Sasovo, Kaluga y Vladimir) fueron alcanzadas por ataques con drones, y el 11 de octubre el tráfico de la red se derrumbó: 99% por debajo de su línea base en el ASN de Yandex Search (AS13238) y 90% en el de Yandex.Cloud (AS200350), según el análisis de Cloudflare. La lectura rápida que circuló en redes fue que las granjas de bots rusas habían quedado fuera de combate. La lectura correcta, con los datos en la mano, es otra: la automatización maliciosa no se detuvo, se mudó de proveedor.

Para un founder, la diferencia no es semántica. Si tu producto depende de tráfico web, de APIs o de contenido indexado, la lección es que la infraestructura es estática y el ataque es portátil.

Qué pasó exactamente con la red de Yandex

Cloudflare separó dos redes que suelen confundirse bajo la misma marca:

• AS13238 (Yandex Search): el 99,5% de sus requests fueron clasificados como automatizados y el 93,6% de sus bots como verificados. Es decir, casi todo era rastreo legítimo de buscador: YandexBot (78,1% de las muestras), YandexRenderResourcesBot (11,5%) e YandexImages (1,9%).
• AS200350 (Yandex.Cloud): el 95,0% de sus requests puntuados fueron bots, pero ninguno fue verificado. Se comportaban como aplicaciones: casi dos tercios enviaban datos a sitios web, algunos se identificaban como programas en JavaScript, Python o Go.

El impacto también fue distinto. En el ASN de búsqueda, la caída fue casi toda rastreo. En el de cloud, hubo un descenso del 40% en tráfico de bots, con derrumbes muy marcados en categorías de ataque: el sondeo de plugins de WordPress cayó 90% y las requests identificadas como escáneres, 93%. Los bloqueos de clientes de Cloudflare sobre tráfico de Yandex.Cloud bajaron 70%.

A nivel agregado, el tráfico automatizado global no se movió: pasó de 39,4% de todas las requests HTTP en la línea base (1 al 6 de octubre) a 39,5% el 13 de octubre. Lo que sí cayó fue el tráfico automatizado de origen ruso: de 50,4% a 42,1% en el mismo período.

La prueba de que los bots migraron, no murieron

El caso más claro está en el sector del gambling. Casi todas las requests de bots de Yandex.Cloud apuntaban a una sola cuenta de cliente. Justo después de la disrupción del 8 de octubre, ese tráfico cayó a cero. Al mismo tiempo, empezaron a llegar requests idénticas desde otros ASN de hosting ruso, incluidos Radist y Selectel.

La huella era la misma en todos los proveedores: el mismo fingerprint TLS JA4, las mismas rutas de request poco comunes, los mismos headers HTTP y los mismos User-Agent personalizados. El tráfico ruso dirigido a cuentas de gambling quedó prácticamente plano en la semana: de 167,7 millones a 170,1 millones de requests (+1,4%).

Traducción: la operación nunca se detuvo. Movió la carga de trabajo a otro proveedor en cuestión de horas.

Cloudflare también revisó el ángulo de la manipulación en redes sociales y no encontró cambios anómalos: el tráfico total desde IPs de origen ruso bajó 0,6% y el global subió 1,2% en el período. En endpoints de post, reply y like de una plataforma social específica, la caída desde origen ruso fue de 5,7% y el global subió 1,1%. Los datos no respaldan la idea de que los ataques hayan paralizado la manipulación en redes.

Qué dicen otros medios sobre el mismo episodio

Cybernews reportó que Yandex confirmó daños en tres data centers (Sasovo, Vladimir y Kaluga), con las instalaciones de Sasovo y Vladimir completamente apagadas. El medio también recuerda algo clave: las granjas de trolls estatales suelen esconderse detrás de proxies residenciales, dispositivos IoT comprometidos, VPN comerciales y proveedores cloud occidentales, no de la propia red de Yandex.

Hromadske documentó que las disrupciones afectaron a usuarios y empresas en Rusia, Kazajistán, Kirguistán, Uzbekistán, Bielorrusia y Armenia, incluyendo aplicaciones de retail, delivery, banca y transporte. Y Tom's Hardware, vía Yahoo, señaló que el tráfico de Yandex llegó a estar en 0,4% de su máximo de dos semanas, con las zonas cloud del centro de Rusia marcadas como no disponibles.

Para poner el volumen en perspectiva: según ZDNET, el tráfico global de internet creció cerca de 20% en 2025 y alrededor del 30% del tráfico web mundial ya viene de bots. El CEO de Cloudflare, Matthew Prince, dijo en una llamada con inversores recogida por GovInfoSecurity que el tráfico no humano ya superó al humano este año, antes de lo que la compañía proyectaba, y que en cinco años podría ser hasta 1.000 veces mayor.

Qué significa esto para tu startup

El titular fácil (atacaron los data centers y los bots cayeron) es exactamente el tipo de conclusión que un panel de métricas agregadas te invita a sacar. Y es falsa. Tres implicancias concretas:

1. El volumen de tráfico no es una señal de seguridad. Una caída de tráfico desde un ASN solo confirma que esa red dejó de enviar requests. No dice nada sobre si el actor detrás de esos requests sigue activo. Si tu monitoreo se basa en cuánto tráfico recibo, estás midiendo el clima, no el riesgo.
2. La infraestructura es estática; el atacante no. Migrar scripts de un proveedor cloud a otro toma horas. Si tu defensa se apoya en bloquear rangos de IP o ASN específicos, tu protección tiene fecha de vencimiento.
3. El bloqueo por reputación de red tiene techo. En el episodio, los bloqueos de clientes sobre Yandex.Cloud cayeron 70% porque simplemente llegaba menos tráfico malicioso desde ahí. Cuando el atacante cambia de proveedor, ese bloqueo deja de servir.

Acciones concretas que puedes implementar esta semana

• Pasa de listas de IP a comportamiento. Cloudflare recomienda identificar fingerprints compartidos (como JA4), monitorear tasas de request anómalas y aplicar reglas de WAF sobre endpoints sensibles, sin importar de qué red venga la request. Si tu stack lo permite, activa reglas por tasa y por path, no solo por geolocalización o ASN.
• Protege los endpoints que sí importan. El patrón del caso gambling muestra que el atacante concentra el volumen en un objetivo muy específico. Revisa tus endpoints de login, checkout, formularios y APIs públicas: son los que reciben automatización de alto volumen.
• Mide la automatización, no el total. Instrumenta qué porcentaje de tus requests son automatizadas y cuántas devuelven 4xx. En el análisis, la caída de respuestas 4xx en varios verticales fue la pista de que el tráfico de ataque se había ido a otra parte.
• Decide qué bots quieres. No todo bot es enemigo: los crawlers de buscadores traen descubrimiento de contenido. En Publishing y Newspapers, el tráfico desde redes de Yandex cayó 44% y el 40,5% de los clientes de Cloudflare devolvía HTTP 403 porque el dueño del sitio bloqueaba al crawler. Bloquear todo tiene un costo de visibilidad.

Conclusión

El episodio de Yandex deja una lección que aplica a cualquier startup con presencia web: una disrupción de red apaga servidores, no amenazas. La automatización maliciosa está diseñada para moverse, y lo hizo en horas, con la misma huella técnica desde proveedores distintos. La defensa que funciona no es la que persigue redes, sino la que inspecciona comportamiento. Si tu estrategia anti-bot depende de dónde viene el tráfico, ya estás un paso atrás.

Fuentes

• Cloudflare: Yandex outage (fuente original)
• Cybernews: Yandex bot traffic fell, but the troll farm story does not hold
• Hromadske: Yandex bot traffic plunges after Ukrainian strikes
• Yahoo / Tom's Hardware: Russian bot traffic decimated overnight
• ZDNET: The internet in 2025
• GovInfoSecurity: Cloudflare Rides Surge in Bot Traffic and AI Workloads