Résumé

  • Les sites d'actualité ont perdu des visites qui alimentaient la recherche Yandex. Ailleurs, un client continuait de recevoir des requêtes suspectes par de nouveaux hébergeurs.
  • Chez un client du secteur des jeux d'argent, plusieurs signatures de requêtes ont réapparu via d'autres hébergeurs. Ce constat étaye une migration précise, sans identifier l'opérateur ni décrire tout Internet.

Une rédaction publie pour être lue. Parmi les visiteurs qui l'y aident figurent des programmes : ils viennent chercher les articles pour les moteurs de recherche. Leur disparition n'est donc pas forcément une bonne nouvelle, même si elle fait baisser le compteur des robots.

Après la panne de Yandex, ces visites utiles ont fortement diminué. Mais chez un client du secteur des jeux d'argent, les requêtes suspectes ont trouvé un autre chemin. Dans son analyse du 14 octobre, Cloudflare décrit des caractéristiques identiques réapparues via d'autres hébergeurs lorsque l'ancien réseau a cessé d'envoyer ce flux.

Voilà le décalage : moins de travail pour rendre les articles visibles, sans disparition de toute l'activité qui inquiétait les sites. Le trafic total baisse dans les deux réseaux étudiés, mais cette baisse ne raconte pas à elle seule ce que leurs destinataires ont gagné ou perdu.

Ce que les machines ne venaient plus chercher

Pour un éditeur, le point décisif est la fonction de ces visites. Avant l'incident, environ 90 % du trafic du réseau de recherche Yandex vers les sites d'actualité venait de YandexBot indexant des articles. Moins de passages, c'est moins de collecte et de découverte pour ce moteur. Le rapport ne chiffre toutefois pas une perte de revenus des rédactions.

Cloudflare a isolé ce réseau grâce à son numéro, AS13238. Le cloud porte un autre numéro, AS200350. Ces identifiants, appelés ASN, permettent de distinguer les réseaux qui livrent les requêtes, sans identifier chaque client hébergé dans l'un d'eux.

Sur le réseau de recherche, 99,5 % des requêtes observées étaient automatisées. Parmi ces requêtes de robots, 93,6 % étaient vérifiées par Cloudflare : elles répondaient à ses critères d'identification honnête et de comportement non abusif. L'échantillon comprenait YandexBot, YandexRenderResourcesBot et YandexImages, avec des tâches de collecte et de restitution de pages et d'images. Ces chiffres expliquent pourquoi le trafic perdu correspondait surtout à du travail de recherche, et non à des attaques éliminées.

L'interruption, elle, était bien matérielle. Dans sa déclaration du 9 octobre, Yandex faisait état de graves dégâts à Sasovo après une attaque de drones dans la nuit du 7 au 8, puis d'une atteinte à une partie des installations de Kaluga le 9. La mise à jour du 11 octobre ajoutait l'arrêt du site de Vladimir. Ce récit de l'entreprise explique le contexte des pannes ; il n'attribue pas les activités des utilisateurs du cloud.

Cloudflare mesurait, le 11 octobre, un trafic inférieur de 99 % à sa référence pour le réseau de recherche et de 90 % pour le cloud. Le 13, les deux réseaux restaient entre 86 et 90 % sous leur niveau habituel. Une observation ajoutée au rapport les situait à 85 % de la normale le 14 à 18 heures UTC. Il s'agit de mesures datées, vues depuis Cloudflare, et non d'un bulletin de disponibilité actuel.

Le cloud transportait aussi la vie ordinaire des applications

Dans le cloud, près de 95 % des requêtes notées étaient classées comme provenant de robots, sans requête de robot vérifiée dans l'échantillon. Ce dernier point ne signifie pas que tout était malveillant. Le statut décrit par la documentation de Cloudflare repose sur des critères d'identification et de comportement ; son absence ne condamne pas chaque programme inconnu.

Près des deux tiers des requêtes envoyaient des données à des sites. Les logiciels et les intégrations étaient bien présents, et la majorité du trafic destiné au secteur logiciel recevait HTTP 200 avant comme pendant l'événement. Cette réponse indique une réussite au niveau HTTP, pas une garantie d'innocuité. Elle rappelle néanmoins que des applications ordinaires partageaient cet hébergement.

Cloudflare a aussi observé un recul d'environ 40 % du trafic de robots de cet ASN, de 90 % des sondages de modules WordPress et de 93 % des requêtes reconnues comme des scans. Les blocages appliqués par ses clients au trafic Yandex.Cloud diminuaient de 70 %. Ces séries mesurent des catégories différentes ; leur baisse situe une interruption, sans prouver la disparition du travail qui les produisait.

Le destinataire retrouvait des signes familiers

Un compte client du secteur des jeux d'argent apporte la pièce la plus précise. Presque toutes les requêtes de robots de Yandex.Cloud vers ce secteur se concentraient sur ce compte et ses différents noms d'hôte. Après le 8 octobre, elles ont cessé d'arriver depuis AS200350. Simultanément, d'autres réseaux russes, dont Radist et Selectel, ont livré des requêtes aux mêmes caractéristiques.

Elles partageaient l'empreinte TLS JA4, qui décrit des traits de la connexion chiffrée du client, mais aussi des chemins et des en-têtes inhabituels, ainsi que des chaînes User-Agent personnalisées. C'est leur réunion au même point d'arrivée qui donne du poids à l'hypothèse de migration retenue par Cloudflare. Une empreinte seule n'est pas l'identité d'une personne.

À une échelle plus large, le trafic russe de robots vers les comptes de jeux d'argent de l'échantillon est passé de 167,7 à 170,1 millions de requêtes, soit +1,4 %. Ce total ne correspond pas au seul client précédent. Il ne dit pas non plus que tous les robots se sont déplacés ou que Yandex pilotait l'activité.

La table datée du rapport fournit une autre comparaison : la part automatisée des requêtes HTTP mondiales observées était de 39,4 % du 1er au 6 octobre, puis de 39,5 % les 11 et 13. Au sein des requêtes d'origine russe, elle passait de 50,4 % à 42,2 %, puis à 42,1 %. Les dénominateurs comptent : ce sont des parts de requêtes, pas un recensement des robots ou de leurs opérateurs. La stabilité mondiale ne contredit ni le recul régional ni la continuité d'un flux chez un client.

La vue Radar donne le contexte de mesure. Cloudflare n'observe pas tous les sites ; son analyse ne soutient pas l'affirmation d'une paralysie de la manipulation des réseaux sociaux, tout en réservant la question plus large à des données extérieures à son réseau.

La Note 65 de Lu Heng sert ici de rapprochement éditorial, non de preuve sur l'incident : ce texte sur la gouvernance des numéros Internet privilégie la réalité des systèmes en fonctionnement aux étiquettes. Dans ce cas précis, regarder ce qui parvient encore au site est plus instructif que de s'arrêter au nom de l'hébergeur disparu de sa courbe.