Защита сайта от ботов: шесть лет практики фильтрации трафика
Практика работы с аномальным трафиком началась для меня в 2020 году, когда я занимался веб-разработкой и поисковым продвижением. В один момент привычная статистика сайта изменилась: в отчётах появились десятки однотипных визитов из социальных сетей. Ежедневно фиксировалось примерно 30-60 "посетителей", однако их поведение не имело ничего общего с действиями реальных пользователей.
Вебвизор и другие отчёты показывали повторяющиеся сценарии: одинаковая глубина просмотра, почти синхронные действия, нулевая вовлечённость и странная география. При этом прежний органический и прямой трафик выглядел совершенно иначе. Ситуация требовала не косметической настройки аналитики, а полноценного анализа источника запросов и способов фильтрации.
2020-2021: первые поведенческие боты
На раннем этапе основной задачей было противодействие искусственной накрутке поведенческих факторов. Тогда многие специалисты считали такой трафик безвредным или даже полезным для сайта. Однако наблюдения на разных проектах давали другую картину: появление большого количества неестественных визитов часто совпадало с ухудшением позиций и снижением качества органического трафика.
Первым очевидным решением выглядела блокировка запросов по значению Referer. Если подозрительные визиты приходили из определённых социальных сетей, казалось логичным ограничить соответствующий источник. На практике этот метод оказался слишком примитивным. Заголовок Referer легко подделывается, скрывается или заменяется, поэтому он не может служить надёжным идентификатором посетителя.
Следующим шагом стала проверка JavaScript и cookie на стороне сервера. Такой подход действительно изменил статистику: часть простейших автоматизированных клиентов перестала проходить фильтр. Но поток аномальных запросов не исчез. Боты начали имитировать выполнение сценариев, сохранять cookies и воспроизводить базовые действия браузера.
Некоторое время полезными казались две отдельные подсети, из которых поступала значительная часть подозрительных обращений. Их блокировка дала кратковременный результат, однако вскоре источники изменились. Особенно наглядно проблему продемонстрировал IPv6: большое количество адресов сделало бессмысленной попытку поддерживать постоянный список "плохих IP".
Почему одиночные признаки не работают
За шесть лет стало очевидно: практически любой отдельный технический признак можно изменить. IP-адрес меняется через прокси и мобильные сети, User-Agent подменяется, Referer редактируется, cookies генерируются автоматически, а поведение сценария имитируется браузерной автоматизацией.
Цифровой отпечаток также не является паспортом пользователя. Он способен помочь при анализе, но не гарантирует точной идентификации. Одинаковые браузеры и устройства могут иметь близкие характеристики, а один и тот же бот способен менять часть параметров между запросами.
Отдельная ошибка - считать, что скрытие ботов в системе аналитики решает проблему. Скрипт, который не отправляет данные о подозрительном визите в Метрику или другую систему статистики, только очищает отчёты. Сам бот при этом продолжает обращаться к серверу, расходовать ресурсы, собирать информацию и создавать нагрузку.
Фильтры аналитических платформ полезны для построения отчётов, но не заменяют сетевую защиту. Реальное ограничение трафика должно происходить до обработки запроса приложением - на уровне CDN, reverse proxy, веб-сервера или специализированного шлюза.
2022-2024: развитие правил Cloudflare
На следующем этапе основным инструментом стала ручная настройка правил фильтрации в Cloudflare. Штатных проверок оказалось недостаточно: они хорошо отсекали очевидные автоматизированные запросы, но хуже справлялись с распределёнными и имитирующими поведение ботами.
Постепенно набор правил превратился из нескольких простых блокировок в систему сценариев. Для разных типов трафика применялись разные действия: пропуск, проверка, ограничение частоты, временная блокировка или полный отказ. Анализировались не только IP-адрес и User-Agent, но и частота обращений, последовательность URL, методы запросов, наличие заголовков, cookies, характеристики TLS-соединения и реакция клиента на проверки.
Blacklist при этом постоянно увеличивался, но его ценность снижалась. Адреса быстро менялись, а чрезмерное расширение списка повышало риск заблокировать обычных пользователей. Главной проблемой стала не только точность распознавания, но и цена ложного срабатывания. Ошибочная блокировка поискового робота, клиента с нестандартным браузером или посетителя из корпоративной сети могла оказаться дороже, чем пропущенный подозрительный запрос.
К 2024 году Cloudflare перестал восприниматься как готовая защита "из коробки". Он стал инфраструктурной средой, в которой приходилось реализовывать собственную логику оценки трафика. Сервис предоставлял необходимые технические возможности, однако качество результата зависело от архитектуры правил, их последовательности и регулярного пересмотра.
2025 год: переход к собственной системе
В 2025 году ограничения доступности зарубежных сервисов в России сделали зависимость от одной внешней платформы особенно заметной. Начался переходный период: тестировались российские решения защиты, сравнивались их возможности, стабильность, гибкость правил и пригодность для разных типов сайтов.
Практика показала, что универсальной замены в формате "подключил и забыл" не существует. Одни продукты хорошо справлялись с массовыми атаками, но предлагали мало возможностей для тонкой настройки. Другие давали расширенную аналитику, однако требовали сложной интеграции или не позволяли учитывать специфику конкретного проекта.
В результате появилась идея собственной многоуровневой системы CronArmor. Её задача - не просто разделять запросы на "хорошие" и "плохие", а оценивать контекст обращения и накапливать признаки во времени.
Почему одной защиты для всех сайтов недостаточно
Разные сайты имеют разные модели поведения. Для интернет-магазина нормальны частые обращения к карточкам товаров и API, для корпоративного сайта - редкие просмотры страниц, а для медиа-проекта - большое количество последовательных переходов. Один и тот же шаблон фильтрации может быть безопасным для одного ресурса и разрушительным для другого.
Поэтому CronArmor не строится как универсальная кнопка. Для каждого проекта требуется собственный профиль: учитываются популярные разделы, допустимая частота запросов, тип аудитории, наличие личного кабинета, публичного API, поисковых роботов и интеграций.
Современная защита должна как минимум различать несколько классов трафика:
- обычных пользователей;
- поисковых роботов;
- авторизованных клиентов;
- системные интеграции и API;
- браузерную автоматизацию;
- сканеры и сборщики контента;
- нагрузочные и распределённые атаки;
- поведенческих ботов, имитирующих реального посетителя.
От TLS-отпечатка к анализу клиентской среды
TLS-fingerprint, включая семейство подходов JA3 и JA4, полезен для группировки клиентов, но не является постоянным идентификатором. Отпечаток можно изменить с помощью другой библиотеки, прокси, браузера или промежуточного сервиса. Поэтому его нельзя использовать как единственное основание для блокировки.
Более надёжный результат даёт совокупная оценка клиентской среды. В неё могут входить параметры TLS, HTTP-заголовки, поддерживаемые протоколы, порядок обращений, работа JavaScript, cookies, особенности сессии и временная динамика запросов. Важен не отдельный параметр, а согласованность всей картины.
Даже невидимая проверка не решает задачу полностью. Если фильтр незаметен для пользователя, автоматизированный клиент может пройти его вместе с легитимным браузером. Если проверка слишком агрессивна, пострадают реальные посетители. Поэтому защиту приходится строить ступенчато: сначала применять мягкие признаки, затем усиливать меры только при накоплении подозрительных сигналов.
Кластерная аналитика трафика
Одно из ключевых направлений развития - анализ не отдельных запросов, а групп похожих обращений. В кластер могут объединяться визиты с близкими IP-диапазонами, одинаковыми отпечатками, совпадающими последовательностями URL, синхронным временем активности или похожей реакцией на проверки.
Такой подход помогает обнаруживать распределённую инфраструктуру, даже если каждый отдельный адрес выглядит относительно безобидно. Например, десятки тысяч IP могут обращаться к сайту с одинаковым интервалом, одной и той же глубиной просмотра и повторяющимся набором страниц. По отдельности эти признаки слабы, но в совокупности образуют характерный профиль.
Важна и временная составляющая. Повторяющиеся всплески, одинаковые окна активности, резкое появление новых адресов после блокировки предыдущих и массовая смена User-Agent могут указывать на управляемую сеть автоматизированных клиентов.
Как выстроить защиту на практике
Эффективная система обычно включает несколько уровней:
1. Сетевой уровень - ограничение очевидно вредных адресов, подсетей, странных протоколов и массовых всплесков.
2. Уровень частоты - контроль количества запросов от IP, сессии, подсети или группы похожих клиентов.
3. Проверка клиента - анализ JavaScript, cookies, заголовков и реакции на challenge.
4. Поведенческий уровень - оценка маршрута пользователя, времени между действиями и повторяемости сценариев.
5. Прикладной уровень - отдельные правила для API, форм, авторизации, поиска и административных разделов.
6. Аналитический уровень - накопление статистики, пересмотр правил и поиск новых кластеров.
Режим блокировки не всегда должен включаться сразу. Для новых признаков разумно использовать сначала наблюдение или ограничение скорости. Это позволяет понять масштаб проблемы и оценить риск ложных срабатываний.
Итоги шести лет
За период с 2020 по 2026 год подход к защите сайтов изменился принципиально. Сначала казалось, что достаточно найти источник переходов, заблокировать несколько IP или скрыть подозрительные визиты из аналитики. Затем стало ясно, что современные боты быстро меняют отдельные признаки и способны имитировать базовое поведение пользователя.
Главный вывод практики - невозможно построить надёжную защиту на одном параметре. Нужна многоуровневая система, которая учитывает технические характеристики соединения, поведение, частоту запросов, контекст сайта и взаимосвязи между группами клиентов.
Фильтрация должна защищать не только статистику, но и сервер, приложение, бюджет рекламных кампаний, поисковые показатели и реальные пользовательские сценарии. Именно переход от простого blacklist к кластерной аналитике и адаптивным профилям стал наиболее важным результатом этого периода.