Во многих сферах безопасности есть негласный закон: хотите безопаснее — станет менее удобно.

Привет, Хабр! Меня зовут Руслан Сабиргалиев, руковожу группой аналитиков‑разработчиков отдела доверия и надёжности Яндекса. Вместе с командами Yandex Cloud и Yandex Infrastructure мы развиваем Yandex Smart Web Security (SWS) и Yandex SmartCaptcha. Эти сервисы защищают сайты и API клиентов от нежелательной автоматизации, DDoS‑атак и попыток эксплуатации уязвимостей. Этой же технологией мы бережём и сервисы самого Яндекса.

В прошлой статье я рассказывал, как устроен bot score — параметр для оценки «роботности» трафика, который помогает нам защищать приложения от вредоносных ботов. Но он не исключает «серой зоны», при которой мы покажем капчу легитиному пользователю (а этого никто не любит). Сегодня — о том, что мы сделали, чтобы не ограничиваться одним параметром. Расскажу на нашем примере, как технологии и внимательный анализ боли людей, а также защищаемых сервисов помогают поспорить с этим негласным законом. Мы добавили две проверки, которые человек почти не замечает, выстроили из них систему интерактивных «челленджей» и дали клиентам три режима защиты. В итоге сдвинулся сам компромисс между удобством и безопасностью.

Коротко

• Появились Cookie‑проверка и JS‑проверка. Человек проходит их автоматически, обычно меньше чем за секунду, и они берут на себя часть работы капчи.

• Проверки выстроены в поэтапную, или интерактивную, схему: сомнительные запросы сначала получают самую мягкую проверку, и только если после неё выглядят достаточно подозрительно — проходят более строгую.

• У защиты теперь три режима: «Нормальный», «Повышенная защита» и «Под атакой». Их можно переключать вручную или автоматически по порогу нагрузки, а правила — привязывать к режиму.

• Результат для режима Smart Protection “Полная защита”: полнота по роботам выросла на 80%, люди стали реже в 3 раза попадать на капчу или блокировку.

• Доля атак, которые защита начинает отражать с первого же запроса, выросла в 1,4 раза.

Дилемма одного порога

Bot score — это оценка от 0 до 100: чем она выше, тем сильнее запрос похож на робота. Остаётся решить, с какого значения вмешиваться и какую меру предпринять. Условно: всё, что выше 60, отправляем на проверку, остальное пропускаем. Опустим порог до 40 — поймаем больше ботов, но капчу увидит больше людей. Поднимем до 80 — людям станет спокойнее, но часть ботов пройдёт.

Порог напрямую влияет на:

• удобство для людей: при слишком строгом пороге пользователи чаще видят капчу или попадают под блокировку;

• безопасность сервиса: при слишком мягком пороге роботы пропускаются и создают сервису проблемы — от парсинга данных до критичной нагрузки на бэкенд.

Регулировка чувствительности — важный инструмент: она позволяет явно выбрать компромисс между удобством и безопасностью под конкретный сервис. Но пока из возможных мер есть только «пропустить», «показать капчу» и «заблокировать», правильного значения у порога нет: можно лишь выбрать, чем пожертвовать. Мы хотели пойти дальше — придумать архитектуру принятия решений, которая улучшает оба показателя сразу (удобство и безопасность).

Что было в арсенале

Напомню, как устроен Smart Web Security.

Правила для автоматизированного трафика — желательного и нежелательного, — а также защиту от DDoS‑атак на уровне L7 защищаемый сервис настраивает в двух местах: в профиле безопасности и в профиле Advanced Rate Limiter (ARL). По сути это его админка: здесь он либо сам описывает политики безопасности и действия с трафиком, либо делегирует решение Антироботу — нашей системе, которая самостоятельно оценивает запросы и выбирает меру.

