Как боты стали фактором риска для бизнес

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

В 2024 году половина всего интернет-трафика — это боты. Из них 18% — «хорошие» боты: поисковые и ИИ-краулеры. И 32% — «плохие» боты: вредоносные или нежелательные.

Ключевая проблема — рост числа «умных» ботов. Это уже не простые скрипты, а системы, имитирующие реальные пользовательские паттерны и обходящие классические механизмы защиты. Они проводят атаки на бизнес-функции: от сбора данных и парсинга цен до массовых регистраций, SMS-фрода или перехвата товарных остатков. Борьба с создателями таких ботов в каком-то смысле похожа на противостояние red и blue team. Ботоводы быстро адаптируются и эволюционируют под конкретные сервисы. Командам, отвечающим за безопасность, становится всё сложнее отличить поток легитимных запросов от автоматизированного, потому что умные боты мимикрируют под реальных пользователей на уровне поведения и технических сигнатур.

От простых скриптов к распределённым системам

Те, кто давно работает с защитой веб-проектов, помнят время, когда бот представлял простейший curl-запрос, а сигнатура по User-Agent, ограничение по IP или CAPTCHA решали проблему быстро и без особых усилий. Но по мере усиления защиты развивались и инструменты её обхода.

Сегодня боты — это распределённые инфраструктуры, headless-браузеры, антидетект-платформы, скрипты, имитирующие человеческое поведение, и алгоритмы машинного обучения, подстраивающиеся под реакцию системы защиты. Вокруг автоматизации сформировался полноценный рынок — команды разрабатывают ботов под заказ, поддерживают их, выпускают обновления, тестируют против популярных WAF и сервисов защиты. А как все начиналось? В начале 2010-х защиту часто строили на простых JavaScript-челленджах — достаточно было распарсить скрипт на Python, вычислить нужное значение и отправить корректный payload. С появлением Puppeteer (2017) ситуация изменилась: инструмент, задуманный как средство тестирования, оказался удобной базой для автоматизации, поскольку рендерил полноценный JavaScript, имел доступ к сенсорам и выглядел как настоящий Chrome. Через год вышел puppeteer-extra-stealth — набор техник, скрывающий признаки автоматизации. Этого было достаточно, чтобы обходить большинство ранних антибот-проверок. Дальше борьба пошла на уровне архитектуры. Появились проверки, которые анализируют DevTools-протокол: активированные домены вроде “runtime” и “network” меняют поведение браузера (например, добавляют заголовки, отключающие кэш). Антибот-системы стали отслеживать такие артефакты, а разработчики ботов — патчить библиотеки и браузеры, чтобы их скрывать. Параллельно развивались методы подмены фингерпринтов — WebGL, Canvas, особенности iFrame, различия в реализации JavaScript в разных платформах. Бот-инструменты научились корректировать эти параметры так, чтобы сгенерированные отпечатки выглядели статистически правдоподобными. CAPTCHA перестала быть надежным барьером. ML-модели распознают объекты на изображениях, автоматически решая задачи recaptcha и hcaptcha. Аудиоверсии капчи взламывались ещё несколько лет назад: современные нейросети делают это стабильно и быстро. Существуют библиотеки, способные воспроизводить реалистичные траектории движения мыши, проходя проверки второго уровня, связанные с микродвижениями курсора и паттернами кликов.

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

Как бот-трафик влияет на производительность, аналитику и устойчивость веб-сервисов

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

1. Рост нагрузки и расходов на инфраструктуру

Когда веб-приложение работает под нагрузкой до 500–700 RPS, а половина трафика оказывается паразитной, компания платит за то, что не приносит ей ни «живого» трафика, ни продаж.Особенно болезненно это проявляется у API-ориентированных продуктов с высокой частотой вызовов, у сервисов, где автоскейлинг реагирует на каждый пик нагрузки, а также у компаний, у которых любое увеличение трафика немедленно отражается в расходах на облако или SMS-шлюзы.

2. Искажение аналитики и управленческих решений

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

3. Фрод и прямые финансовые потери

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

Распространённые типы атак

Сегодня автоматизированные атаки на веб-сервисы укладываются в несколько устойчивых категорий. Несмотря на разные цели, их объединяет одно: каждая нагрузка выглядит «нормально» с точки зрения трафика, но системно вымывает ресурсы и искажает работу сервиса.

Скрапинг и парсинг

Скраперы системно обходят страницы, исполняют JavaScript, вытягивают каталоги, цены, остатки, расписания и другие коммерчески чувствительные данные. Парсеры работают точечно: извлекают конкретные элементы страниц, API-ответы или структурированные фрагменты контента. В связке они формируют полноценные инструменты конкурентного анализа. Вредоносные сценарии становятся агрессивными: используются headless-браузеры, антидетект, прокси-сети и частота запросов, сравнимая с живым пользователем. В e-commerce, travel и тикетинге такие боты могут обновлять данные чаще, чем собственный backend компании, создавая нагрузку и искажая аналитику.

