Когда бот-трафик становится большинством, вопрос меняется
Веб-безопасность долго опиралась на молчаливое допущение: за входящим запросом в большинстве случаев стоит человек. На этом допущении были построены управление сессиями, противодействие мошенничеству, ограничение скорости, безопасность входа, защита контента и политики WAF. Боты существовали; но большинство систем рассматривали их как исключение. Человеческий трафик считался нормой, а бот-трафик — отклонением, которое нужно отделить.
На входе в 2026 год этот баланс изменился. Бот-трафик больше не маленькая проблема, стоящая на краю веб-трафика. Поисковые краулеры, SEO-инструменты, скраперы цен, боты credential stuffing, сети click fraud, инфраструктуры residential proxy и AI-агенты обращаются к одной и той же поверхности приложения с разными намерениями.
Поэтому в современном управлении ботами вопрос уже не только в том: бот ли этот запрос? Более важный вопрос: какого типа этот бот и что он пытается сделать?
Ведь не каждый бот враждебен. Googlebot должен иметь доступ к вашему сайту. Авторизованным инструментам мониторинга нужно проверять ваши сервисы. AI-агент клиента, действующий от его имени, может создать совершенно новую модель доступа. В то же время боты, выполняющие credential stuffing, крадущие ваши ценовые данные, истощающие запасы или скрапящие контент, должны быть остановлены. Защита, построенная без этого различия, даёт два плохих результата: блокирует хороших ботов и упускает плохих.
Поэтому современное управление ботами — это не одно решение о блокировке. Оно совместно оценивает поведенческие сигналы, протокольные отпечатки, поток сессии, контекст IP и ASN, объём запросов и индикаторы намерений. А затем применяет к каждой категории свою политику.
Эпоха 51% в цифрах
Боты впервые пересекли порог человек/не-человек в 2025 году
Imperva Bad Bot Report 2025TR7 Bot Management совместно использует поведенческие, протокольные сигналы, сигналы идентичности и репутации
TR7 ПродуктОбнаружение должно работать в потоке запросов, не влияя на легитимных пользователей
TR7 ИнженерияНеобходимые (разрешить), терпимые (ограничить), враждебные (блокировать) — одного решения недостаточно
OWASP OATCAPTCHA долго были средством контроля бот-защиты по умолчанию. Базовая идея была проста: создать задачу, которую человек легко решает, а бот — нет. Эта идея утратила прежнюю силу. Современные графические AI-модели способны решать графические CAPTCHA с высокой точностью. Системы speech-to-text обесценивают аудио-CAPTCHA. Простые математические или логические вопросы не создают преграды для LLM. А поведенческие CAPTCHA в стиле drag-and-drop или puzzle обходятся библиотеками автоматизации, имитирующими движение человека. Что важнее, боту даже не нужно решать CAPTCHA самостоятельно. Сервисы решения CAPTCHA работают как глобальная цепочка поставок — принимают bot challenge, передают его недорогому сервису решения и используют ответ в реальном времени. При этом легитимный пользователь теряет несколько секунд, сталкивается с проблемой доступности или выпадает из сессии. Баланс стоимости перевернулся: CAPTCHA добавляет трение легитимному пользователю, но не может остановить мотивированного злоумышленника. Более верный подход — собирать сигналы в фоне, не требуя от пользователя доказывать себя — поэтому поведенческий отпечаток, анализ протокола и классификация намерений становятся центром современного управления ботами.
Современное управление ботами не опирается на один сигнал
Эпоха, когда в обнаружении ботов хватало одного сигнала, осталась позади. IP-репутации самой по себе недостаточно; сети residential proxy могут выводить трафик из настоящих домашних интернет-соединений. User-agent ненадёжен. Проверка headless-браузера сама по себе слаба. Решение CAPTCHA ненадёжно. Эффективное управление ботами совместно оценивает множество слабых сигналов — каждый по отдельности можно обойти, но злоумышленнику сложно подделать их все одновременно, согласованно и с низкой стоимостью.
Поведенческий отпечаток
Реальные пользователи взаимодействуют с приложением нерегулярно, контекстно и биологически непоследовательно — движения мыши не описывают идеальных кривых, ритм печати непостоянен, скорость прокрутки меняется с контентом, события фокуса, паузы, возвраты и мелкие колебания образуют естественный паттерн внутри сессии. Боты впадают в одну из крайностей: слишком регулярны (идеальный тайминг, линейные движения, равномерно распределённые запросы) или непоследовательно имитируют человека. Поведенческий отпечаток совместно оценивает эти микросигналы — легитимному пользователю не показывается видимый challenge.
TLS-отпечаток (JA4)
Боты часто пытаются выдавать себя за современный браузер — user-agent можно выставить как Chrome, заголовки можно отредактировать, JS-окружение можно частично имитировать. Однако на нижних слоях остаётся настоящий след клиентской библиотеки. Список cipher suite в TLS Client Hello, порядок расширений, поддерживаемые группы и детали handshake дают сильные сигналы об идентичности клиента. Даже если Python requests, настоящий Chrome, headless-браузер или специальный инструмент автоматизации пытаются выглядеть одинаково, на уровне TLS они оставляют разные следы.
HTTP/2-отпечаток
HTTP/2 точно так же даёт ценные сигналы — настройки фреймов, порядок pseudo-header, поведение HPACK-кодирования, предпочтения приоритизации и детали управления соединением отражают истинную природу клиентской библиотеки. Поведение HTTP/2 настоящих браузеров и библиотек автоматизации часто не совпадает в точности. Даже если на верхнем слое заголовки подделаны, детали протокола остаются разными — это различие ценно при обнаружении продвинутых ботов, выглядящих очень близко к настоящему браузеру.
Анализ потока сессии
Один из самых ценных сигналов — форма сессии. Отдельные запросы могут выглядеть чисто — заголовки верны, IP не подозрителен, TLS-профиль приемлем. Но при изучении всей сессии намерение проявляется. Поведение настоящих пользователей следует пути: приходит на главную, просматривает контент, переходит в категорию, изучает товар, ждёт. Боты пропускают фазу исследования — идут прямо на целевой эндпоинт, повторяют одну и ту же операцию, нагружают форму входа разными учётными данными, регулярно вытягивают страницы с ценами, прогоняют поток оплаты, не изучив товар.
Репутация IP и ASN
Сети residential proxy серьёзно ослабили защиты на основе IP-репутации. Злоумышленники больше не приходят только с IP дата-центров. Несмотря на это, репутация IP и ASN не вовсе бесполезна. Если с одного residential IP приходят тысячи запросов в минуту, это всё ещё подозрительно. ASN, выполняющий за короткое время множество попыток входа в аккаунты, всё ещё важен. Сети, ранее замеченные в злоупотреблениях, должны вносить вклад в оценку риска. Верный подход: IP не должен решать сам по себе — но должен добавлять вес решению.
Классификация намерений
Настоящая точка перелома — классификация намерений. «Автоматический трафик» сам по себе недостаточная категория — поисковая система тоже автоматична, и бот credential stuffing тоже. Классификация намерений смотрит на такие вопросы: какие эндпоинты атакуются, в каком порядке приходят запросы, как меняются payload'ы, как варьируются учётные данные при попытках входа, с каким ритмом вытягиваются страницы цен или запасов. Credential stuffer и скрапер цен не рассматриваются одинаково. Управление ботами выходит из решения «блокировать/разрешить»; оно превращается в систему, применяющую политику по категориям.
Три категории: разрешить, ограничить, блокировать
В современном управлении ботами цель — не устранить всех ботов. Это и невозможно, и нежелательно. Некоторые боты необходимы для вашего бизнеса. Некоторые терпимы. А некоторые должны быть напрямую заблокированы. На практике бот-трафик нужно разделить на три основные категории.
Необходимые боты — разрешить
Их доступ ценен для вашего бизнеса или операционно необходим. Поисковые краулеры индексируют ваши страницы и приносят органический трафик. Боты предпросмотра соцсетей обеспечивают корректный вид ссылок. Авторизованные инструменты мониторинга проверяют доступность сервиса. Ваши собственные синтетические тесты измеряют здоровье приложения. AI-агенты — аутентифицированные, авторизованные, действующие от имени пользователя — относятся сюда; их не следует оценивать как анонимного плохого бота. Верная политика — не блокировка, а проверка и контролируемое разрешение.
Терпимые боты — ограничить
Они не являются напрямую необходимыми, но и блокировать их в любом случае не нужно. Медленные скраперы, RSS-читалки, инструменты архивирования, генераторы предпросмотра соцсетей, краулеры среднего уровня анализа относятся к этой группе. Их можно терпеть в определённых пределах — но нельзя позволять им потреблять ресурсы приложения, агрессивно вытягивать данные или влиять на пользовательский опыт. Верная политика: ограничение скорости, низкий приоритет, применение challenge, ограничение определёнными эндпоинтами. Неопределённые сессии тоже можно отнести к этой категории — их проверяют недорогим трением.
Враждебные боты — блокировать
Боты, чья цель — напрямую нанести вред. Боты credential stuffing пробуют утёкшие пароли на эндпоинтах входа. Атаки account takeover пытаются захватить аккаунты. Конкурентные скраперы крадут данные цен и запасов. Боты click fraud расходуют рекламный бюджет. Боты запасов искусственно истощают запасы. Несанкционированные скраперы контента забирают ваши данные для чужих моделей, конкурентов или брокеров данных. Верная политика ясна: блокировать, логировать, генерировать тревогу и при необходимости запускать дополнительные процессы безопасности. Каждый успешный запрос создаёт издержки — здесь нужно не трение, а прямая остановка.
Слой политики: отделить обнаружение от действия
Частая ошибка в управлении ботами — рассматривать обнаружение и политику как одно и то же.
Обнаружение отвечает на вопрос: что это за трафик?
Политика же отвечает на другой вопрос: что мы будем делать с этим трафиком?
Когда эти два решения не разделены, система становится хрупкой. Простое правило вроде «если бот — блокировать» складывает Googlebot, RSS-читалку, AI-агента и credential stuffer в одну корзину. А это увеличивает ложные срабатывания и отсекает ценный для бизнеса трафик.
Более устойчивый подход таков: слой обнаружения определяет тип и намерение бота; слой политики применяет действие по категории.
Например, для Googlebot — разрешить, для uptime monitor — разрешить, для RSS-читалки — применить ограничение скорости, для неопределённой автоматизации — применить недорогой challenge, для скрапера цен — ограничить или блокировать, для credential stuffing — блокировать и генерировать тревогу, для click fraud — блокировать и сообщать.
Это разделение обеспечивает операционную гибкость. Когда появляется новая категория AI-агентов, политику можно обновить, не переписывая движок обнаружения с нуля. При повышении чувствительности обнаружения поисковые системы не блокируются по ошибке. Разными категориями ботов можно управлять с разной скоростью.
Как измерить, работает ли ваше управление ботами?
Управление ботами — это не одноразовая настройка. По мере того как меняются злоумышленники, меняются и сигналы. Поэтому успех системы нужно непрерывно измерять по шести практическим метрикам.
Соотношение бот-человек по эндпоинту
Среднего по всему сайту самого по себе недостаточно. Эндпоинты входа, регистрации, оплаты, поиска, цен, запасов, API и контента нужно отслеживать по отдельности. Проблема ботов обычно концентрируется на определённых эндпоинтах. Доля ботов на эндпоинте оплаты и доля ботов на странице блога не относятся к одному уровню риска. Поэндпоинтный взгляд позволяет увидеть проблему в нужном месте.
Распределение по категориям ботов
Информация «есть X% бот-трафика» сама по себе не порождает действия. Важно распределение: сколько поисковых систем, сколько инструментов мониторинга, сколько скраперов, сколько credential stuffing, сколько AI-агентов, сколько неопределённой автоматизации. Если большая часть вашего бот-трафика идёт от поисковых систем — у вас одна проблема безопасности, если от трафика credential stuffing — совершенно другая.
Задержка обнаружения
Решения об обнаружении ботов должны приниматься быстро. Пользователь не должен ждать, пока система примет решение, в критических потоках вроде входа, оплаты или поиска. Даже задержки в миллисекунды могут влиять на пользовательский опыт в высоконагруженных приложениях. Практическая цель — чтобы механизм решения работал настолько быстро, что пользователь его не ощущает. TR7 Bot Management спроектирован так, чтобы принимать это решение с задержкой менее 5 мс.
Сигналы ложных срабатываний
Ложные срабатывания не видны только из панели безопасности. Реальные сигналы часто проявляются в обращениях в поддержку, жалобах пользователей, падениях воронки конверсии, росте неудачных входов или показателях отказа от оплаты. Отслеживание ложных срабатываний нельзя оставлять только на внутренних оценках движка обнаружения — его нужно вести вместе с метриками пользовательского опыта и бизнеса. Если бот-защита останавливает злоумышленника, но при этом останавливает и реального клиента, она не успешна.
Доля обхода
Одна из важнейших метрик, показывающих долгосрочное здоровье системы. Нужно отслеживать долю подтверждённых сессий враждебных ботов, достигающих защищённых действий — попыток входа, создания аккаунтов, покупок, чувствительных вызовов API, скачивания контента. Тренд важнее абсолютного числа. Если доля обхода стабильна, защита, возможно, поспевает за темпом злоумышленника. Если растёт — значит злоумышленники начали обходить текущие сигналы; нужны новые сигналы, настройка политики или более сильные средства контроля.
Стоимость на одну блокировку
Не каждая защита стоит одинаково. Сигнатурные средства контроля и сигналы IP/ASN могут работать в большом объёме с низкой стоимостью. Поведенческий анализ требует больше контекста. Тяжёлый ML-inference или глубокий анализ сессии следует использовать не для каждого запроса, а для точек принятия решений высокой ценности. Бот-защиту нужно выстраивать слоями — дешёвые сигналы на широком трафике, более дорогие анализы — на входе, оплате, создании аккаунтов, чувствительных API и действиях высокого риска. Верная метрика — не только «сколько ботов заблокировано?». Лучший вопрос: ценность атаки, которую мы заблокировали, выше стоимости защиты?
Одним из новых заголовков, усложняющих управление ботами в 2026 году, являются AI-агенты. Традиционное разделение ботов проводилось в основном между хорошим ботом и плохим ботом. Поисковая система — хорошо, credential stuffer — плохо. Однако AI-агенты размывают эту черту. AI-агент может заполнять форму от имени пользователя, исследовать товары, делать бронирование, сравнивать цены или завершать корпоративный рабочий процесс. В этом случае то, что трафик автоматический, само по себе не означает злого умысла. Здесь критичны идентичность и полномочия. Авторизованного AI-агента следует рассматривать не как анонимного бота, а как клиента, действующего от имени пользователя. А это объединяет управление ботами с контролем доступа. Должно быть чётко определено, от чьего имени он действует, какими разрешениями обладает, какие действия может выполнять и каким ограничениям скорости подчиняется. Из-за AI-агентов управление ботами теперь уже не только слой безопасности — оно становится моделью доступа, которую нужно продумывать вместе с идентичностью, политикой и опытом приложения.
Вывод: вместо CAPTCHA — сигнал, вместо блокировки — классификация
В 2026 году управление ботами нельзя вести по старым рефлексам.
CAPTCHA утратили эффективность как первичное средство контроля. Сети residential proxy сделали IP-репутацию недостаточной самой по себе. Headless-браузеры способны обходить простые проверки отпечатков. А AI-агенты делают невозможным объяснять автоматический трафик лишь категорией вредоносного бота.
В этой среде верный подход состоит из трёх частей: обнаружение по поведенческим и протокольным сигналам; классификация намерений по анализу потока сессии и payload'ов; политика, разграниченная по категории бота.
Так легитимному пользователю не показывается CAPTCHA. Необходимым ботам разрешается. Терпимые боты ограничиваются. Враждебные боты блокируются. А AI-агенты управляются в контексте идентичности и полномочий.
Цель современного управления ботами — не «уничтожить каждого бота». Цель — применить к каждому автоматическому трафику верное обращение.
Ссылки и источники
Годовое отраслевое измерение, документирующее, что в 2025 году доля ботов превысила 51%. https://www.imperva.com/resources/resource-library/reports/bad-bot-report/
Полный каталог автоматизированных угроз, включая credential stuffing (OAT-008), scraping (OAT-011), злоупотребление созданием аккаунтов (OAT-019). https://owasp.org/www-project-automated-threats-to-web-applications/
Современный набор TLS-отпечатков от FoxIO, пришедший на смену старому JA3, с более сильными возможностями кодирования. https://github.com/FoxIO-LLC/ja4
Ежеквартальные отчёты об угрозах о паттернах бот-трафика и трендах обнаружения. https://www.akamai.com/security-research/the-state-of-the-internet
Технические статьи об обнаружении residential proxy, поведенческом анализе и техниках отпечатка. https://blog.cloudflare.com/tag/bots/
Поведенческий отпечаток сильнее CAPTCHA
TR7 Bot Management совместно использует 46 взвешенных факторов обнаружения, включая поведенческий анализ паттернов, TLS- и HTTP/2-отпечаток, контекст IP/ASN, поток сессии и классификацию намерений. Решения спроектированы так, чтобы приниматься менее чем за 5 мс. Для легитимных пользователей он не создаёт трения CAPTCHA. А для враждебных ботов повышает стоимость, усиливает обнаружение и делает возможным реагирование на основе политики.
Изучить TR7 Bot Management