Les frappes ukrainiennes contre plusieurs centres de données de Yandex ont bien provoqué d’importantes perturbations en Russie. Mais la chute du trafic observée ne suffit pas à démontrer une paralysie des bots russes sur les réseaux sociaux.
De nos jours, quand un data center s’arrête, les conséquences dépassent vite quelques sites inaccessibles. Entre les 8 et 11 octobre derniers, des frappes ukrainiennes ont touché trois importantes installations de Yandex en Russie, à Sasovo, Kalouga et Vladimir. Le site de Vladimir a été mis à l’arrêt et celui de Kalouga partiellement neutralisé. Yandex a également rencontré des difficultés sur plusieurs de ses services.
Pour les entreprises qui avaient confié leurs données au cloud du groupe russe, le problème s’est parfois prolongé bien après la frappe. Reuters rapporte notamment le cas de l'application de rencontre Pulse incapable de récupérer suffisamment rapidement ses données pour redémarrer ailleurs. Le Kremlin reconnaissait encore le 13 octobre que les perturbations étaient suffisamment importantes pour être suivies au niveau gouvernemental.
Quand le cloud tombe, les applications suivent
Les perturbations ont touché des services très concrets du quotidien pour les Russes, notamment les transports, les livraisons ou, encore, certains outils de paiement. La panne illustre surtout une faiblesse familière du cloud. Une application peut disposer de serveurs de secours et rester malgré tout paralysée si ses données, ses sauvegardes ou certains de ses services indispensables dépendent des mêmes infrastructures.
C’est aussi ce qui rend ces frappes ukrainiennes intéressantes au-delà du seul cas russe. La redondance annoncée par un hébergeur ne dispense donc pas ses clients de vérifier quels scénarios de panne elle couvre, où se trouvent leurs sauvegardes et comment rétablir leur activité, si ces protections deviennent insuffisantes.
Les bots russes n’ont pas tous disparu
Les premières mesures publiées après les frappes ukrainiennes ont pu donner l’impression d’un effondrement massif des bots russes, mais leur portée est plus limitée. Le 11 octobre, Cloudflare a en effet mesuré une chute pouvant atteindre 99% du trafic en provenance de Yandex Search vers son réseau, et 90% pour Yandex Cloud.
Ces baisses étaient certes spectaculaires, mais elles concernaient uniquement le trafic issu de ces infrastructures. Elles ne signifiaient donc pas que l’ensemble des bots ou des activités automatisées venant de Russie avait reculé dans les mêmes proportions.
Dans le cas de Yandex Search, une large partie de ce qui a disparu correspondait simplement aux robots chargés de parcourir et d’indexer le Web. Les données concernant Yandex Cloud étaient plus intéressantes. Cloudflare a constaté une forte baisse des scans de vulnérabilités et d’autres activités considérées comme malveillantes après les frappes. Mais une partie du trafic automatisé ne s’est pas éteinte pour autant.
Des bots déplacés plutôt qu’éteints
Chez un client de Cloudflare spécialisé dans les jeux d’argent, les requêtes ont réapparu chez d’autres hébergeurs russes, notamment Radist et Selectel. Elles conservaient les mêmes empreintes TLS JA4, des chemins inhabituels identiques et les mêmes en-têtes HTTP.
En additionnant l’ensemble des services de jeux d’argent suivis, l'entreprise américaine constate même une légère hausse du trafic automatisé provenant de réseaux russes sur la semaine, de 167,7 à 170,1 millions de requêtes, soit +1,4%. L’activité s’est donc déplacée davantage qu’elle ne s’est effondrée.
Enfin, Cloudflare a également examiné les requêtes automatisées visant les fonctions de publication, de réponse et de « j’aime » d’une plateforme sociale. Leur volume provenant d’adresses IP russes a diminué de 5,7% sur la période, sans variation jugée inhabituelle par l’entreprise. Ces observations ne permettent donc pas de conclure à une paralysie des opérations d’influence, ni de mesurer directement le nombre de faux comptes encore actifs.
L’incendie d’OVHcloud avait déjà montré les failles du système
L’Europe a déjà connu, dans un contexte très différent, un aperçu de ce que provoque la perte brutale d’une grosse infrastructure cloud. Après l’incendie de son site de Strasbourg en mars 2021, OVHcloud avait comptabilisé 120 000 services totalement ou partiellement affectés.
La parade est connue. Les applications critiques doivent pouvoir fonctionner sur plusieurs infrastructures physiquement séparées avec leurs données répliquées et des sauvegardes réellement accessibles en cas de catastrophe. Encore faut-il avoir préparé cette architecture et, surtout, l’avoir testée avant d’en avoir besoin.
Sources : Internazionale, Reuters et Cloudflare
La redondance désigne le fait de dupliquer des composants (serveurs, stockage, réseau) pour continuer à fonctionner malgré une défaillance. Dans la pratique, elle couvre surtout des pannes « locales » (machine en panne, rack, parfois un bâtiment), mais elle peut rester inefficace si plusieurs services critiques partagent la même dépendance (stockage, sauvegardes, contrôle d’accès, DNS interne). Une application peut donc avoir des serveurs de secours tout en restant bloquée si les données ou les mécanismes de restauration sont indisponibles au même endroit. Pour être robuste, il faut vérifier ce que la redondance inclut réellement (zone, région, site) et quels scénarios extrêmes elle ne couvre pas.
La réplication copie les données en continu (ou quasi) vers un autre système pour assurer la continuité de service, avec un objectif de reprise rapide. Une sauvegarde est une copie « point dans le temps », pensée pour restaurer après suppression, corruption ou incident, souvent avec des versions historiques. La réplication peut propager une erreur (chiffrement par ransomware, suppression accidentelle) si elle n’est pas couplée à des snapshots/versions immuables. Les sauvegardes, elles, peuvent être inutilisables si elles sont stockées dans la même infrastructure touchée ou si l’accès/les clés ne sont plus disponibles. Les architectures sérieuses combinent réplication multi-site et backups testés, isolés et réellement restaurables.
Une mesure de Cloudflare reflète le trafic qui transite vers son réseau depuis des sources identifiées (par exemple Yandex Search ou Yandex Cloud), pas l’ensemble d’Internet. Si une plateforme tombe, son trafic peut s’effondrer sans que les acteurs automatisés disparaissent : ils peuvent simplement se déplacer vers d’autres hébergeurs ou d’autres plages IP. En outre, une partie du trafic de Yandex Search correspond à des crawlers légitimes (robots d’indexation) dont l’arrêt n’indique pas une baisse d’activités malveillantes. Pour attribuer un déplacement de bots, on regarde des marqueurs techniques stables (empreintes TLS comme JA4, en-têtes HTTP, chemins de requête), qui peuvent réapparaître ailleurs même quand l’infrastructure d’origine est hors service.