В Smart Protection мы стараемся минимально влиять на бизнес‑метрики защищаемого ресурса и не создавать лишнего трения для людей. Наша цель — круглосуточно, в том числе во время L7 DDoS‑атак, удерживать точность по людям — метрику TNR (True Negative Rate): сколько запросов людей должно проходить без капчи и блокировки. Наш внутренний ориентир — держать показатель выше 99%.

До недавнего времени мер воздействия было три, и у каждой своя цена:

• пропуск ничего не стоит людям, но и не защищает;

• капча — барьер и для ботов, и для DDoS‑трафика, но вызывает трение для пользователей;

• блокировка (коды 403 и 429) — максимальный барьер и максимальная цена ошибки.

При нашествии ботов или DDoS‑атаке выбор сводится к капче или блокировке. Мы много рассказывали, как делаем капчу дружелюбнее к людям, но давно живём по принципу «лучшая капча — та, которой нет». Её показ — вынужденная мера, а не основной сценарий защиты. Как сделать показ капчи избирательнее, я рассказывал в прошлой статье: там описаны инструменты управления автоматизированным трафиком, которые мы используем сами и рекомендуем защищаемым сервисам. Но избирательность упирается в точность модели: как бы хорошо она ни работала, у неё остаётся «серая зона» — запросы, про которые нельзя уверенно сказать, человек это или бот.

Поэтому мы поставили себе три цели:

• снизить избыточное трение для людей;

• ловить больше ботов и лучше отбивать DDoS‑атаки;

• расширить инструменты избирательного отбора и повысить их точность.

И пришли к трём направлениям работы:

1. Новые способы проверки и интерактивная система проверок.

2. Новая матрица принятия решений Smart Protection — адаптивная защита.

3. Больше возможностей для клиента: самостоятельная настройка политик и новые сигналы в инструментах избирательного отбора.

Две невидимые проверки

Список требований

Прорабатывая концепцию новых проверок, мы выделили главные свойства решения:

• минимальное трение для человека;

• доступность и инклюзия:

  • для людей с ограниченными возможностями и особенностями восприятия цвета;

  • на старых устройствах;

  • при плохом интернете;

  • требования к устройству — не жёстче, чем у капчи;

  • возможность получить помощь, если что-то пошло не так;

• проверка должна быть барьером для автоматизации и атак;

• проверка должна давать дополнительный контекст, который повышает точность детектирования.

После обсуждений и мозгоштурмов мы решили, что новые проверки должны:

• проходиться полностью автоматически, не требуя от человека усилий и когнитивной нагрузки;

• быть максимально незаметными, быстрыми и лёгкими — но с выходом на форму обратной связи, если что-то пошло не так;

• учитывать наш опыт работы над доступностью и инклюзией;

• опираться на стандартные HTTP-редиректы — коды 302 и 307;

• не требовать от устройства ничего, кроме поддержки cookie и JavaScript.

Так появились две автоматические проверки. В документации SWS они называются Cookie Challenge и JS Challenge.

Cookie-проверка

Как она работает:

1. Антиробот получает запрос и решает, что его стоит проверить.

2. В ответ браузер получает код 307 и cookie: мы просим повторить запрос по тому же адресу со служебной меткой.

3. Браузер повторяет запрос уже с cookie. Если всё в порядке, вторым редиректом 307 убираем служебную метку и пропускаем запрос дальше.

От устройства нужна только поддержка cookie. Проверка полностью автоматическая и очень быстрая: основная задержка — сетевая, из‑за дополнительных редиректов. Главное её преимущество — в коде 307: по стандарту HTTP он сохраняет метод и тело запроса. Поэтому Cookie‑проверка подходит и для POST‑запросов из браузера: например, отправленная форма доедет до бэкенда в исходном виде.

JS-проверка

Проверка тоже полностью автоматическая, если в браузере включён JavaScript и поддерживаются cookie. В большинстве случаев она занимает 200–1000 мс, и человек её просто не замечает — разве что увидит, как мигнула страница.

Как она работает:

1. Антиробот получает запрос и решает, что его стоит проверить.

2. Браузер получает код 302 и переходит на страницу проверки.

