Роботный трафик — это посещения сайта не людьми, а автоматическими программами, скриптами или ботами. Автоматизированный трафик бывает и полезным, например от поисковых роботов, и вредоносным — когда искажает аналитику, перегружает веб‑ресурс или используется для спама, атак, причинения экономического ущерба.
Yandex Smart Web Security — это сервис для защиты сайтов и приложений от DDoS‑, веб‑атак и ботов, который разрабатывают несколько команд: Yandex Cloud, Yandex Infrastructure и команда Антиробота. C помощью схемы защиты с reverse proxy можно обезопасить ресурс, в том числе, расположенный вне контура Yandex Cloud. В качестве базовой технологии защиты от роботов и DDoS‑атак на уровне приложений (L7 модели OSI) в сервисе используется SmartProtection‑модуль на базе сервиса Антиробот, который защищает, в том числе и весь Яндекс.
Недавно мы добавили в сервис новую функциональность по работе с роботами: пользователям облачной платформы она даёт возможность самостоятельно настраивать правила для выделения роботного трафика буквально с помощью пары бегунков. Мы делаем фокус на простых инструментах управления. Но за этими, казалось бы, небольшими улучшениями интерфейса, стояла большая инженерная работа.
Мы проработали разметку, обучение модели, сформировали гибкие инструменты управления чувствительностью защиты, а также учли экономические издержки роботов, боли людей и, конечно, дали возможность не задеть полезных для бизнеса роботов.
Меня зовут Руслан Сабиргалиев, я руковожу группой аналитиков службы доверия и надёжности в Яндексе. Расскажу, как мы сделали новые механизмы управления трафиком, а также про скоринг запроса, бот‑менеджмент (и почему одной крутилки оказалось не достаточно), расширенные новые сигналы и практические сценарии использования.
Что мы уже умели
Веб‑ресурсы и отрасль защиты от роботов сталкивается со средой, которая постоянно адаптируется к системам защиты. Мы подробно рассказывали про подходы и масштабируемую архитектуру принятия решения, которые используем для поддержки высоких показателей точности (Precision) по людям и полноты (Recall) по роботам.
Упрощённая архитектура сервиса Smart Web Security:
Также есть возможность защиты инфраструктуры, если она размещена на собственных серверах или в других публичных облаках с помощью подключения в режиме reverse proxy.
Что касается, непосредственно, части защиты на уровне приложений (L7 модели OSI) до того как мы взялись за задачу, у пользователей уже была возможность:
Полностью делегировать принятие решения Антироботу (SmartProtection‑модуль правил Профиля Безопасности).
Самостоятельно писать if на обеления / challenge‑проверку / блокировки на разные срезы (Базовые правила Профиля Безопасности).
Отправлять запросы на инспектирование в Управляемые наборы правил (CRS, YARS, ML) модуля Облачного WAF и защищаться от различных угроз OWASP TOP 10.
Лимитировать срезы трафика через модуль Advanced Rate Limiter: защищать свои бэкенды и ресурсоемкие части сервиса от повышенных нагрузок, которые также могут вызвать denial of serviсe.
Диагностировать проблемы по логам (в Cloud Logging/Monium Logs, в собственных SIEM через интеграцию с Audit Trails) или мониторинговым сигналам (Yandex Monitoring/Monium Metrics).
Остановимся чуть подробнее на типе правил SmartProtection.
SmartProtection — это тип правил, где система сама глубоко анализирует трафик и принимает решение, а для защищаемого сервиса нужно только выбрать один из двух режимов: Полная защита или Защита API.
Полная защита подходит для обычных веб‑страниц, где важно сохранить удобство для людей и при этом ограничивать роботов. В этом режиме сервис понимает, что можно использовать челленджи, требующие поддержку Java Script, Cookies, а также требуется обеспечить защиту от L7 DDoS.
Режим защиты API нужен там, где тоже важна защита от L7 DDoS, но возможности для проверки трафика с помощью инструментов верификаций ограничены. Это типично для трафика от бизнес‑партнеров, мобильных приложений, cross‑origin iframes, AJAX‑запросов и других сценариев, где челленджи могут сломать интеграцию или ухудшить работу. Поэтому для API и похожих маршрутов основной акцент — на защите от DDoS, а более тонкую настройку и дополнительные проверки клиент может делать сам через базовые правила или Advanced Rate Limiter.
Основная задача команды Антиробота — защитить сервис от вредоносной автоматизации, не ухудшая опыт пользователей. Система должна удерживать метрику TRN выше 99,XX%, мягко реагировать на подозрительный трафик, отражать DDoS‑атаки и повышать Recall по плохим ботам.
Такой подход позволяет нашим пользователям быстро подключать защиту. В отдельных сценариях можно сделать буквально несколько кликов и сохранить привычные бизнес‑метрики, не страдать от капчи или блокировок, при этом уже иметь базовую полноту по роботам, которая достаточна для многих защищаемых сервисов.
В указанной постановке задачи мы всё больше становились заложниками своих же ограничений и, по мере развития, стали всё чаще замечать, что у пользователей растут потребности к регулировке чувствительности. В итоге появился внутренний проект Bot Management, который затем стал доступен для решения пользовательских задач.
Почему одной настройки оказалось мало
При первоначальной постановке задачи, мы исходили из основной потребности — регулировать чувствительность принятия решения, помимо возможности передачи полномочий Антироботу. Кроме самого скоринга запроса, в реальной практике защиты важно не только оценивать, насколько запрос роботный или человечный, но и иметь возможность ответить на важные вопросы:
Позволяет ли решение регулировать тот самый баланс точности по людям / полноты по роботам?
Достаточна ли синтаксическая выразительность написания правил для разделения полезных роботов и тех, кто генерирует паразитную нагрузку? Существует ли возможность выделять ещё более узкие срезы трафика?
Есть ли возможность получать от сервиса сигналы и дополнительный контекст для принятия решения на стороне защищаемого сервиса?
Так или иначе, на первый взгляд, многое из этого можно было свести:
к классической задаче бинарной классификации (в эталонах 1 — роботы, 0 — люди);
передаче прогнозного скорингового балла в качестве управления самому пользователю в нашей админке сервиса, а также настройка возможности увидеть скор‑балл в логах или у себя на бэкенде.
Но только этим мы не сможем ограничиться:
Нам нужно поднять интерпретируемость скорингового балла, ведь у разных сервисов разная цена перебана людей и недобана роботов. Соответственно, требуется интерпретируемое управление балансом точности и полноты.
Нужна возможность отделять полезных роботов от вредных. Условно, у нас высокий bot score, но это краулер Яндекса, и ограничение этого робота потенциально будет вызывать сложности с продвижением ресурса в поисковике.
А также нужна возможность более гранулярного тюнинга на уровне узких срезов трафика.
Как устроен bot score
Логика работы
Как и в любой задаче скоринга, на старте нужно определиться, какой постановкой задачи в терминах машинного обучения мы будем оперировать. Зачастую схожие задачи сводятся к классической задаче ML на размеченных данных, например, бинарной классификации. Либо если целевой переменной нет — свести задачу к скорингу аномалий.
Чтобы построить контролируемый процесс оценки метрик качества принятия решения, постановка задачи на размеченных данных предпочтительнее. В терминах бинарной классификации в рамках нашей задачи — это разметка 1 для роботов и 0 для людей. Но где взять эту разметку и как контролировать метрики её качества?
Мы уже умели довольно надёжно строить разметку на определённых подсегментах трафика почти без серой зоны (там, где отсутствует разметка). В момент, когда проект только стартовал, чаще всего, мы переиспользовали модели, обученные на размеченном трафике. Но если посмотреть на всю генеральную совокупность наблюдений, где будет производиться потенциальный инференс модели, то это была бы выборка с большой (свыше 95–98%!) неразмеченной эталонной разметкой.
Даже в таких ситуациях, подходы моделирования всё ещё работают с теми или иными ограничениями (скорее всё сводится к вопросу, насколько репрезентативна и/или смещена выборка с размеченной частью от генеральной совокупности наблюдений).
Нам хотелось учесть как можно больше данных и добиться разнообразия примеров для построения bot score. Мы рассматривали разные варианты того, как разметить серую зону для обучения базового алгоритма машинного обучения, и в итоге остановились на алгоритмах построения разметки weak supervision.
Это позволило гибко учесть накопленную экспертизу аналитиков‑разработчиков, перекрытия и шумы в гипотезах. А ещё не использовать размеченную часть выборки для обучения алгоритма разметки, а скорее только для контроля метрик качества и проверки гипотез.
Внутренние метрики качества показали значительное снижение серой зоны (осталось менее 0,5%) и высокую точность разметки на эталонных срезах (по метрике PR AUC > 99.9%).
В результате работы разметочного алгоритма weak supervision мы получили не бинарную метку, а мягкую целевую переменную на отрезке [0,1]. С одной стороны, это менее удобно, для тех, кому привычнее работать с бинарной величиной. С другой — мы разметили серую зону, которая позволит нам учесть сервисо‑специфичные особенности трафика в большей степени и в меньшей степени переживать за репрезентативность выборки для обучения и её потенциального отклонения от среды эксплуатации.
Обучение
Итак, у нас есть soft target — пора запускать обучение алгоритма. Чаще всего мы используем CatBoost: это позволяет соответствовать строгим требованиям к производительности и длительности обработки запросов и иметь достаточную разрешающую способность алгоритма для решения поставленных задач.
В качестве факторов мы используем широкий набор технических сигналов. Некоторые из них являются интерпретируемыми и ожидаемо должны влиять на роботность: например, с ростом значения признака прогнозная оценка роботности должна не убывать, и наоборот. Также некоторые из признаков влияют на экономические издержки разработчиков софта роботов.
Всё это можно учесть через гиперпараметры monotonic_constraints у CatBoost. Что мы, собственно, и сделали. Сама идея использования monotonic_constraints для целей регуляризации, увеличения интерпретируемости и борьбы с переобучением не нова. Но мы рады, что наше внутреннее исследование экономических издержек парсеров получило ещё одно приложение в bot score.
Возьмём самый простой пример фактора: количества запросов с IP‑адреса:
Интуитивный уровень риска роботности растёт с количеством запросов. И такие требования к алгоритму машинного обучения можно настраивать. А именно, чтобы прогнозный скор‑балл роботности не убывал с ростом значения этого признака.
Для робота это означает, что потребуются дополнительные экономические издержки на инфраструктуру (например, чтобы с той же интенсивностью парсить контент, теперь нужно прятаться за несколькими IP‑адресами).
Конечно, у этого фактора могут возникать и краевые случаи, например, одновременно несколько пользователей и робот за одним IP‑адресом: NAT‑сети, мобильные IP‑адреса, Wi‑Fi).
Преимущество технологии Антиробота в том, что мы можем учитывать даже такие сложные случаи: решение принимается позапросно, а значит, можно учесть и другие факторы, которые будут влиять позитивно для людей (дообелить их с учётом всего контекста факторов) и негативно для роботов (добанить с учётом дополнительных факторов).
Итого, мы повысили интерпретируемость базового движка, отвечающего за скоринг, и определили направление его работы: чем лучше бот имитирует человека, тем выше его издержки на обход и поддержку инфраструктуры.
Архитектура
Теперь немного про саму архитектуру bot score. Мы делали фокус не только на алгоритме машинного обучения — мы дополнили его учётом высокоточных правил — эвристик, по которым выделяются роботы. В целом идея тут такая: не нужно тратить разрешающую способность сложных алгоритмов на то, что можно решить обычным if. Также мы учли дополнительную модель, которая смотрит на агрегационные/поведенческие факторы, и проверили гипотезы в части интерпретации работы архитектуры.
Сами значения bot score и калибровка скор‑балла на истинные вероятности — задача с двумя звёздочками, поэтому мы стараемся пока избегать терминов «вероятность».
Вместо калибровки на текущем этапе мы выделяем несколько особо важных для себя метрик:
монотонный рост доли роботных событий с ростом bot score;
рост ROC AUC как оценку качества сортировки алгоритма;
рост доли роботов покрытых эвристиками и факторами повышающими их экономические издержки.
Как работает алгоритм присвоения bot score
Bot score рассчитывается от 0 до 100:
0 = максимально «человеческий» профиль трафика.
100 = максимально «роботный» профиль трафика.
Сам алгоритм подсчёта bot score учитывает не только базовый алгоритм машинного обучения, но и комплекс высокоточных поведенческих моделей и эвристик.
Для первичной настройки чувствительности защиты, мы проработали экспертную шкалу роботности.
На выходе из алгоритма запросу присваивается балл от 0 до 100, где 0 означает максимально «человеческий» профиль, а 100 — максимально «роботный». В реальной практике важно начать с каких‑то бенчмарков, мы рекомендуем вам начинать свои эксперименты с такой шкалы:
не более 20— человек;20–40— вероятно человек;40–60— зона неуверенности;60–80— вероятно бот;более 80— бот.
А по мере развития — уточнять её для своего приложения. Экспериментируйте!
Как верифицируем значимых роботов
Для автоматизированного принятия решения Антироботом раньше мы самостоятельно определяли верифицированных роботов, к которым будут применяться наиболее либеральные подходы. Преимущественно, это роботы‑краулеры, ограничительные меры к которым могут вызывать сложности с продвижением в поисковиках.
Но когда мы уже говорим про самостоятельную пользовательскую регулировку чувствительности по bot score, можно, например, отправить на капчу трафик с bot score = 100. В таком случае можно задеть и вполне полезных роботов (у них тоже будут высокие баллы).
Зачастую у роботов, которые пришли проиндексировать ваш сайт, понятный user agent. Но для надёжной верификации этого не достаточно: злоумышленник тоже может подменить user agent и мимикрировать под полезного робота.
Верификация — это процесс проверки и подтверждения достоверности робота с использованием различных методов. Чаще всего в качестве верификации достаточно использовать одну из пар:
User‑agent + IP (единичный или подсети);
User‑agent + ASN (единичная или несколько);
User‑agent + анализ хоста, полученный в рамках reverse DNS lookup у пришедшего IP.
Но по каким критериям мы понимаем, что бота нужно включить в скоуп тех, что мы добавим в список верифицированных? Помимо краулеров существуют и другие роботы. Процесс по критериям добавления не всегда очевиден, попробуем их формализовать. Когда мы оценивали, стоит ли добавлять бота в общий скоуп, то обращали внимание на следующее:
Потребности пользователей. Пользователи могут просить идентифицировать робота. В таком случае мы разбирались, что это за робот.
Он должен принадлежать компании (в задаче идентификации безопасных роботов мы не хотели идентифицировать роботов, представляющий собой скрипт, который можно включить на любом хосте). Пользователь может самостоятельно обелить такого робота.
У робота должен быть набор стабильных идентификаторов (заголовок, сетевой источник).
Робот может представлять интерес более широкому перечню клиентов.
Откуда бот и чем он занимается.
Является региональным, крупным роботом (например VK, Дзен). В России эти роботы генерируют больше трафика чем в других странах.
Если бот известен или он принадлежит крупной компании, вроде Яндекса.
Уже обеляется Антироботом (ранее провели анализ в глубину и поняли, что бот полезный).
Если слышим о нём впервые, сначала разбираемся, чем он вообще занимается. Часто у роботов нет большого количества трафика или их создатели не являются крупными компаниями, но при этом робот имеет социальную значимость (например, новостной агрегатор).
Насколько глобально распространённый бот.
Бот генерирует много трафика или заявлен как популярный робот в провайдерах — Akamai, Cloudflare, AWS.
Формирование итогового списка оказалось большим и ручным трудом, по пути возникали и сложности.
В итоге, мы верифицировали свыше 100 роботов, учли как региональную, так и глобальную специфику и провели ручную глубину анализа. Поскольку роботов стало много, возникла потребность их категоризации. Мы проанализировали свои внутренние и действующие рыночные практики, в итоге остановились на 17 категориях.
AcademicResearchBot— боты для сбора данных из интернета, которые используются в академических исследованиях. Помогают автоматизировать извлечение информации для анализа и изучения научных проблем.AccessibilityBot— боты для улучшения доступности контента в интернете для людей с ограниченными возможностями. Например, помогают озвучивать текст на сайте.AdvertisingAndMarketingBot— боты для поддержки рекламных и маркетинговых кампаний.AggregatorBot— боты для сбора и распространения информации. Например, для агрегации статей с новостных сайтов.AIAssistantBot— ассистенты на базе искусственного интеллекта. Используются для решения широкого круга задач.AICrawlerBot— боты для обучения и улучшения моделей искусственного интеллекта. Могут собирать данные для тренировки алгоритмов машинного обучения.AISearchBot— боты на основе искусственного интеллекта, оптимизированные для интерактивного поиска и предоставления информации по запросам пользователей.ArchiverBot— боты для записи и долгосрочного хранения копий веб‑страниц и других интернет‑ресурсов.FeedFetcherBot— боты для извлечения данных из различных источников с регулярными обновлениями, таких как новостные ленты и блоги. Помогают пользователям получать актуальную информацию.MonitoringAndAnalyticsBot— боты для сбора аналитики по веб‑сайтам. Отслеживают различные метрики сайтов (например, посещаемость, скорость загрузки, количество ошибок) и предоставляют аналитическую информацию для улучшения работы сайтов.PagePreviewBot— бот для генерации предварительного просмотра страниц по ссылкам, которыми делятся пользователи в мессенджерах или соцсетях.SearchEngineCrawlerBot— боты для сканирования интернета и индексации страниц для поисковых систем. Помогают системам, например Яндексу, обновлять базы данных и предоставлять актуальные результаты поиска.SearchOptimizationBot— боты для оптимизации сайтов и улучшения их видимости в поисковых системах. Анализируют страницы на наличие ошибок, предлагают изменения в контенте и структуре.SecurityBot— боты для проверки веб‑сайтов на уязвимости и различные угрозы безопасности.SocialMediaMarketingBot— боты для управления присутствием брендов в социальных сетях. Автоматизируют публикации, модерацию и ответы пользователям, собирают аналитику и оценивают эффективность SMM‑кампаний.WebhooksBot— боты для автоматизации процессов с помощью технологий реального времени, позволяющих веб‑приложениям взаимодействовать друг с другом.OthersBot— прочие категории верифицированных ботов.
И для удобства наших пользователей сервис верификации стал доступен в виде нескольких крутилок
Верифицированный робот (булев флажок да/нет)
Имя робота (выпадающий список 100+ элементов)
Категория робота (выпадающий список 17 элементов)
Ещё больше полезных сигналов и резюме
На момент, когда мы приступили к задаче, в сервисе уже была возможность матчить трафик по признакам:
гео,
IP/подсети/диапазоны,
компоненты http‑запроса,
репутационный анализ IP‑адреса.
И части пользователей, этого стало не хватать.Поэтому мы расширили возможность борьбы с автоматизированных и подозрительным трафиком и добавили ASN (номер автономной системы) и tls‑fingerprint (JA4 и JA3).Это позволило ещё более гранулярно профилировать и управлять трафиком защищаемого ресурса.
Также у пользователей, особенно enterprise‑сегмента, возникают потребности в получении от нас дополнительных сигналов. Чаще всего, для расследования инцидентов, обогащения информацией внутренних антифрод‑движков, чистки внутренних логов от влияния роботного трафика (например, для анализа успешности маркетинговой активности, А/Б‑экспериментов).
Сигналы сервис научился поставлять либо в виде логов, либо в виде заголовков, которыми обогащается проинспектированный запрос поступающий на защищаемые ресурсы.
Bot Score — это не абстрактная «оценка роботности», а практичный сигнал, на который можно опираться в конкретных сценариях: где‑то мягко повышать чувствительность, где‑то отправлять трафик на дополнительную проверку, а где‑то жёстче ограничивать подозрительные срезы, в том числе, с учётом расширенных сигналов которые реализованы в Bot Management.
На практике это позволяет отдельно учитывать специфику API, публичных страниц, партнёрские интеграции и ресурсоемкие участки сервис. При этом, не смешивая полезных роботов и легитимных пользователей, с роботами, которые осуществляют вредоносную автоматизацию.
