Бизнес против ботов: как защитить сайт от скликивания, парсинга цен и автоматизированных атак

Илья Самылов, руководитель команды сопровождения сервисов информационной безопасности NGENIX
Автоматизированный трафик давно перестал быть проблемой, которую можно решить блокировкой подозрительного IP или использованием CAPTCHA. Боты научились имитировать действия пользователей, менять IP-адреса, работать через полноценные браузеры и взаимодействовать с бизнес-логикой сайтов. При этом развитие искусственного интеллекта одновременно усложняет борьбу с нежелательной автоматизацией и приводит на сайты новый легитимный трафик — ИИ-краулеров и агентов. Разбираемся, как изменились боты, какой ущерб они наносят бизнесу и почему современная защита должна не блокировать автоматизацию как таковую, а понимать, кто, как и зачем обращается к веб-ресурсу.
Когда сайт работает, но бизнес теряет деньги
Бот-активность не всегда сопровождается очевидными признаками атаки. Веб-ресурс может продолжать работать штатно, а автоматизированный трафик будет выглядеть почти так же, как действия обычных пользователей. Поэтому проблема нередко обнаруживается по косвенным признакам: росту нецелевого трафика и нагрузки на инфраструктуру, увеличению расходов на внешние сервисы или аномалиям в бизнес-метриках.
При этом последствия такого вмешательства могут напрямую отражаться на расходах и бизнес-показателях. Боты собирают цены и другие коммерчески значимые данные, массово заполняют формы, инициируют отправку SMS, регистрируют аккаунты, резервируют товары и билеты, перебирают пары логин-пароль. Они могут кликать по рекламным объявлениям, расходуя рекламный бюджет без привлечения реальных клиентов, или создавать искусственную активность, которая искажает бизнес-аналитику.
Поэтому проблема бот-трафика находится на стыке информационной безопасности, ИТ и экономики цифрового бизнеса. Компания оплачивает вычислительные мощности и внешние сервисы, которые обслуживают автоматизированные запросы, маркетинг получает искаженные показатели, а пользователи могут сталкиваться с последствиями вмешательства ботов в бизнес-процессы.
По сводным данным NGENIX за 2025 год, на защищаемых веб-ресурсах 43% трафика классифицировалось как бот-активность. При этом только 6% приходилось на публичных и легитимных ботов — например, поисковые системы и ИИ-краулеры. Оставшаяся часть представляла собой нелегитимный либо подозрительный автоматизированный трафик, который требовал дополнительной проверки.
Но сама по себе доля ботов еще мало говорит о характере угрозы. Гораздо важнее понять, что именно автоматизация делает на конкретном сайте и какой бизнес-процесс использует.
Многообразие способов навредить
Часто сценарий злоумышленников зависит от того, на чем зарабатывает веб-ресурс и какие функции доступны пользователю. Для интернет-магазина одной из наиболее чувствительных проблем становится автоматизированный сбор данных. Парсеры могут последовательно обходить каталог, получать информацию о ценах, остатках и ассортименте и использовать ее, например, для конкурентного анализа. Современный парсер при этом совсем не обязательно будет отправлять тысячи однотипных запросов с одного адреса. Он может работать через headless-браузер, исполнять JavaScript, менять IP-адреса и заголовки и выдерживать паузы между переходами, имитируя чтение страниц человеком.
У одного из клиентов NGENIX до 60% трафика составляли скрапперы, которые системно выгружали каталог. Автоматизация использовала headless Chrome, выполняла JavaScript и получала данные из DOM после асинхронных загрузок. Простые ограничения по User-Agent и частоте запросов удалось обойти за несколько часов: скраппер начал менять заголовки и добавлять случайные задержки. Выдала его уже совокупность поведенческих признаков, в частности, отсутствие действий, характерных для обычного посетителя сайта. После внедрения многоуровневой защиты общий трафик удалось снизить на 35%, а нагрузку – примерно с 400–580 до 270 RPS без ущерба для легитимных пользователей.
Другой распространенный сценарий: злоупотребление формами и функциями сайта. Форма регистрации, обратной связи, восстановления пароля или получения одноразового кода сама по себе работает именно так, как задумано разработчиками. Проблема возникает, когда вместо человека ей начинает пользоваться автоматизированная система в промышленных масштабах.
Например, боты могут создавать тысячи регистраций и инициировать отправку SMS-кодов. В одном из исследованных нами случаев запросы поступали волнами с нескольких тысяч адресов, причем каждый IP выполнял всего несколько регистраций в час. Поэтому обычный rate limit по отдельному адресу не показал бы явной аномалии. При анализе обнаружились другие признаки: использование виртуальных номеров и временных почтовых сервисов, нетипичные HTTP-клиенты и нереалистично быстрое заполнение полей формы — порядка 100–200 мс на одно поле. После включения митигации удалось блокировать до 80% автоматизированных запросов и существенно сократить расходы на SMS.
Схожая логика работает и в случае спама через формы обратной связи. Если оценивать отдельный запрос, он может быть абсолютно корректным: бот заполняет предусмотренные поля и нажимает предусмотренную разработчиком кнопку. Отличие проявляется в масштабе, последовательности действий, технических характеристиках клиента и поведении сессии.
Скликивание рекламы относится к той же группе экономически мотивированной автоматизации. Цель здесь не обязательно заключается в нарушении доступности сайта. Бот воспроизводит действие, за которое бизнес платит, но за кликом нет потенциального клиента. В результате рекламный бюджет расходуется на искусственную активность, а статистика рекламных кампаний смешивает действия реальной аудитории с автоматизированными.
Именно поэтому смотреть на бот-трафик исключительно как на разновидность классической атаки не всегда полезно. Во многих сценариях бот не «ломает» функцию веб-приложения, а массово использует ее штатным способом в целях, для которых она не предназначалась. В нашей практике эта особенность прослеживается и в других сценариях: SMS-фроде, скальпинге, credential stuffing, злоупотреблении бонусными программами и при высокочастотных обращениях к API.
Почему сегодня сложно заблокировать бота
Еще несколько лет назад значительную часть автоматизации можно было обнаруживать относительно простыми средствами. Если сотни запросов приходили с одного IP-адреса или клиент имел характерный User-Agent, источник было несложно идентифицировать. Сегодня ботоводы стараются не использовать такие очевидные сценарии.
Для распределения запросов используются большие пулы IP-адресов и residential proxy – адреса обычных домашних или мобильных пользователей. Автоматизация работает через headless- и headed-браузеры, воспроизводит задержки между действиями, клики, перемещения курсора и последовательности переходов по страницам. Параллельно подделываются характеристики браузера и устройства: User-Agent, viewport, Canvas/WebGL-отпечатки, язык, часовой пояс и другие параметры.
Поэтому блокировка только по IP постепенно теряет эффективность. То же относится к попытке принять решение по одному браузерному отпечатку. В ходе исследований NGENIX выяснилось, что боты способны подменять browser fingerprint и canvas fingerprint, поскольку оппонент контролирует среду, в которой выполняется проверка. Следовательно, надежнее собирать данные из разных источников и оценивать их совместно.
Не является универсальным решением и JavaScript Challenge. Разработчики автоматизации могут провести реверс-инжиниринг проверки и научить бота получать необходимый результат вне обычного пользовательского сценария. CAPTCHA тоже перестала быть непреодолимым барьером: современные модели ИИ способны решать стандартные визуальные задачи, на которых традиционно строилась такая проверка. Поэтому мы отдельно тестировали другой подход: анализ не только правильности решения задачи, но и того, как именно пользователь ее решает, собирая в процессе дополнительные поведенческие сигналы.
Получается, что определить автоматизацию по одному техническому признаку становится все сложнее. Решение приходится принимать по совокупности характеристик запроса, клиента и его поведения.
ИИ меняет игру в «кошки-мышки»
Развитие искусственного интеллекта добавляет проблеме еще одно измерение. С одной стороны, ИИ расширяет возможности разработчиков нежелательной автоматизации. Он помогает совершенствовать алгоритмы обхода защитных механизмов, адаптировать поведение к меняющимся фильтрам и точнее имитировать действия пользователя. В результате снижается порог создания более сложных автоматизированных сценариев, а привычные проверки быстрее устаревают. Мы рассматриваем развитие генеративного ИИ как один из факторов, заметно расширивших возможности современных ботов.
С другой стороны, само появление ИИ-сервисов увеличивает объем автоматизированного трафика, который нельзя автоматически считать вредоносным. Поисковые роботы давно сканируют сайты для индексации. Теперь рядом с ними работают ИИ-краулеры, которые получают контент для использования ИИ-системами. Появляются и ИИ-агенты – более автономные системы, способные не только получить информацию со страницы, но и выполнить на ее основе последовательность действий. Например, агент может найти цены, сравнить предложения, отследить изменение стоимости и перейти к формированию заказа.
Для бизнеса это создает нетривиальную дилемму. Полностью закрыть сайт от ИИ-ботов значит потенциально ограничить новый канал распространения контента. Открыть его для любой автоматизации – потерять контроль над тем, кто и с какой интенсивностью собирает данные и какие действия выполняет.
Поэтому само понятие «защита от ботов» постепенно меняется. Задача заключается уже не в том, чтобы доказать, что перед нами бот, и автоматически его заблокировать. Необходимо определить тип автоматизации, ее поведение и допустимость конкретного сценария для бизнеса. Решение о том, какие поисковые и ИИ-боты допускать к ресурсу, а какие ограничивать, должно зависеть от задач владельца сайта. Такой подход позволяет учитывать одновременно требования безопасности, нагрузку на инфраструктуру и задачи продвижения.
Не «бот или человек», а контекст поведения
Представим два автоматизированных клиента. Первый – известный поисковый робот, который индексирует открытые страницы. Второй – парсер, последовательно выгружающий весь каталог и создающий значительную нагрузку. Оба являются ботами, но одинаковая реакция на них не соответствует интересам бизнеса.
Обратная ситуация тоже возможна. Один IP-адрес может принадлежать обычному пользователю, а тысячи адресов – одному распределенному ботнету. Поэтому схема «много запросов с одного IP – блокируем» уже не описывает реальную картину.
На практике приходится одновременно учитывать технические и поведенческие признаки. В NGENIX входящий трафик разделяется на четыре категории: «публичный бот», «вероятно бот», «точно бот» и «вероятно человек». Такое разделение позволяет не принимать бинарное решение там, где имеющихся данных недостаточно.
Для веб-трафика могут применяться разные проверки. Compute позволяет незаметно для пользователя отсеивать примитивную автоматизацию. CSS-проверка анализирует корректность обработки стилей браузером. CAPTCHA остается дополнительным инструментом для отдельных критичных сценариев или случаев, когда неинтерактивных проверок недостаточно.
При работе с API и мобильными приложениями подход отличается: привычные браузерные проверки там неприменимы. Поэтому приходится анализировать отклонения от нормального поведения и при этом отличать нежелательную автоматизацию от естественных всплесков трафика, например, после запуска рекламной кампании.
В результате защита превращается не в статический набор запретов, а в постоянный процесс наблюдения за трафиком. Боты адаптируются к митигации, меняют технические характеристики и сценарии поведения, поэтому настройки защиты тоже приходится корректировать по мере изменения картины.
Как понять, что проблема уже есть
Самый очевидный признак бот-активности – резкий всплеск запросов – далеко не единственный и не самый интересный. Продвинутая автоматизация, наоборот, старается такого всплеска не создавать. Поводом для анализа может стать ситуация, когда технические или бизнес-показатели перестают соответствовать друг другу. Например, растет количество регистраций, но не меняется конверсия. Увеличивается посещаемость каталога, но это не отражается на продажах. Растут расходы на SMS. Инфраструктура масштабируется под увеличившийся RPS, хотя число реальных клиентов остается прежним. Формы обратной связи получают больше обращений, но значительная их часть не имеет бизнес-ценности.
При этом бот-трафик способен искажать не только операционные расходы, но и саму картину бизнеса. Автоматизированные клиенты проходят воронки, открывают страницы, кликают по элементам интерфейса и создают регистрации. Если их действия не отделены от поведения людей, продуктовые и маркетинговые команды начинают анализировать смешанный поток и могут принимать решения на основании метрик, которые не отражают реальный спрос.
Поэтому первый этап защиты не агрессивная блокировка, а наблюдаемость. Нужно понять, какая часть трафика автоматизирована, какие функции сайта она использует, как распределена по времени и источникам и какую долю составляют известные легитимные системы. Только после этого имеет смысл выбирать способ митигации.
Почему одного средства защиты недостаточно
Практика показывает, что универсального признака, по которому можно безошибочно отделить человека от современного бота, нет. IP-адрес можно сменить. User-Agent – подделать. Fingerprint – модифицировать. JavaScript Challenge – исследовать и научиться обходить. CAPTCHA – решить с помощью автоматизации. Слишком жесткий rate limiting, в свою очередь, способен затронуть реальных пользователей.
Поэтому эффективная защита строится на корреляции разных сигналов: технических характеристик клиента, поведения сессии, последовательности запросов, частотных показателей и аномалий относительно нормальной модели работы конкретного приложения. Именно совокупность признаков позволяет увидеть то, что незаметно на уровне отдельного HTTP-запроса.
При этом чем жестче митигация, тем выше цена ошибки. False positive для интернет-магазина может означать потерянную покупку, для финансового сервиса – невозможность выполнить операцию, для другого онлайн-сервиса – ухудшение пользовательского опыта. Поэтому задача антибот-защиты состоит не в максимальном количестве блокировок, а в том, чтобы остановить именно нежелательную автоматизацию, не затронув пользователей и разрешенные автоматизированные системы.
У нас был кейс с клиентом из финансовой сферы, где после анализа около 30–40% запросов были отнесены к категории «вероятно бот», однако блокировать весь этот объем не стали. Проверки применялись к подозрительному трафику, а известные партнерские API, банковские приложения и другие разрешенные интеграции исключались из них. В результате стабильно блокировалось 5–10% бот-трафика (именно та часть, которая представляла риск) без влияния на легитимных пользователей и автоматизированные процессы.
От борьбы с ботами к управлению автоматизированным трафиком
Скликивание рекламы, сбор цен конкурентами и спам через формы обратной связи кажутся разными проблемами. Технически их объединяет одно: бизнес предоставляет пользователю определенную функцию, а автоматизация начинает использовать ее в чужих интересах и в масштабе, на который эта функция не рассчитана.
Именно поэтому бот может наносить ущерб, не взламывая сайт и не делая его недоступным. Он использует разрешенные действия: открывает страницу, нажимает кнопку, отправляет форму, запрашивает код, кладет товар в корзину. Однако с экономической точки зрения – каждое такое действие несет потери компании.
На фоне развития генеративного искусственного интеллекта Интернет еще быстрее движется к миру, где автоматизированных клиентов становится больше и их функции разнообразнее. Рядом с парсерами, скальперами и инструментами фрода работают поисковые роботы, партнерские интеграции, ИИ-краулеры и агенты, доступ которых может быть полезен самому владельцу ресурса.
Поэтому зрелая стратегия защиты начинается не с вопроса «как заблокировать ботов?», а с трех других: кто обращается к ресурсу, что он на нем делает и соответствует ли это интересам бизнеса.
Ответы на них позволяют перейти от бесконечной блокировки отдельных IP и сигнатур к управлению автоматизированным трафиком: пропускать полезные системы, дополнительно проверять сомнительные и ограничивать ту автоматизацию, которая расходует ресурсы, искажает данные или вмешивается в бизнес-процессы.
И, вероятно, именно способность проводить эту границу будет становиться все важнее по мере того, как отличить автоматизированного клиента от человека технически становится сложнее, а самих легитимных сценариев автоматизации больше.