3. Мы производим анализ, в том числе с помощью моделей машинного обучения. Без JavaScript и cookie проверку не пройти; не пройти её и при особых комбинациях технических сигналов.

4. Пользователь возвращается на ресурс, который запрашивал.

Если проверка не укладывается в отведённое время, человек увидит страницу‑подстраховку со ссылкой на форму обратной связи. Там можно сообщить о своей проблеме — или о том, что сервис встроил JS‑проверку в сценарий, для которого она не предназначена. 

При коде 302 браузеры превращают POST‑запрос в GET и теряют его тело, поэтому JS‑проверка рассчитана прежде всего на переходы по HTML‑страницам, а для форм и других POST‑запросов лучше подходит Cookie‑проверка.

JS‑проверка — результат работы крупной команды. Проект оказался большим и непростым, так что со временем, думаю, мы напишем о нём отдельную статью. Некоторые технические подробности мы раскрыли в докладе о JS‑челлендже на конференции Yandex Scale.

Меры и их цена

Так палитра мер пополнилась двумя проверками, которые встали между пропуском и капчей:

Система интерактивных проверок

Сами по себе новые проверки — не стена в абсолютном смысле: успешная проверка не доказывает, что запрос отправил человек, — автоматизированные браузеры тоже поддерживают JavaScript и cookie. Ценность новых проверок в другом.

1. Человеку они почти ничего не стоят. Поэтому их можно показывать гораздо шире, чем капчу, — в том числе запросам из «серой зоны», которые раньше приходилось либо пропускать, либо отправлять на капчу.

2. Они отсекают примитивные и базовые атаки. Многие инструменты L7-флуда не хранят cookie и не выполняют JavaScript — для них проверка становится барьером.

3. Они дают контекст для выявления более сложных атак. Результат проверки и собранный технический контекст мы учитываем при следующих запросах с устройства — в том числе в bot score. Оценка становится точнее, и строгие меры получают только те, кто и после проверки выглядит достаточно подозрительно.

Вот как теперь выглядит расчёт bot score: результаты проверок стали для модели ещё одним источником сигналов.

Под капотом правил Smart Protection получается та самая интерактивная проверка: пропуск → Cookie‑проверка или JS‑проверка → капча → блокировка. Однозначно роботизированные запросы с высоким bot score, как и раньше, сразу получают капчу или блокировку, а запросы из «серой зоны» начинают с мягких проверок и поднимаются выше, только если дополнительные сигналы говорят, что запрос подозрительный.

Раньше мы упирались в две вещи: в нежелание лишний раз показывать людям капчу или блокировку и в разрешающую способность алгоритмов машинного обучения. Для запросов из «серой зоны» было два варианта, и оба имеют недостатки: пропустить — и вместе с людьми пропустить ботов, или показать капчу — и вместе с ботами задеть людей.

Теперь между этими вариантами появилась мягкая ступень, и она работает в обе стороны:

Людям — меньше капчи. Запрос, который раньше сразу получил бы капчу, теперь сначала отправляется на автоматическую проверку. Обычный браузер проходит её сам, и человек так и не видит капчу. Она остаётся для явных роботов и для тех, кто выглядит подозрительно после проверки.

Роботам — больше барьеров. Запросы из «серой зоны», которые раньше пропускали, чтобы не задеть людей, теперь получают проверку. Простые инструменты на ней отсеиваются, а для остальных результат проверки становится сигналом, чтобы обосновать более строгие меры на последующих запросах.

По сути, мягкие проверки дали нам запас полноты, и часть этого запаса мы разменяли на более редкую капчу. Поэтому в результатах ниже растут обе метрики: роботов мы ловим больше, а капчу и блокировки люди видят примерно в 3 раза реже — ценой короткой автоматической проверки, которую большинство просто не замечает.

Стало и удобнее, и безопаснее.

Как включить новые проверки

Новые проверки и интерактивную проверку можно использовать тремя способами:

