Збій Яндекса різко скоротив пошуковий обхід сайтів, але частина шкідливих ботів знайшла інші сервери. Дослідження Cloudflare показує, чому падіння трафіку окремої мережі не варто сприймати як зникнення самої загрози.
Після повідомлень про удари по дата-центрах 7–11 жовтня поширилися припущення про зупинку російських бот-мереж та операцій впливу. Marina Elmore і Lai Yi Ohlsen у дослідженні від 14 жовтня зіставили ці твердження з даними Cloudflare Radar і Bot Management. Йдеться про запити, видимі в інфраструктурі компанії, а не про весь інтернет.
Дві мережі Яндекса — два різні типи автоматизації
Для початку дослідники розділили дві автономні системи. ASN — це номер мережі певного оператора чи провайдера. У цьому випадку AS13238 пов’язана з пошуком Яндекса, а AS200350 — з Yandex.Cloud, де працюють і сторонні клієнтські застосунки.
| Показник | Пошук — AS13238 | Yandex.Cloud — AS200350 |
|---|---|---|
| Падіння трафіку 11 жовтня відносно базового рівня | 99% | 90% |
| Запити, класифіковані як автоматизовані | 99,5% | Близько 95% оцінених запитів |
| Статус Verified серед спостережуваних бот-запитів | 93,6% | 0% |
У пошуковій мережі переважали перевірені краулери, зокрема YandexBot. Вони завантажують сторінки та ресурси для пошуку. Зменшення такого потоку означає менше обходу, а не автоматично менше кібератак.
Позначка Verified означає, що Cloudflare перевірила самовизначення та поведінку бота. Її відсутність сама собою не доводить шкідливості. В облачній мережі можуть працювати звичайні інтеграції та програми незалежних користувачів; адреса хостингу не встановлює власника конкретного скрипту.
Важливо й не переплутати часові зрізи. До 13 жовтня трафік залишався на 86–90% нижчим від звичайного рівня. В уточненні за 14 жовтня, 18:00 UTC, автори вже вказували 85% від норми. Це відновлення до 85%, а не падіння на 85%.
Сканування поменшало, але частина запитів переїхала
Після збою бот-трафік із Yandex.Cloud скоротився приблизно на 40%. Спроби перевірки плагінів WordPress зменшилися на 90%, запити, визначені як сканування, — на 93%, а кількість блокувань цього потоку засобами Cloudflare — на 70%.
Найвиразніший приклад перенесення знайшли в трафіку до одного клієнта зі сфери азартних ігор. Після порушення роботи 8 жовтня запити з Yandex.Cloud до нього впали до нуля. Водночас аналогічний потік з’явився з мереж Radist і Selectel.
Збігалися одразу кілька ознак: JA4-відбиток TLS-клієнта, нетипові URL-шляхи, HTTP-заголовки та власні рядки User-Agent. У наведеному порівнянні сукупний російський бот-трафік до гральних сайтів навіть зріс зі 167,7 млн до 170,1 млн запитів — на 1,4%.
JA4 описує особливості того, як клієнт встановлює TLS-з’єднання. Це допомагає групувати схожі запити, але не є унікальним паспортом людини чи пристрою. Тут висновок про міграцію підкріплює сукупність технічних збігів, а не лише один відбиток.
Тому цей приклад показує перенесення конкретної автоматизованої активності. Він не встановлює, хто керував ботами, і не доводить, що так само переїхали всі операції з ураженої інфраструктури.
Що вдалося побачити в соцмережах
В окремій перевірці неназваної соціальної платформи дослідники не знайшли незвичного зламу активності. Загальний трафік із російських IP зменшився на 0,6%, а автоматизовані звернення до адрес публікацій, відповідей і вподобань — на 5,7%. Глобальні показники відповідно зросли на 1,2% та 1,1%.
Ці спостереження не підтверджують масштабної зупинки маніпуляцій у соцмережах. Водночас вони не дозволяють виключити вплив поза межами вибірки. Кількість HTTP-запитів не є прямим виміром пропаганди, а одна платформа не представляє всі соціальні мережі.
Що з цього варто взяти власнику сайту
Я б почав із розділення двох питань: чи стало менше небажаних запитів і чи не зник доступ у потрібних пошукових роботів. Однакова зміна загального графіка може приховувати зовсім різні наслідки.
Для перевірки обходу корисні серверні журнали: які сторінки запитує робот, як часто повертається та які коди відповіді отримує. Падіння кількості його звернень саме по собі ще не показує змін позицій чи пошукового трафіку. У цьому дослідженні довгострокові наслідки для індексації не вимірювали.
Для захисту варто зіставляти походження запитів із їхньою поведінкою: повторюваними шляхами, частотою, заголовками та зверненнями до чутливих адрес. Блокування за ASN може бути одним із фільтрів — такий підхід ми вже розглядали в матеріалі про захист WordPress за ASN і перевірки JavaScript. Проте перенесений на інший хостинг скрипт уже надходитиме з іншої мережі.
Відсутність запитів зі старих IP — ще не підстава вважати проблему закритою. Варто перевірити, чи не повторюється та сама поведінка з нових адрес.