Un informe de Cloudflare examina cómo afectaron las interrupciones en dos redes de Yandex a la actividad automatizada que pasa por su infraestructura. Aunque el tráfico global de Yandex cayó de forma abrupta tras los incidentes en sus centros de datos, los datos muestran que buena parte de la actividad maliciosa no desapareció: se reubicó en otros proveedores.
Qué muestran los datos sobre Yandex y su tráfico automatizado
Cloudflare separa la infraestructura de Yandex en dos sistemas autónomos (ASNs) con roles distintos: uno asociado al buscador (encargado del rastreo e indexación) y otro a los servicios en la nube. Ambos ASNs sufrieron caídas importantes de tráfico tras los daños reportados, pero con perfiles de automatización diferentes.
El ASN usado por el buscador registró una proporción muy alta de tráfico clasificado como automatizado, mayoritariamente verificado como rastreadores legítimos de búsqueda. En cambio, el ASN de cloud mostró también una alta tasa de requests automatizadas, pero con poca o ninguna verificación de rastreador legítimo; muchos de esos requests parecían proceder de aplicaciones y scripts (identificados como clientes tipo JavaScript, Python o Go) y estaban dirigidos con frecuencia a servicios de terceros.
Qué cambió y qué no
- La caída en el ASN del buscador se tradujo principalmente en menos indexación: sitios de prensa y publicaciones vieron descender las visitas procedentes del rastreador.
- En el ASN de cloud se observó una reducción en tráfico que, por su perfil, incluía comportamientos de escaneo y sondeo (por ejemplo, sondeos de plugins de WordPress y peticiones identificadas por los sistemas de escaneo), pero no en la misma proporción para todo el tráfico malicioso global.
- En sectores como el de software y el juego online se detectó que el volumen de requests destinado a cuentas concretas cayó en el ASN afectado y reapareció de forma inmediata desde otros proveedores rusos, manteniendo la misma “huella” técnica de las solicitudes.
Por qué la interrupción no supuso el fin de las operaciones maliciosas
Cloudflare explica que una caída en métricas agregadas de tráfico solo confirma que una red quedó degradada o inalcanzable; no revela si la automatización maliciosa quedó desactivada. Al analizar patrones de petición —cabeceras, payloads, fingerprinting del cliente— se apreció que muchos operadores simplemente migraron sus cargas a otros ASNs. En el caso analizado, la suma del tráfico malicioso de origen ruso se mantuvo esencialmente estable durante la semana: la operación continuó desde proveedores alternativos.
Además, la proporción de bloqueos aplicados por clientes de Cloudflare contra el tráfico procedente del ASN de cloud bajó durante la interrupción, lo que sugiere que menos tráfico evidentemente malicioso estaba cruzando el perímetro WAF desde ese ASN, porque los mismos actores estaban reemergiendo desde otros orígenes.
Implicaciones prácticas para administradores y propietarios de web
- No confiar en que una caída de un proveedor o de una red concreta vaya a eliminar la amenaza: los atacantes pueden redistribuir rápidamente sus infraestructuras.
- Priorizar defensas basadas en comportamiento y en controles aplicados a nivel de aplicación (WAF, reglas de bot management y fingerprinting), no solo en listas de bloqueo por ASN o por país.
- Monitorear patrones anómalos en los endpoints clave (por ejemplo, intentos de explotación de plugins, picos en APIs o tráfico repetitivo hacia recursos de pago) y correlacionarlos con la telemetría propia, no solo con métricas públicas agregadas.
- Considerar medidas adicionales como reputación por fingerprint del cliente, rate limiting y verificación reforzada en acciones sensibles (formularios, pagos, APIs) para reducir el impacto si la automatización maliciosa migra a nuevos proveedores.
El caso muestra que derribar una pieza de infraestructura no equivale a desactivar operaciones automatizadas: muchas botnets y servicios de scraping pueden trasladarse entre proveedores con rapidez.
Lee también:
- Detienen en EE. UU. a ejecutivo canadiense vinculado a la investigación sobre ShinyHunters
- IPFire 2.29 Core Update 204 soluciona fallos de DNS en VPN y actualiza el kernel a Linux 6.18.54
Fuente: Cloudflare Blog