1. Правило Smart Protection в режиме «Полная защита». Решение о том, что делать с запросом, принимаем мы и сами выстраиваем интерактивную проверку.

2. Базовые правила профиля безопасности*. Защищаемый сервис сам задаёт условия и выбирает меру — JS‑проверку или Cookie‑проверку.

3. Правила Advanced Rate Limiter*. Запросы сверх лимита можно не только блокировать или отправлять на капчу, но и направлять на JS‑ или Cookie‑проверку.

В правилах также появятся* новые условия: запрос к статическому файлу и признаки того, что устройство уже проходило проверку — капчу, JS‑ или Cookie‑проверку. Например, можно не показывать проверку при запросах к картинкам и скриптам или не проверять повторно устройство, которое уже прошло JS‑проверку. А комбинируя такие условия, можно выстроить и собственную политику интерактивной проверки.

* Эту функциональность мы публично анонсировали на конференции Yandex Scale, работаем над релизом.

Адаптивная защита

Задачу отражения атак можно разделить на два вопроса:

• идёт ли сейчас атака?

• нужно ли что‑то предпринять и что именно?

Термин «DDoS‑атака» знают многие, но на практике отличить атаку от легитимного трафика порой оказывается непросто. Резкий рост трафика бывает и без атаки:

• маркетинговая активность сервиса: рекламная кампания, распродажа;

• особенности бизнес‑логики самого приложения;

• неудачный релиз бэкенда;

• желательные боты: например, бизнес‑партнёр разом забирает большой объём данных.

Поэтому в отрасли защиты зачастую говорят не «атака», а «аномалия». Понять, атака ли это, без ручного анализа со стороны аналитика и самого сервиса порой невозможно.

Детектировать аномалии может как сам защищаемый сервис, так и сервис защиты — одно не мешает другому, а скорее дополняет его:

Бизнес всегда лучше знает свою внутреннюю кухню: особенности продукта, когда стартует акция для привлечения аудитории, какой запас по железу. Мы лучше понимаем, как обнаруживать аномалии и защищать от атак наиболее избирательными мерами, но почти ничего не знаем о бизнесе клиента без глубокого анализа каждого случая, то есть без ручного труда.

Три режима вместо одного

До сих пор у защиты фактически был один режим — «Нормальный». Под капотом в нём работали и продолжают работать наши статистические методы и эвристики: они определяют, что на ресурс идёт атака, и применяют самые щадящие из подходящих мер. Но некоторые сервисы подключают защиту прямо во время атаки, и без истории трафика статистические методы сталкиваются с ограничениями в точности, чтобы отличить нормальный трафик крупного клиента от атаки. Нам также сообщали, что были сервисы, которые держали два набора настроек защиты — обычный и на время атаки.

Это работает, но неудобно и требует разработки и лишних настроек на стороне клиента. Поэтому мы решили сделать этот рычаг частью продукта и ввели три режима защиты:

Режимы вложены друг в друга. У каждого правила профиля безопасности есть настройка «Режимы применения» с тремя вариантами: «Все режимы», «Повышенная защита и Под атакой» или «Только Под атакой». Правило, помеченное вторым вариантом, работает в обоих повышенных режимах, третьим — только в режиме «Под атакой».

Переключать режимы можно двумя способами.

Вручную. Переключение необязательно привязывать к метрике: иногда во время атаки быстрее и понятнее просто нажать кнопку. Буквально в два клика режим «Нормальный» переключается на «Повышенную защиту» или «Под атакой», и выбранный режим сохраняется независимо от нагрузки, пока клиент снова не включит автоматическое управление или не вернёт «Нормальный» режим обратно.

Повышенные режимы включают более агрессивные, но по‑прежнему избирательные наборы правил и анти‑DDoS ML‑модели. 

Автоматически. Режим переключается сам по правилам, которые вы задаёте заранее. Для каждого повышенного режима правило состоит из трёх параметров: порога входящих запросов на профиль, периода расчёта и времени сохранения режима — например, «больше 1000 запросов за последнюю секунду, держать режим 2 минуты». Дальше логика такая:

