Anatomia internetowej manipulacji: Yandex, Cloudflare i mit o zamilkłych rosyjskich botach

W dniach 8-9 października doszło do poważnych ataków na infrastrukturę centrów danych rosyjskiego Yandexa. Informacje o uszkodzeniach zostały potwierdzone przez samą spółkę, a awarie infrastruktury chmurowej znalazły odzwierciedlenie w oficjalnych komunikatach technicznych.

Niemal równolegle w mediach społecznościowych zaczęły pojawiać się sugestie, że wraz z problemami Yandexa wyraźnie zmniejszyła się aktywność kont rozpowszechniających prorosyjską narrację. Jako argument zaczęto przywoływać statystyki ruchu sieciowego publikowane przez Cloudflare Radar.

Powstała z tego atrakcyjna historia, łatwa do rozpowszechniania i znakomicie nadająca się do politycznych przepychanek. Wystarczy wykres, odpowiedni komentarz tudzież narracja, że oto przypadkiem wyłączono sporą część rosyjskiej machiny propagandowej. Problem polega niestety na tym, że statystyki ruchu sieciowego nie są automatycznie statystykami operacji dezinformacyjnych. A między jednym a drugim jest jeszcze całkiem sporo infrastruktury, protokołów i wiedzy technicznej.

Co rzeczywiście wydarzyło się z infrastrukturą Yandexa?

Zacznijmy od faktów, ponieważ sam incydent nie budzi większych wątpliwości. W nocy z 7 na 8 października 2026 roku ukraiński atak dronowy spowodował pożar i poważne uszkodzenia centrum danych Yandexa w Sasowie, w obwodzie riazańskim. Obiekt został całkowicie wyłączony.

9 października spółka potwierdziła kolejny atak, tym razem na centrum danych w Kałudze, gdzie część infrastruktury również przestała działać. Konsekwencje były realne. Według oficjalnego rejestru incydentów Yandex Cloud niedostępna stała się strefa ru-central1-b, obsługująca między innymi zasoby obliczeniowe, bazy danych oraz usługi zarządzane. Operator przekierował część obciążenia do pozostałych stref dostępności.

Jeszcze 10 października strefa pozostawała niedostępna, a operator ograniczał możliwość przydzielania nowych zasobów. Zakłócenie zostało również odnotowane przez Cloudflare Radar dla sieci YandexCloud (AS200350). Nie ma więc sensu kwestionować samej awarii. Nastąpiła, była poważna i dotknęła infrastruktury wykorzystywanej przez zewnętrzne aplikacje oraz usługi.

Pozostaje jednak pytanie - jaki ma to związek z kontami publikującymi komentarze na X, Facebooku czy na przykład "polskim reddicie" - Wykopie? Na razie żadnego takiego związku nie udowodniono.

YandexBot to nie rosyjski troll z kontem na X-ie.

Podstawowym problemem internetowej narracji jest nieprecyzyjne posługiwanie się słowem "bot". W terminologii technicznej określenie to obejmuje rozmaite systemy automatyczne wykonujące zupełnie różne zadania.

YandexBot jest robotem indeksującym wyszukiwarki Yandex. Jego zadaniem jest odwiedzanie stron internetowych, pobieranie ich zawartości i dostarczanie danych wykorzystywanych przez mechanizmy wyszukiwania - generalnie działa podobnie do Googlebota czy Bingbota.

Co istotne, Cloudflare Radar identyfikuje YandexBota jako odrębnego, zweryfikowanego robota, przypisanego do kategorii wyszukiwarek. Zupełnie inną kategorię stanowią automatyczne konta społecznościowe wykorzystywane do publikowania komentarzy, rozpowszechniania określonych narracji czy sztucznego zwiększania zasięgów.

Takie systemy mogą wykorzystywać interfejsy API, automatyzację przeglądarek, narzędzia do zarządzania kontami, harmonogramy publikacji oraz rozmaite mechanizmy omijania detekcji. Do tego dochodzą ludzie obsługujący konta ręcznie, ponieważ nie każda operacja wpływu polega na automatycznym generowaniu komentarzy.

