AWS WAF Bot Control: что видит клиент

Управляемая группа правил это движок решений, и полезный вопрос не в том, сработала ли она, а в том, что она получила. BotBrowser предоставляет объявленный профиль, который сохраняет согласованность доступных странице поверхностей, и не меняет то, что группа правил решает на периферии. Структура важнее оценки: два уровня защиты проверяют разные вещи, механизм меток позволяет одному правилу передавать данные следующему, а набор действий делает блокировку и Challenge заметно разными для клиента.

Кратко

• Bot Control это одна управляемая группа правил с двумя уровнями защиты, common и targeted, и включение только common оставляет поведенческие проверки выключенными.
• Уровень common обнаруживает самоидентифицирующихся ботов традиционными методами, а targeted добавляет обнаружение ботов, которые себя не идентифицируют, и включает защиту common.
• Совпавшее правило может прикрепить метку, и последующие правила могут совпадать по этой метке, поэтому язык правил становится составным, а не одной оценкой.
• Block и Challenge это разные действия: одно завершает запрос, другое просит клиента выполнить скрипт и повторить попытку.
• Измеренный запрос без user agent вернул 403 с HTML-телом в 919 байт и без скрипта проверки, то есть это блокировка, а не Challenge.
• Тот же endpoint вернул 200 с user agent браузера, поэтому разница в этом измерении была в запросе, а не в пути.
• Метки чаще всего упускают, потому что панель со статусом «заблокировано» не сообщает, какая группа правил или какая метка привела к решению.
• Профиль на стороне страницы может сохранять согласованность своих поверхностей и не может сделать решение периферии успешным.

Содержание

• Одна группа правил, два уровня защиты
• Метки как язык правил
• Измеренная блокировка и разные действия
• Чего не видит группа правил и практический вывод

Одна группа правил, два уровня защиты

Сначала важно зафиксировать, что Bot Control это не одна сущность. У него два уровня защиты внутри одной управляемой группы правил: common работает по умолчанию, а targeted это опция, добавляющая обнаружение клиентов, которые себя не называют. Команда, которая включает более дешёвую и читает её панель, закрывает реальную часть задачи, но не всю задачу.

Уровень common обнаруживает самоидентифицирующихся ботов традиционными техниками, такими как статический анализ данных запроса; в терминах документации он помечает самоидентифицирующихся ботов, проверяет желательных, таких как поисковые системы, и обнаруживает сигнатуры высокой уверенности. Такие проверки можно выполнить, ничего не требуя от клиента, поэтому они идут первыми и ловят наименее аккуратную автоматизацию.

Уровень targeted включает защиту common и добавляет обнаружение изощрённых ботов, которые себя не идентифицируют, применяя ограничение частоты, CAPTCHA и фоновые проверки браузера, а также опрос браузера, отпечатки и поведенческие эвристики. Для задачи сбора данных это практическая разница: клиент, прошедший common, всё ещё может не пройти targeted, и оба отказа выглядят одинаково в коде состояния.

Совместное чтение меняет смысл числа «блокировок». Блокировка, отнесённая к Common, говорит о самом запросе. Блокировка, отнесённая к Targeted, говорит о сеансе, то есть один и тот же запрос может пройти при однократной отправке и не пройти при повторной. Без указания группы правил отчёт не различает эти ситуации, а реакция на каждую из них разная.

Метки как язык правил

Это структурное отличие AWS WAF от продукта на основе оценки, и именно эта часть оправдывает изучение. Когда правило совпадает, оно может прикрепить к запросу метку. Последующие правила в том же web ACL могут совпадать по этой метке так, будто это входные данные.

rule A matches   -> label aws:bot:category:http_library attached
                    (namespaced by the service, e.g. awswaf:managed:aws:bot-control:bot:category:http_library)
rule B reads     -> if label present, apply its own action
rule C reads     -> combine two labels into a narrower decision