• нагрузка ниже обоих порогов — работает «Нормальный»;

• превышен порог «Повышенной защиты» — включается «Повышенная защита»;

• превышен порог «Под атакой» — включается «Под атакой». Если превышены оба порога, действует более строгий режим.

Когда нагрузка опускается ниже порога, режим сохраняется ещё заданное время, а затем защита переходит к режиму, который соответствует текущей нагрузке. Так она не переключается туда‑обратно на границе порога. Значения на скриншоте ниже — пример: 1000 и 3000 запросов в секунду, время сохранения 2 минуты.

Эти параметры задаёте вы: о распродажах, релизах и запасе мощности бэкенда вы знаете лучше нас. Ориентир для настройки — пиковые нагрузки органического трафика, включая плановые акции: порог ставят выше этих пиков, но ниже нагрузки, которую выдерживает бэкенд. Настройки стоит пересматривать, когда меняется трафик: растёт аудитория, готовится крупная акция или меняется инфраструктура.

Кто принимает решение — клиент или мы

Здесь напрашивается вопрос: значит ли появление режимов, что мы отдаём решение целиком клиенту и просто выполняем его команды? Нет.

Мы по‑прежнему сами определяем, что происходит, и совершенствуем свои алгоритмы. Автоматическое детектирование атак никуда не девается и продолжает развиваться.

Но теперь мы учитываем сигнал самого клиента. В некоторых сценариях клиент лучше нас знает, когда у него распродажа, а когда — реальная проблема. Поэтому его «я под атакой» — не команда, которая отменяет наши подходы, а дополнительный и очень качественный сигнал, который мы добавляем в свою матрицу принятия решений. Выбранный режим меняет политику Smart Protection, но решение по каждому запросу по‑прежнему принимает автоматика, которая видит картину трафика целиком.

А если хочется — можно настроить политику с нуля самому. Тем, кому мало доверять нам даже с поправкой на свой сигнал, остаётся путь полностью самостоятельных мер: клиент пишет собственные базовые правила и правила Advanced Rate Limiter, и наша автоматика в этом решении не участвует. Например: «Во время атаки весь трафик ботов отправляй на капчу, а подозрительный — на JS‑проверку» (такая проверка в собственных правилах станет доступна с релизом до 1 декабря). Это максимум контроля и прозрачности: защищаемый сервис точно знает, что произойдёт, а мы в этой части просто исполняем его правила.

Для этой логики у правил профиля безопасности есть настройка «Режимы применения», о которой я писал выше.

Настраивая собственные политики, помните, что автоматизация бывает и полезной — например, поисковые краулеры. Чтобы верифицированный поисковый робот не получал проверок, можно воспользоваться нашим сервисом верификации роботов — о нём мы рассказывали в прошлой статье.

Все три уровня участия защищаемого сервиса:

Результаты

Вот что изменилось в режиме «Полная защита» Smart Protection после запуска новых проверок и адаптивной защиты. Метрики мы считаем по офлайн‑разметке трафика: людей и роботов размечает алгоритм weak supervision, а точные сигналы, когда они есть, имеют приоритет над его разметкой. Цифры оценивали для сервисов под защитой SWS.

Значения сравнивали с периодом до начала раскатки. Прирост может различаться от сервиса к сервису.

Полнота по роботам (recall) выросла на 80% (для отдельно взятых защищаемых сервисов). Рост начался с поэтапной раскаткой в конце июля.

• результат получен на частичном и избирательном применении новых типов проверок;

• показывает общую картину, но отражает и наше состояние разметки трафика;

• при расчёте полноты учитывались все вердикты, кроме пропуска.

Людям стало удобнее. В 3 раза сократилась доля запросов людей, на которые капча или блокировка показывались. На автоматическую JS‑ или Cookie‑проверку при этом попадают от 12 до 20% людей — в зависимости от настроек политик, — а время обработки такого запроса на нашем бэкенде на p95 не превышает 1–5 мс (без учёта сети и работы проверки в браузере).