Wspólnym mianownikiem jest automatyzacja lub koordynacja działań, a nie identyczna architektura techniczna. Dlatego nawet potwierdzony spadek aktywności YandexBota nie byłby dowodem na spadek aktywności rosyjskich farm trolli. Indeksowanie stron internetowych i prowadzenie operacji wpływu to dwa różne procesy. Nie oznacza to, że nie mogą współdzielić jakichś elementów infrastruktury. Oznacza jedynie, że nie wolno zakładać takiej zależności bez dowodów.

Cloudflare Radar nie jest wykrywaczem rosyjskiej propagandy!

Tu dochodzimy do najważniejszej części całego nieporozumienia. Cloudflare Radar udostępnia statystyki ruchu sieciowego, w tym dane dotyczące systemów autonomicznych, żądań HTTP, ruchu automatycznego oraz zweryfikowanych robotów internetowych. W dyskusji o Yandexie należy rozróżnić przynajmniej trzy źródła danych:

• AS13238 (YANDEX) -> statystyki ruchu pochodzącego z sieci autonomicznej Yandexa.

• AS200350 (YandexCloud) -> dane dotyczące infrastruktury sieciowej usług chmurowych Yandexa.

• YandexBot -> statystyki żądań generowanych przez konkretnego, zweryfikowanego robota indeksującego.

Nie są to trzy nazwy tej samej metryki. W szczególności wykres Bot vs. Human dla określonego ASN nie przedstawia liczby kont społecznościowych ani liczby komentarzy opublikowanych przez domniemane farmy trolli. Pokazuje klasyfikację ruchu HTTP obserwowanego przez Cloudflare. W przypadku tego wykresu chodzi o żądania dotyczące treści HTML.

Mechanizmy takie jak Cloudflare Bot Management wykorzystują heurystyki, analizę właściwości żądań i uczenie maszynowe do określania prawdopodobieństwa automatyzacji ruchu. Nie identyfikują natomiast przekonań politycznych operatora, jego pracodawcy, przynależności organizacyjnej ani celu prowadzonej kampanii informacyjnej. Bot Score nie jest wskaźnikiem rosyjskiej dezinformacji.

Dodatkowo Cloudflare obserwuje ruch przechodzący przez własną infrastrukturę, a nie całość aktywności internetowej każdego podmiotu. Jeżeli żądanie nie przechodzi przez sieć Cloudflare, nie musi być widoczne w analizowanej metryce. Tym bardziej nie ma podstaw, aby na podstawie takiego wykresu ustalać, ilu użytkowników X czy Wykopu przestało publikować komentarze. To nie jest drobna nieścisłość - to błąd interpretacji samego źródła danych.

Co naprawdę pokazują wykresy po atakach?

W tym miejscu warto oddzielić potwierdzone zdarzenia od interpretacji. Cloudflare odnotował zakłócenie dotyczące YandexCloud AS200350, związane z wyłączeniem centrum danych w Sasowie. Jest to zgodne z informacjami pochodzącymi bezpośrednio od operatora infrastruktury. Nie stanowi to jednak dowodu na analogiczny spadek aktywności wszystkich usług Yandexa.

W szczególności nie wykazano, że wskutek ataków nastąpił porównywalny spadek ruchu w AS13238 albo żądań generowanych przez YandexBota. Dostępne, zweryfikowane informacje nie pozwalają również przypisać konkretnego ograniczenia aktywności crawlera do uszkodzonych serwerów w Sasowie czy Kałudze.

Yandex Cloud potwierdził niedostępność ru-central1-b, ale nie opublikował szczegółowej mapy zależności pozwalającej ustalić, które instancje systemu indeksowania korzystały z dotkniętej awarią infrastruktury. Sama możliwość techniczna nie jest jeszcze dowodem. Podobnie należy traktować wykresy z Cloudflare Radar.

Krótkotrwałe zmiany aktywności botów są normalnym zjawiskiem w infrastrukturze internetowej. Na natężenie ruchu wpływają między innymi harmonogramy indeksowania, polityki ograniczania liczby żądań, dostępność serwerów, regionalne zmiany trasowania i automatyczne mechanizmy zarządzania obciążeniem.

Aby wykazać nietypowy spadek, należałoby zestawić wartości sprzed incydentu i po nim, porównać analogiczne przedziały dobowe oraz zbadać historyczną zmienność danej metryki. Na chwilę obecną nie przedstawiono dotąd wiarygodnego zestawienia liczbowego, które potwierdzałoby istotne załamanie aktywności rosyjskich operacji dezinformacyjnych wskutek ataków na Yandexa.