Такая композиция и делает язык выразительным. Оценка сводит все наблюдения к одному числу, а число не может сказать, какие две проверки согласились. Набор меток может, потому что каждая метка сохраняет своё имя и происхождение, а правило, читающее две метки, утверждает конъюнкцию, а не порог.

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

Метки также объясняют поведение, которое снаружи выглядит непоследовательным. Два запроса с одним путём и одинаковыми заголовками могут получить разные действия, если более раннее правило совпало по тому, чего во втором запросе не было, и разница состоит в метке, а не в изменении endpoint.

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

Block      -> 403 by default; the client receives an error response
Challenge  -> 202; the client receives a script, runs it, retries with a token
CAPTCHA    -> 405; the client receives a page a person is expected to complete

Только среднее действие ждёт от клиента выполнения кода. Клиент, считающий блокировкой всё, что не 200, будет повторять Challenge бесконечно, потому что повтор никогда не несёт токен, которого требовал Challenge. Клиент, считающий Challenge всё, что не 200, будет выполнять несуществующий скрипт, потому что тело является страницей ошибки, а не Challenge.

Различие видно в ответе до любого разбора. Challenge несёт скрипт, который клиент должен выполнить; блокировка несёт документ ошибки. Поиск скрипта дешевле сравнения кода состояния, потому что код состояния у Challenge и блокировки может совпадать.

Измеренная блокировка и разные действия

Утверждение о различии легко заявить, поэтому был записан один запрос. Простой HTTPS-клиент запросил страницу документации без заголовка user agent, а затем тот же клиент запросил ту же страницу с user agent браузера.

no_ua:        status=403 bytes=919  challenge_marker=false block_marker=true
              server=CloudFront content-type=text/html
browser_ua:   status=200 bytes=18804
              server=Server content-type=text/html

В этом выводе стоит назвать три вещи. Первая это состояние: простая ошибка, а не обмен с Challenge. Вторая это длина тела: достаточно короткая для документа ошибки и слишком короткая для страницы, с которой клиент должен взаимодействовать. Третья это поиск маркеров, который не нашёл в ответе ни одного скрипта Challenge.

Четвёртая вещь это сравнение. Тот же клиент, тот же путь и та же секунда суток вернули полную страницу, как только запрос получил user agent браузера. Это не доказывает срабатывание правила, поскольку endpoint мог делать нечто совсем иное; это показывает, что разница между запросами была в запросе и что клиент может изменить одно, не меняя другое.

Блокировка также ничего не сообщает клиенту о том, какое правило её создало. Так и задумано: ответ не несёт идентификатор правила, набор меток или группу правил. Информация есть в журналах поставщика и в консоли, поэтому диагностика должна перейти туда, а не оставаться на клиенте.

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

Она не читает документ. Значение, существующее только после выполнения JavaScript, например хеш canvas, строка рендерера WebGL или вычисленный размер макета, не является входом для правила, которое выполняется до отправки ответа. Это не ограничение, выбранное поставщиком, а порядок операций. Периферия решает до того, как страница существует.

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

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

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

clean_get:    status=200 bytes=18804 challenge_marker=false block_marker=false
no_ua:        status=403 bytes=919   challenge_marker=false block_marker=true
scripted_post: status=403 bytes=1053 challenge_marker=false block_marker=true

Два из этих ответов являются блокировками, а один успехом, и две блокировки различаются длиной тела на сто тридцать четыре байта. Разница достаточно мала, чтобы читатель, записывающий только код состояния, увидел одно событие, тогда как читатель, записывающий длину и поиск маркеров, увидел два. Ни одна блокировка не несла скрипт Challenge, поэтому обе окончательны: клиенту нечего выполнять, и повтор того же запроса даст тот же ответ.

Набор заголовков добавляет второе прочтение. Успешный ответ сообщал server=Server, а обе блокировки сообщали server=CloudFront. Это не идентификатор правила и не название группы правил, но это говорит читателю, какой слой ответил, и отделяет блокировку, созданную перед приложением, от ответа, созданного приложением.