Не обошлось без проблем

Во время раскатки мы столкнулись с двумя проблемами: первая задела часть легитимных пользователей, вторая исказила измерения.

1. Погрешность разметки. При наплывах трафика разметка иногда ошибалась: защита успевала ограничить самые первые запросы атаки, а офлайн‑разметка признавала их «человеческими». Такие запросы попадали в статистику как ошибочно заблокированные люди и искусственно занижали точность по людям. Мы продолжаем повышать точность офлайн‑разметки трафика.

2. Небраузерный трафик в режиме «Полная защита». У части сервисов «Полная защита» была включена не только для веб‑страниц, но и для трафика, который не выполняет JavaScript или не хранит cookie: мобильных приложений, кросс‑доменных AJAX‑запросов, встраиваний в чужие страницы (cross‑origin iframe) и доменов без cookie. Когда мы начали раскатывать новые проверки, некоторые пользователи таких сервисов получили проверку, которую в их сценарии пройти невозможно. Мы разобрали обращения и помогли владельцам сервисов перенастроить защиту. Практическое правило: для API, мобильных приложений и встраиваний используйте режим «Защита API», а «Полную защиту» — для страниц, которые открываются в браузере с поддержкой cookie и JavaScript. Если на одном сайте есть и страницы, и API, заведите для API отдельное правило Smart Protection в режиме «Защита API».

Быстрее реагируем на атаки

В защите от DDoS‑атак важен не только сам факт отражения, но и скорость реакции: чем раньше защита начинает отбивать атаку, тем меньше атакующий успевает разогнать RPS. Насколько мощными бывают такие атаки, мы в 2021 году разбирали с Qrator Labs на примере ботнета Mēris.

Реакция на первый же запрос атаки.

С июня по сентябрь доля средних и крупных L7-атак на сайты в режиме «Полная защита», в которых защита отреагировала уже на первый запрос атакующих, выросла почти в 1,4 раза. Реакцией считаем любую меру, кроме пропуска.

В режимах адаптивной защиты «Повышенная защита» и «Под атакой» мы ожидаем ещё более значимые эффекты.

Реагировать раньше нам помогли:

• переход на новую логику принятия решений;

• внутренние работы над улучшением подходов автоматического детектирования аномалий;

• ускорение механизмов актуализации данных;

• переобучение анти‑DDoS‑модели — теперь она участвует в решении уже по первым запросам.

Итого

В начале статьи я упоминал негласный закон защиты: хотите безопаснее — станет менее удобно. Он и правда работает, пока у защиты только один рычаг управления и ограниченные меры воздействия. Тогда остаётся лишь выбирать компромисс. Мы пошли другим путём и сдвинули сам компромисс: добавили проверки, которые почти ничего не стоят человеку, и научили защиту прислушиваться к защищаемому сервису. Цифры выше показывают, что так можно улучшить обе стороны сразу: полнота по роботам выросла на 80%, а капчу и блокировки люди стали видеть в 3 раза реже.

Из нашего опыта можно вынести три вывода, которые пригодятся не только в защите от ботов:

• Упёрлись в один порог — добавьте промежуточную меру. Она превращает один порог в два, и «серая зона» перестаёт быть выбором между ранее ограниченным количеством мер.

• Упрощённая проверка ценна не только как дополнительный барьер, но и как источник сигнала. Человек её почти не замечает, а у системы появляется контекст для более точного решения.

• Контекст бизнеса трудно угадать — куда эффективнее дать сервису рычаг. Сигнал защищаемого сервиса — ещё один весомый фактор в решении автоматики.

Мы по‑прежнему живём по принципу «лучшая капча — та, которой нет». Капча никуда не делась и остаётся эффективным барьером, но это крайняя мера. Попробовать новые возможности Yandex Smart Web Security можно в Yandex Cloud: вот документация по правилам и режимам защиты.