Nie można też uczciwie twierdzić, że każde zaobserwowane odchylenie jest wyłącznie naturalną fluktuacją. Wymagałoby to dokładnie takiej samej analizy. Weryfikacja nie polega na zastąpieniu jednej nieudowodnionej tezy drugą.

Farmy trolli nie muszą korzystać z rosyjskich adresów IP.

Kolejnym problemem jest uproszczone wyobrażenie o sposobie funkcjonowania operacji dezinformacyjnych. Profesjonalne operacje wpływu nie sprowadzają się do kilkudziesięciu skryptów uruchomionych na jednym serwerze w Moskwie, z którego wszystkie konta logują się do serwisów społecznościowych. Ukrywanie pochodzenia operatorów i utrudnianie wykrywania skoordynowanych działań stanowi istotną część ich bezpieczeństwa operacyjnego, czyli Operational Security (OpSec).

Stosowane techniki mogą obejmować komercyjne sieci proxy, w tym residential proxies, VPN-y, rozproszone serwery VPS oraz infrastrukturę należącą do różnych dostawców i zlokalizowaną w wielu państwach. Równie istotna jest warstwa behawioralna. Operatorzy mogą różnicować harmonogramy aktywności, język, styl wypowiedzi, tematykę publikacji i sposób prowadzenia interakcji. Znaczenie mają tutaj również techniki stylometryczne, pozwalające analizować charakterystyczne cechy autorstwa tekstów, a także działania mające utrudnić taką analizę.

Nie jest to wyłącznie teoretyczny model. Meta od lat dokumentuje skoordynowane sieci nieautentycznych kont (Coordinated Inauthentic Behavior), w tym operacje pochodzące z Rosji. Z kolei raporty Europejskiej Służby Działań Zewnętrznych (EEAS) opisują złożony charakter rosyjskich operacji manipulowania informacją, wykorzystujących wiele platform, podmiotów pośredniczących i kanałów dystrybucji.

Oczywiście nie każda taka operacja musi wykorzystywać identyczny zestaw narzędzi. Nie istnieje jedna uniwersalna architektura farm trolli. Jednak rozproszenie infrastruktury i maskowanie pochodzenia ruchu są dobrze znanymi praktykami w tego rodzaju działalności. Próba identyfikowania wszystkich rosyjskich kont dezinformacyjnych wyłącznie na podstawie ruchu z oficjalnych sieci Yandexa byłaby więc metodologicznie wadliwa.

Istnieje też drugie zastrzeżenie - zewnętrzny adres IP nie przesądza o lokalizacji infrastruktury sterującej. System korzystający z zagranicznych proxy może nadal posiadać centralne komponenty w jednym centrum danych. Dlatego nie da się z góry wykluczyć zależności infrastrukturalnych pomiędzy określonymi operacjami informacyjnymi a usługami Yandexa. Trzeba je jednak wykazać, a nie zgadywać.

Korelacja czasowa to jeszcze nie związek przyczynowo-skutkowy.

Załóżmy na chwilę, że po opisywanym tutaj ataku rzeczywiście zmalała aktywność pewnej grupy kont politycznych. Co wynikałoby z takiej obserwacji? Przede wszystkim to, że w określonym przedziale czasu opublikowano mniej treści. Aby ustalić przyczynę, należałoby najpierw zidentyfikować konta, wykazać ich wzajemną koordynację, przeanalizować historię aktywności oraz sprawdzić, czy spadek nie występował także w grupach kontrolnych.

Dopiero wtedy można byłoby szukać zależności z awarią konkretnych usług, a bez takiej analizy otrzymujemy jedynie dwa zdarzenia występujące w podobnym czasie. Atak na centrum danych i cisza na kilku profilach mogą być ze sobą powiązane. Mogą też nie mieć ze sobą nic wspólnego. Sam fakt następstwa czasowego niczego nie rozstrzyga.

To klasyczny problem mylenia korelacji z przyczynowością, znany zarówno ze statystyki, jak i analizy incydentów bezpieczeństwa. W cyberbezpieczeństwie nazywanie takiej korelacji dowodem atrybucji byłoby wyjątkowo ryzykowne. W mediach społecznościowych najwyraźniej wystarczy odpowiednio opisany wykres.