Credential stuffing и автоматизация атак на личные кабинеты

Такие боты перебирают пары логин–пароль, используют базы утечек, эмулируют реальные устройства, управляют cookie-контекстом и обходят капчи с помощью ML. С ростом стоимости аккаунтов и бонусных баллов это направление стало системным и коммерчески мотивированным.

L7-DDoS и эксплуатация API.

Тонкие атаки уровня приложения, когда бот генерирует трафик, похожий на запросы легитимных пользователей. Нагрузка направляется на ресурсоёмкие ручки API, эндпоинты со сложной бизнес-логикой или тяжёлые страницы. Это вызывает пиковые скачки CPU, «вымывание» лимитов, автоскейлинг и рост инфраструктурных затрат. При этом трафик внешне выглядит валидным.

SMS-бомбинг

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

Скальпинг.

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

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

Митигировать, но не навредить пользователю

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

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

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

• поведенческая аналитика;
• ML-модели профилирования;
• эвристические признаки;
• частотные анализы и сигнатуры;
• корреляция запросов.

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

Практика: как это выглядит на реальных проектах

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

Кейс 1. Когда скрапперы занимают до 60% трафика

Компания столкнулась с парадоксом: по всем метрикам рост трафика выглядел позитивно, но инфраструктура оказалась под постоянной нагрузкой около 400–580 RPS.
Паттерны были характерными:

• линейный обход страниц пагинации с минимальными интервалами;
• отсутствие типичного поведения (скроллинга, кликов по сопутствующим элементам);
• запросы шли с ротирующихся IP-адресов, но с идентичными User-Agent и отпечатками браузера;
• скорость перехода между страницами была аномально высокой: реальный пользователь физически не успел бы обработать контент.

После анализа выяснилось, что до 60% трафика — это скрапперы, которые системно выгружали каталог.
Скраппер использовал headless Chrome с реальными браузерными fingerprints — формально это был «настоящий» браузер, выполняющий JavaScript. Он даже рендерил страницы и собирал данные из DOM после всех асинхронных подгрузок. Первые попытки блокировки по User-Agent и простым rate limits он обошёл буквально за 2-3 часа, добавив случайные задержки между запросами и ротацию заголовков. Скраппер делал вид, что «читает» контент — добавлял случайные паузы от 3 до 15 секунд между переходами, имитируя человеческое поведение. Но детальный анализ показал, что паузы были слишком равномерно распределены (настоящие люди ведут себя менее предсказуемо), а главное — отсутствовали любые вспомогательные запросы: никаких обращений к статике при скролле, запросов на рекомендации или кликов по фильтрам.

Для решения этой задачи мы внедрили многоуровневую защиту, в которую входили:

• анализ поведенческих сигналов (скорость навигации, паттерны кликов, движение мыши);
• fingerprinting для выявления автоматизированных клиентов, маскирующихся под браузеры,
• challenge-решения для подозрительных сессий без влияния на UX легитимных посетителей.

В результате внедрения:

• трафик был снижен на 35%,
• RPS упал до 270,
• при этом легитимные пользователи не пострадали.

Для бизнеса это означало не только снижение нагрузки, но и экономию на масштабировании.

Кейс 2. SMS-фрод и массовые регистрации

У другого нашего клиента проблема проявлялась циклично: всплески активности, массовые регистрации, увеличивающиеся расходы на SMS. Детальный разбор показал, что запросы на отправку SMS шли сериями с близкими временными метками, использовались сервисы виртуальных номеров и временных email, IP-адреса принадлежали датацентрам и прокси-провайдерам, а не обычным ISP. TLS-fingerprints и HTTP-заголовки указывали на автоматизированные HTTP-клиенты, а не реальные браузеры. Время между заполнением полей формы было нереалистично коротким — около 100-200мс на поле. Атака не была очевидной, потому что мы столкнулись с распределенным ботнетом, который работал волнами. Вместо того, чтобы атаковать с одного IP, злоумышленники использовали пулы из нескольких тысяч адресов, каждый из которых делал 2-5 регистраций в час. И формально это выглядело как легитимная активность.

После включения митигации:

• удалось блокировать до 80% автоматизированных запросов,
• существенно сократить затраты на SMS,
• уменьшить общий объём паразитного трафика.

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

Вывод: боты стали фактором, которым нужно управлять

Автоматизированный бот-трафик сегодня — это самостоятельная экосистема, которая влияет на устойчивость бизнеса, на точность аналитики и на финансовый результат. Опыт показывает, что системный подход может снизить паразитный трафик на 30–80%, одновременно улучшив производительность и снизив риски. Но главное — это умение отличать вредоносные боты от легитимных, не мешая пользователю. Мы в NGENIX набили кучу шишек, пока исследовали, как точнее митигировать бот-атаки и распознавать нежелательных ботов. Подробнее расскажем про наш путь и поделимся экспертизой 12 декабря на онлайн-конференции ICEBREAKER 2025.