Из этого не следует, что user agent является решающим входом. В первом сравнении менялась именно эта переменная, и её хватило, чтобы перевести один endpoint из ошибки в полную страницу. Достаточно ли её где-то ещё, зависит от конфигурации того endpoint, и единственный честный способ ответить это записать те же три поля на рассматриваемом сайте, а не обобщать по одному случаю.

В числах есть урок второго порядка. Ответы в 919 и 18804 байт различаются в двадцать раз, и конвейер, хранящий только состояние, считает их одним классом событий, хотя один является документом ошибки, а другой страницей. Сохранение длины почти ничего не стоит и сразу разделяет их, поэтому оно принадлежит записи рядом с состоянием, а не отдельному сеансу отладки.

У группы правил есть и временное измерение, которое не покажет один запрос. Поведенческие проверки смотрят на серию запросов, поэтому клиент, отправивший один запрос и прочитавший ответ, измерил самую дешёвую часть системы. Задание, отправляющее тысячи запросов, задействует накопительную часть, и отчёт по одиночным запросам не может её описать. Это не пробел в документации поставщика, а пробел в том, что может подтвердить одно наблюдение.

Чего не видит группа правил и практический вывод

Прочитайте действие до изменения клиента. 403 с коротким телом это Block, и для объяснения нужна консоль; ответ со скриптом Challenge это Challenge, и нужен клиент, способный его выполнить. Укажите группу правил в записи, потому что Common и Targeted отказывают по разным причинам, а один код состояния покрывает обе. Сохраняйте метки, поскольку это единственное поле, которое говорит, какое правило согласилось с каким, а сводка на основе оценки это отбрасывает. Для поставщика с другой композицией прочитайте Cloudflare и DataDome: что видит сборщик; о том, какие правила требуют значения, никогда не достигающего страницы, читайте правила периферии, которые скрипт страницы не может вычислить.

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

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

У выразительности есть цена, и её стоит назвать, чтобы команда её планировала. Web ACL с множеством правил, читающих чужие метки, сложнее осмыслить, чем одну оценку, потому что порядок вычисления важен и метка, присутствующая на одном пути, может отсутствовать на другом. Правило, читающее две метки, ведёт себя иначе, чем два правила, читающих по одной, и эта разница невидима в панели, показывающей только итоговое действие. Хранение списка меток в журнале делает эту разницу восстановимой задним числом, и это то же поле, которое отвечает на вопрос о ложном срабатывании месяц спустя.

Замечание об области действия, потому что это тот случай, когда небольшое преувеличение делает всю запись бесполезной. Ничто здесь не утверждает, что конкретный сайт использует Bot Control, что конкретный код состояния пришёл от управляемой группы правил или что запрос, прошедший однажды, пройдёт на следующий день. Измерения описывают три запроса к одному endpoint документации и документированную структуру продукта; они не описывают защищённое приложение, и те же три поля, записанные для реальной цели, понадобились бы читателю, чтобы что-то о ней утверждать.

Та же осторожность относится к словарю меток. В примере используется имя в форме категории, чтобы показать работу композиции, а реальное развёртывание увидит имена, создаваемые его собственными правилами, включая префикс пространства имён, добавляемый сервисом. Копирование строки метки из руководства в правило, которое её читает, это самый быстрый способ построить правило, которое никогда не совпадёт, и исправление состоит в чтении меток из реального запроса, а не в доверии образцу.

Наконец, в наборе действий есть асимметрия, которую стоит помнить при составлении отчёта. Блокировка это решение, которое можно объяснить задним числом из консоли, а Challenge это решение, породившее второй запрос. Подсчёт только первого запроса занижает путь с Challenge вдвое, потому что повтор с токеном это отдельная запись, которая может быть успешной и не оставить следа в счётчике отказов. Отчёт, описывающий произошедшее, должен решить, что именно он считает, до того как напечатать число.

Источники

• AWS WAF Bot Control
• Метки правил AWS WAF
• Действие Challenge в AWS WAF
• BotBrowser: согласованность автоматизации