Summary

  • La baisse observée chez Yandex Search correspondait surtout à la disparition de robots d’indexation vérifiés ; l’échantillon Yandex.Cloud réunissait des applications ordinaires et de l’automatisation de type attaque.
  • Des requêtes présentant les mêmes empreintes TLS, chemins, en-têtes et agents utilisateurs sont apparues sur d’autres réseaux russes après l’arrêt du trafic vers un compte client précis. Cela étaye la migration de cette activité observée, sans identifier un opérateur ni décrire tout le trafic Internet.

Un numéro de système autonome indique le réseau d’où vient une requête. À lui seul, il ne dit ni ce qu’elle faisait, ni qui la contrôlait, ni si elle a continué ailleurs. Le récit de Cloudflare sur la perturbation d’octobre autour de Yandex rend cette limite particulièrement visible : les réseaux de recherche et d’hébergement cloud ont tous deux perdu du trafic, mais leurs automatismes n’avaient pas la même fonction et n’ont pas laissé les mêmes indices.

Publié le 14 octobre, le bilan de Cloudflare s’appuie sur Radar et Bot Management, donc sur son propre réseau. Le 11 octobre, le trafic était, selon l’entreprise, inférieur de 99 % à la référence pour Yandex Search (AS13238) et de 90 % pour Yandex.Cloud (AS200350). Les deux réseaux restaient 86 à 90 % sous leur niveau habituel le 13 octobre ; à 18 heures UTC le 14 octobre, Cloudflare les situait à 85 % de la normale. Ce sont des mesures de fournisseur, pas un recensement de l’Internet russe.

La cause doit elle aussi être attribuée avec soin. Yandex a publiquement décrit des dégâts et des interruptions de service dans ses installations de Sasovo, Kaluga et Vladimir ; Cloudflare situe les frappes signalées entre le 7 et le 11 octobre. Ces événements physiques aident à comprendre la perte de capacité. Ils n’identifient pas les responsables des requêtes auparavant hébergées sur ces réseaux. Les déclarations publiques ne montrent pas non plus que Yandex exploitait le trafic repéré chez d’autres hébergeurs.

AS13238 est le cas le plus lisible. Cloudflare a classé 99,5 % des requêtes observées sur cet AS comme automatisées et 93,6 % de ces requêtes de robots comme vérifiées. L’échantillon comprenait YandexBot, YandexRenderResourcesBot et YandexImages, ce qui correspond au crawl et au rendu de pages. Selon Cloudflare, environ 90 % du trafic pré-incident de cet AS vers les sites d’actualité était du YandexBot indexant des articles. La baisse a donc surtout réduit le crawl et la découverte de contenus dans Yandex Search : « robot » ne signifiait pas « attaque ».

L’échantillon Yandex.Cloud était plus hétérogène. Cloudflare indique qu’environ 95 % des requêtes notées étaient des robots, sans requête de robot vérifiée dans l’échantillon. Cela ne rend pas chaque requête malveillante. Près des deux tiers envoyaient des données à des sites ; les logiciels et intégrations occupaient une place importante, et la majorité des requêtes du secteur informatique renvoyaient un code HTTP 200 avant comme pendant la perturbation. Un AS de cloud héberge les charges de ses clients : son étiquette ne vaut pas verdict comportemental.

Cloudflare a toutefois mesuré un recul de catégories précises : le trafic de robots depuis AS200350 baissait d’environ 40 %, le sondage des extensions WordPress de 90 %, les requêtes identifiées comme du scan de 93 % et les blocages de clients visant le trafic Yandex.Cloud de 70 %. Sur son périmètre, l’activité arrivant de cet AS a bien été interrompue. Cela ne répond pas encore à la question de savoir si une opération s’est arrêtée.

Pour y répondre, le rapport suit les requêtes vers le compte d’un client du secteur des jeux d’argent. La quasi-totalité des requêtes de robots Yandex.Cloud de ce segment visait ce compte, sur plusieurs de ses noms d’hôte. Après la perturbation du 8 octobre, le trafic depuis AS200350 vers ce compte est tombé à zéro. Au même moment, Cloudflare a observé chez d’autres hébergeurs russes, dont Radist et Selectel, des requêtes portant la même empreinte TLS JA4, les mêmes chemins et en-têtes peu courants et les mêmes agents utilisateurs personnalisés.

Le trafic russe de robots vers les comptes de jeux d’argent est passé, dans l’échantillon, de 167,7 à 170,1 millions de requêtes, soit +1,4 %.

C’est un indice plus solide qu’une comparaison de courbes nationales : plusieurs caractéristiques des requêtes réapparaissent à la même frontière client alors que l’AS d’origine se tait. Il étaye l’interprétation de Cloudflare selon laquelle cette activité observée a migré. La conclusion reste circonscrite : elle ne démontre ni le déplacement de tous les robots, ni l’identité d’un opérateur, ni l’intention à partir d’une empreinte seule, ni le trafic vers des sites hors réseau Cloudflare. JA4 est un indice de continuité, pas une identité humaine.

Cloudflare précise qu’il faudrait des données extérieures à son réseau pour trancher le lien éventuel avec la manipulation des réseaux sociaux.

Les chiffres agrégés rappellent qu’il faut garder le dénominateur visible. Cloudflare indique que les requêtes automatisées représentaient 39,4 % du volume mondial de requêtes HTTP du 1er au 6 octobre, puis 39,5 % les 11 et 13 octobre. Pour les requêtes d’origine russe, la part est passée de 50,4 % à 42,2 % le 11 octobre, puis 42,1 % le 13. Il s’agit de parts des requêtes observées, pas du nombre absolu de robots ni de personnes. Une part mondiale stable peut coexister avec un recul régional, un effondrement sur un AS et une migration vers un compte précis.

La leçon opérationnelle tient dans cette séparation. La première question d’une panne est de savoir si le chemin du fournisseur est coupé. La suivante est de déterminer si le comportement préoccupant s’est arrêté, s’est déplacé vers une autre destination ou a changé d’hébergeur. Il faut pour cela une référence temporelle et des indices associés aux destinations et aux caractéristiques des requêtes, pas un simple total par AS. Une baisse d’origine peut perturber le référencement et des clients ordinaires du cloud même si un flux de requêtes suspectes persiste ailleurs.

La Note 65 de Heng Lu, « Running-Code Primacy », n’est ici qu’un angle éditorial : juger un système par ce que font réellement ses composants déployés, plutôt que par les étiquettes censées résumer leur comportement. Elle ne constitue pas une preuve sur Yandex, Cloudflare ou l’incident. L’application est limitée : le graphique par AS localise un chemin ; l’analyse des requêtes aide à établir ce qui l’empruntait et ce qui s’est produit après son interruption.

Sources : l’analyse de Cloudflare ; la déclaration de Yandex du 9 octobre ; le communiqué investisseurs de Yandex du 11 octobre ; la documentation Cloudflare sur les robots vérifiés ; la Note 65 de Heng Lu; la vue du trafic de Cloudflare Radar.