Od wykresu do politycznej sensacji.

Mechanizm powstawania podobnych narracji jest dość prosty. Najpierw pojawia się rzeczywiste zdarzenie techniczne: awaria, atak lub zakłócenie ruchu. Następnie ktoś znajduje wykres, który pozornie pasuje do oczekiwanej interpretacji. Kolejny użytkownik dopisuje do niego własne obserwacje dotyczące aktywności internetowych komentatorów. Wreszcie powstaje sugestia, że infrastruktura konkretnej firmy obsługiwała znaczną część zagranicznej operacji propagandowej.

Na każdym kolejnym etapie interpretacja zaczyna funkcjonować coraz bardziej jak ustalony fakt, mimo że nie przedstawiono dowodu potwierdzającego kluczowy związek. Nie trzeba przy tym fałszować samego wykresu. Wystarczy przypisać mu znaczenie, którego nie posiada.

Jest to szczególnie problematyczne w przypadku narzędzi analitycznych takich jak Cloudflare Radar, ponieważ ich techniczny charakter nadaje internetowym interpretacjom pozory wiarygodności. Wykres z profesjonalnej platformy pomiarowej wygląda przekonująco. Nie oznacza to jednak, że komentarz zamieszczony pod nim jest równie profesjonalny. Wiarygodność narzędzia nie przenosi się automatycznie na wiarygodność osoby interpretującej jego wyniki.

Yandex ucierpiał. Dowodów na zamilknięcie farm trolli nadal brak.

Ataki na centra danych Yandexa faktycznie miały miejsce - potwierdzono poważne uszkodzenia infrastruktury, niedostępność części usług i zakłócenia funkcjonowania Yandex Cloud. Nie potwierdzono natomiast, że wskutek tych ataków doszło do istotnego ograniczenia aktywności rosyjskich farm trolli na X, Facebooku czy Wykopie albo w innych miejscach w sieci. Nie wykazano również, że obserwowany przez Cloudflare ruch automatyczny odpowiada działalności konkretnych sieci dezinformacyjnych.

To dwa zupełnie różne zagadnienia. Profesjonalne operacje wpływu mogą wykorzystywać rozproszoną infrastrukturę, mechanizmy maskowania pochodzenia ruchu oraz złożone systemy zarządzania kontami. Ich zależność od konkretnego centrum danych wymagałaby niezależnego potwierdzenia. Nie można wykluczyć, że pewne operacje korzystały z usług Yandexa i odczuły skutki awarii. Nie można jednak bez dowodów przypisywać im takiej zależności.

Brak dowodu na związek przyczynowy nie jest dowodem na brak takiego związku. Ale tym bardziej nie stanowi potwierdzenia jego istnienia. Opowieść o nagłym zamilknięciu rosyjskich botów po atakach na Yandexa pozostaje więc atrakcyjną hipotezą, a nie ustalonym faktem. I dopóki ktoś nie przedstawi danych pozwalających powiązać określone operacje wpływu z uszkodzoną infrastrukturą, używanie wykresów Cloudflare jako dowodu na wyłączenie rosyjskiej propagandy będzie zwykłą nadinterpretacją.

W końcu nawet najbardziej efektowny wykres nie zastąpi analizy technicznej, a odczytanie wykresu to jeszcze nie to samo co zrozumienie, co właściwie przedstawia.

Źródła i materiały do weryfikacji

1. Yandex - What is happening to our data centers, 9 października 2026

2. Yandex Cloud - oficjalny rejestr incydentu ru-central1-b

3. Reuters - drugi atak na centrum danych Yandexa, 9 października 2026

4. Cloudflare Radar - AS13238, YANDEX

5. Cloudflare Radar - AS200350, YandexCloud

6. Cloudflare Radar - YandexBot

7. Cloudflare - dokumentacja Bot Score

8. Meta - Coordinated Inauthentic Behavior, raport podsumowujący 2022

9. EEAS - Fourth Annual Report on Foreign Information Manipulation and Interference, marzec 2026

Stan informacji: 10 października 2026 r. Analiza opiera się na publicznych komunikatach operatora, dokumentacji Cloudflare i dostępnych raportach dotyczących operacji wpływu. Nie obejmuje niepublicznych logów infrastruktury ani pełnych historycznych szeregów czasowych aktywności botów.