В трафике ботов и злоупотреблений модель «мгновенное решение по каждому запросу» недостаточна.
Трафик ботов и злоупотреблений чаще всего проявляется не как всплеск, а как медленное и непрерывное поведение. IP может делать 30-50 запросов в минуту; само по себе это не катастрофа, но если это продолжается 10 минут, оно превращается в скрапинг, автоматизацию или перебор паролей. Мгновенный rate-limit не всегда корректно улавливает растянутый во времени характер такого поведения.
Сигнатуры WAAP решают другую задачу: соответствует ли этот запрос известному паттерну атаки? Можно поймать вредоносные паттерны контента, такие как SQL injection, XSS или command injection. Но скрапинг, отслеживание цен, перебор учётных записей или агрессивное использование API — выглядящие легитимно, но генерирующие интенсивный трафик — могут ускользнуть от защиты на основе сигнатур.
Между этими двумя подходами нужна модель временной изоляции. Если определённый источник за последние N минут демонстрировал поведение, превышающее порог, он должен быть помещён в карантин на M минут, не будучи заблокированным навсегда. В течение этого времени его трафик может блокироваться, направляться на страницу с пояснением или перенаправляться в другой поток. По истечении срока источник автоматически освобождается.
Для этой модели нужны два отдельных механизма: окно наблюдения, измеряющее поведение, и окно карантина, применяющее изоляцию. Наблюдение может быть коротким, а карантин — длиннее; либо наоборот, в зависимости от чувствительности приложения. Действие тоже не должно быть единообразным: для одних источников уместнее тихая блокировка, для других — страница с пояснением, для третьих — переадресация.
Карантин трафика TR7 обеспечивает эту модель: два отдельных временных окна для наблюдения и карантина, четыре типа ключа, три типа действия, возможность использовать состояние карантина как условие в других правилах, а также живую видимость и ручное вмешательство с экрана vService.
Наш подход
Карантин трафика TR7 объединяет наблюдение за поведением и временную изоляцию в одном движке политик.
Два отдельных окна разделяют поведение и санкцию
В каждом правиле карантина окно наблюдения и окно карантина задаются отдельно. Окно наблюдения измеряет поведение источника; окно карантина определяет, как долго будет действовать действие после превышения порога.
Четыре типа ключа обеспечивают гранулярную изоляцию
Источник не обязан определяться только по IP. С опциями IP, IP+user agent, Host+IP и Host+IP+user agent достигается более точное разделение в сценариях с несколькими доменами, NAT и мультитенантностью.
Три действия предлагают разную жёсткость вмешательства
Во время карантина трафик может блокироваться, перенаправляться на другой URL или получать специальную страницу с контентом. Так к трафику атакующего применяется тихая блокировка, к реальному пользователю — поясняющее сообщение, а к рабочему процессу — подходящая переадресация.
Состояние карантина становится условием в других правилах
Помещённый в карантин источник превращается в сигнал состояния, доступный во всей системе. Другие правила трафика, переадресации и контента могут использовать этот сигнал как условие, формируя композитную политику.
Возможности
Карантин трафика объединяет наблюдение за поведением, временную изоляцию и операторский контроль в единой модели работы.
Структура из двух окон раздельно управляет наблюдением и карантином
В каждом правиле время наблюдения и время карантина настраиваются независимо. В пределах окна наблюдения подсчитывается поведение источника; при превышении порога источник удерживается в отдельном списке в течение окна карантина. По истечении срока запись автоматически удаляется. Эта структура обеспечивает контролируемую и срочную изоляцию вместо постоянной блокировки.
Выбор типа ключа снижает риск ложных срабатываний
Опция `ip` обеспечивает классическое наблюдение по исходному IP. `ipUa` разделяет разные user agent за одним IP. `hostIp` в средах с несколькими доменами отдельно подсчитывает поведение одного IP, идущего к разным хостам. `hostIpUa` обеспечивает наиболее гранулярное разделение в мультитенантных и мультиклиентских средах.
Условие перехода в карантин задаётся числовым порогом
Оператор может задать порог для количества запросов в определённом временном окне. Правила вроде «более 100 запросов за последние 10 минут» запускают поведенческий карантин. Решение основано не на одном запросе, а на суммарном поведении в пределах окна. В отличие от rate-limit, этот подход основан на наблюдении.
Действие Block тихо обрывает трафик атакующего
Действие `block` используется, чтобы тихо отбросить трафик источника в карантине. Для трафика ботов и автоматизации такое поведение чаще всего эффективнее; атакующий не получает чёткого ответа приложения. Это действие подходит для высокорисковых сценариев злоупотреблений, где не требуется показывать пояснение. Влияние на реального пользователя можно отслеживать с экрана мониторинга vService.
Действие ShowContent даёт пользователю поясняющий ответ
`showContent` возвращает источнику в карантине специальный HTTP-код статуса и контент. Например, можно показать страницу, объясняющую, что доступ временно ограничен из-за избыточного числа запросов. Эта модель ведёт себя мягче блокировки в сценариях, где возможны ложные срабатывания или важен пользовательский опыт. Содержание сообщения можно подготовить в соответствии с языком поддержки и бренда организации.
Действие Redirect направляет трафик в иной поток
`redirect` используется, чтобы перенаправить источник в карантине на другой URL. Целью может быть страница CAPTCHA, портал с пояснением, страница повышения подписки или страница поддержки. Так карантин становится не только средством блокировки, но и инструментом перевода пользователя в нужный рабочий процесс. В мультитенантных и SaaS-сценариях эта опция особенно ценна.
Состояние карантина может быть частью композитных правил
Нахождение источника в карантине может использоваться как условие в других правилах. Источники в карантине могут перенаправляться на иной backend, получать специальные заголовки, видеть специальный контентный ответ или попадать под второе, более жёсткое правило. Эта возможность превращает одно правило карантина в сигнал, запускающий изменение поведения во всей системе. Это один из важнейших отличительных моментов TR7.
Политику карантина можно применять к HTTP- и TCP-сервисам
Карантин трафика можно использовать как для HTTP-, так и для TCP-сервисов. На стороне HTTP отслеживается поведение на уровне запросов, а на стороне TCP решение принимается на уровне соединения. Технический результат действия может различаться в зависимости от протокола; но базовая модель одинакова: наблюдай, помещай превысившего порог во временную изоляцию, освобождай по истечении срока.
Монитор vService делает видимыми активные записи карантина
На экране живого мониторинга vService перечисляются активные источники в карантине. Оператор может видеть, какой ключ, по причине какого правила и на какой срок находится в карантине. В случае ложного срабатывания или приоритетного пользователя возможно ручное извлечение. Поскольку записи с истёкшим сроком очищаются автоматически, ручное вмешательство не обязательно.
Несколько параллельных правил позволяют выстроить ступенчатое принуждение
Под одним vService могут совместно работать несколько правил карантина. Например, первое правило при избытке запросов показывает страницу предупреждения, а второе правило блокирует всё ещё продолжающий источник на более длительный срок. Поддерживается 5 параллельных правил карантина на vService. Эта структура формирует контроль злоупотреблений, идущий от мягкого к жёсткому.
Операционная глубина
Карантин трафика управляется операционно вместе с жизненным циклом таблиц, поведением кластера, влиянием перезагрузки, экраном мониторинга и audit-записями.
Жизненный цикл таблиц
Каждое правило карантина использует две отдельные области живого мониторинга — для наблюдения и для карантина. Записи удерживаются на срок и автоматически очищаются по истечении TTL. По мере поступления новых запросов обновляется поведение окна наблюдения. Эта структура удерживает карантин не как постоянную блокировку, а как срочный контроль поведения.
Оценка в момент запроса
При каждом запросе сначала вычисляется формула ключа, затем обновляется значение наблюдения и оценивается условие карантина. Если источник уже в карантине, применяется заданное действие. Если источник не в карантине, нормальный поток трафика продолжается. Решение происходит в тракте данных с низкой стоимостью.
Поведение кластера
В двухузловых установках таблицы карантина могут проектироваться так, чтобы работать локально или синхронно. Если синхронизация не включена, после failover новый активный узел воссоздаёт историю карантина с нуля. При включённой синхронизации состояние карантина может сохраняться после failover. Этот выбор следует оценивать исходя из операционных потребностей и модели развёртывания.
Влияние перезагрузки
Таблицы карантина хранятся в памяти и не ведут себя как постоянный blacklist. После мягкой перезагрузки или сброса таблиц активное состояние карантина может быть очищено. Это допустимое поведение, поскольку карантин — это механизм временной изоляции. Если требуется долгосрочная блокировка, его следует использовать вместе с фидами IP-репутации.
Операция ручного извлечения
На экране монитора vService видны активные записи карантина, и оператор может извлечь определённый источник из карантина. Эта операция удаляет запись таблицы; следующий запрос оценивается в нормальном потоке. Обеспечивает быстрое вмешательство в случае VIP-пользователя, ложного срабатывания или обращения в поддержку.
Audit и поток SIEM
События помещения в карантин и извлечения из карантина могут записываться в audit-журналы. Если включён SIEM log streaming, события могут отправляться во внешний агрегатор. То, какой ключ, по причине какого правила, с каким действием и на какой срок был помещён в карантин, можно проанализировать впоследствии.
Ёмкость и память
Количество активных ключей и тип ключа влияют на потребление памяти. Ключи на основе IP проще, а составные ключи вроде Host+IP+user agent потребляют больше места. Поскольку поддерживается 5 параллельных правил карантина на vService, план ёмкости следует составлять исходя из профиля трафика.
В каких сценариях используется
Подавление агрессивного трафика скрапинг-ботов
E-commerce-сайт может отслеживать источники, выполняющие скрапинг цен, с помощью ключа `ipUa`. Комбинация IP+user agent, превысившая 100 запросов за 5 минут, блокируется на 30 минут; разные реальные пользователи за одним IP могут оцениваться как отдельные ключи.
Временная изоляция поведения login brute-force
Банковский портал может отслеживать повторяющиеся попытки на login-эндпоинте по IP или IP+user agent. При превышении порога источник на 60 минут переводится на поясняющую страницу, и реальному пользователю показывается причина временного ограничения.
Разделение тенантов в мультитенантной SaaS-среде
SaaS-платформа, размещающая несколько доменов, может отдельно отслеживать трафик каждого тенанта с помощью ключа `hostIp`. Агрессивное использование одним тенантом может быть переведено на действие redirect или временной блокировки, не затрагивая трафик других тенантов.
Ступенчатое принуждение от мягкого предупреждения к жёсткой блокировке
Первое правило перенаправляет источник, делающий слишком много запросов, на страницу предупреждения на 10 минут. Если источник продолжает генерировать трафик, находясь в карантине, вступает в действие второе правило и применяет блокировку на 60 минут. Использование состояния карантина как условия в других правилах делает эту ступенчатую модель возможной.
Часто задаваемые вопросы
В чём разница между карантином трафика и rate-limit?
Как состояние карантина используется как условие в других правилах?
Какой тип ключа выбрать?
Как освободить пользователя, ошибочно помещённого в карантин?
Сохраняются ли таблицы карантина после перезагрузки?
Сколько правил карантина можно задать на одном vService?
Подавляйте трафик ботов и злоупотреблений без постоянной блокировки
Поведенческая временная изоляция, композитная структура правил и живая операторская видимость. Давайте вместе разберём, как это работает в вашей собственной среде.