Как мы усилили защиту bot-guard.ru от ботов: путь от списка User-Agent до поведенческого анализа

Почему боты стали проблемой номер один для любого сайта

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

Отдельная история — DDoS-атаки, которые маскируются под легитимных поисковых роботов. Представьте: тысячи запросов с подменённым User-Agent «Googlebot» одновременно обращаются к вашему серверу. Сервер честно пытается обработать их, тратит ресурсы на генерацию страниц, и в итоге падает. Реальные пользователи получают ошибку 503. Аналитика в этот момент показывает всплеск «поискового трафика», хотя на деле это атака на отказ в обслуживании. Проблема усугубляется тем, что простые методы защиты, основанные на блокировке по IP или анализе User-Agent, здесь уже не работают.

Раньше казалось, что достаточно закрыть самые очевидные дыры. Но боты эволюционируют быстрее, чем появляются типовые решения. Они используют реальные IP-адреса мобильных операторов, подделывают заголовки запросов, имитируют поведение человека в браузере. Поэтому мы в bot-guard пересмотрели подход к защите и расскажем, как именно мы это сделали.

Как это работало раньше: ловушка для наивных скриптов

Первоначальная версия нашей защиты строилась на простом, но логичном предположении: у каждого бота есть строка User-Agent. У Googlebot она одна, у Яндекса — другая, у скрипта для парсинга — третья. Мы собрали базу из сотен тысяч известных строк, вычислили хэш от каждой и сохранили в базе. Каждый входящий запрос к сайту проходил проверку: сервер смотрел на User-Agent, вычислял его хэш, сверял с базой и принимал решение — пропустить посетителя, заблокировать известного бота или заблокировать подделку под известного бота.

Схема работала против примитивных скриптов, которые честно представлялись своими именами вроде «Python-urllib» или «curl». Но только до тех пор, пока боты не научились притворяться людьми. Любой школьник, написавший скрипт на Python, может подставить в заголовок запроса строку Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36. Это строка настоящего браузера Chrome. Наша система видела её, сверяла с базой, находила совпадение с «обычным посетителем» и пропускала запрос. Всё. Защита пала.

Мы понимали это ограничение. Хуже того, мы видели в логах, как один скрипт с одного IP-адреса отправлял по 100 запросов в секунду, и каждый из них проходил проверку, потому что User-Agent был подделан под Chrome. Система честно считала его «обычным пользователем». Это было не просто слабое место — это была дверь нараспашку для любого мало-мальски соображающего злоумышленника. Нужно было что-то менять кардинально.

Как мы усилили защиту: многослойный подход вместо одной проверки

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

Проверка настоящих поисковых ботов через FCrDNS

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

Когда запрос представляется как Googlebot или YandexBot, мы не верим строке User-Agent. Вместо этого мы выполняем обратный DNS-запрос: узнаём, какому домену принадлежит IP-адрес, с которого пришёл запрос. Если это IP от Google, обратный DNS покажет что-то вроде crawl-66-249-65-1.google.com. Затем мы делаем прямой DNS-запрос: узнаём IP-адрес этого домена и сверяем его с исходным IP. Если они совпадают — перед нами настоящий бот, и мы пропускаем его без каких-либо дополнительных проверок. Если не совпадают — это подделка, и такой запрос блокируется мгновенно.

Этот механизм называется FCrDNS (Forward-Confirmed Reverse DNS). Он работает безошибочно, потому что подделать записи DNS на стороне Google или Яндекса невозможно. В результате мы закрыли целый класс атак, когда злоумышленники маскировались под поисковых роботов, чтобы обойти защиту или провести DDoS-атаку. Настоящие боты проходят без задержек, а подделки отсекаются на уровне сетевой инфраструктуры.

Определение IP-адресов датацентров и облачных провайдеров

Живой человек, сидящий дома или в офисе, выходит в интернет через IP-адрес своего провайдера. У него нет причин использовать IP-адрес облачного сервера. Если мы видим, что «посетитель» приходит с IP-адреса, принадлежащего Google Cloud, AWS, Hetzner, Azure или другому облачному провайдеру, это почти наверняка скрипт, а не человек. Но здесь есть нюанс: сотрудники некоторых компаний работают через корпоративный VPN, который как раз находится в облаке. Жёстко блокировать такие IP — значит рисковать потерей реальных посетителей.

Поэтому мы действуем тоньше. Для запросов с IP датацентров мы не блокируем доступ сразу, а запускаем тихую проверку через JavaScript. Настоящий браузер выполняет JavaScript автоматически, и пользователь даже не замечает этой проверки. Простой HTTP-скрипт, который просто отправляет GET-запросы, не умеет выполнять JavaScript. Он получает ответ, но не проходит проверку и не получает доступ к контенту сайта. Для человека всё прозрачно, для бота — непреодолимая преграда.

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

Отдельный переключатель для IPv6-адресов

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

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

Анализ заголовков запроса: сигнал, который сложно подделать

Есть одна закономерность, которую мы заметили, анализируя логи легитимных запросов. Настоящий браузер, будь то Chrome, Firefox или Safari, почти всегда отправляет заголовок Accept-Language. Это естественное поведение: браузер сообщает серверу, на каком языке пользователь хочет видеть страницу. Примитивный скрипт-бот, написанный на Python или Node.js, этот заголовок не отправляет. Ему не нужен язык, ему нужны данные.

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

В сочетании с другими механизмами этот анализ заголовков позволяет отсеять значительную часть примитивных ботов ещё до того, как они начнут что-то запрашивать.

Универсальная защита от перебора (rate-limit)

Большинство готовых решений защищают от перебора только форму входа в админку. Но боты атакуют не только её. Они перебирают параметры поиска на сайте, пытаются подобрать ID заказов, сканируют страницы на наличие уязвимостей. Поэтому мы сделали защиту от перебора универсальной: она работает для любого типа запросов на сайте.

Механизм работает так: мы отслеживаем частоту запросов с каждого IP-адреса. Если с одного адреса приходит слишком много запросов за короткий промежуток времени, мы не блокируем его жёстко (это рискованно для офисных сетей, где десятки сотрудников выходят в интернет через один «белый» IP). Вместо этого мы включаем для этого IP временную мягкую проверку. Посетитель с этого адреса получает JavaScript-проверку, которую настоящий браузер проходит автоматически. Если же запросы продолжают идти от скрипта, который не выполняет JavaScript, он получает отказ.

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

Защита форм обратной связи от спама

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

Первый уровень — невидимые ловушки (honeypot-поля). Мы добавляем в форму скрытые поля, которые человек не видит и не заполняет. Бот, который автоматически заполняет все поля формы, заполняет и эти скрытые поля. Когда сервер получает запрос с заполненным honeypot-полем, он с высокой вероятностью понимает, что это бот, и отклоняет запрос, не отправляя сообщение. Человек даже не замечает, что форма сработала неправильно, но спам не проходит.

Второй уровень — проверка скорости заполнения формы. Человек физически не может заполнить форму за одну секунду. Ему нужно прочитать поля, ввести текст, нажать кнопку. Бот делает это мгновенно. Мы замеряем время между загрузкой страницы с формой и отправкой запроса. Если это время меньше определённого порога (например, меньше двух секунд), мы считаем, что запрос отправлен не человеком, и запускаем дополнительную проверку.

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

Прозрачная статистика: вы видите, от чего мы защищаем

Раньше в личном кабинете была одна общая цифра «заблокировано N запросов». Это не давало понимания, что происходит на сайте. Мы полностью переработали статистику. Теперь владелец сайта видит разбивку по всем причинам блокировки: сколько запросов заблокировано по IP датацентров, сколько — по спам-POST, сколько — по подделкам под поисковых ботов, сколько — по перебору, сколько — по неклассифицированным IPv6.

Эта детализация важна не только для понимания общей картины, но и для принятия решений. Если вы видите, что большинство блокировок приходится на спам-POST, значит, нужно усилить защиту форм. Если много блокировок по датацентрам — возможно, стоит ужесточить настройки для облачных IP. Прозрачная статистика превращает защиту из «чёрного ящика» в управляемый инструмент, с которым можно работать.

На горизонте: переход от правил к обучению

Формальные признаки — IP, заголовки, User-Agent — это хорошо, но у них есть предел. Опытный злоумышленник может подделать все эти параметры. Поэтому мы начали движение в сторону машинного обучения. Уже сейчас сервис в фоновом режиме собирает обезличенные данные о движении курсора мыши реальных посетителей. Важно подчеркнуть: мы собираем данные только у тех, кто уже прошёл проверку и признан человеком. Никаких персональных данных — только траектория движения курсора, скорость, паузы.

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

Сервис сейчас в открытом бета-тестировании

Мы хотим, чтобы как можно больше владельцев сайтов могли проверить наш сервис на своих проектах. Поэтому bot-guard.ru сейчас находится в стадии открытого тестирования, и защита предоставляется полностью бесплатно. Никаких скрытых платежей, никакого ограничения функционала — вы получаете все механизмы защиты, описанные выше, в полном объёме.

Подключение занимает несколько минут. Вам нужно вставить один короткий PHP-сниппет в начало вашего сайта. Вся остальная логика подгружается и обновляется автоматически с сервера bot-guard. Вам не нужно ничего переустанавливать вручную, следить за обновлениями баз данных или настраивать сервер. Мы делаем это за вас. Если у вас сайт на популярной CMS — WordPress, Bitrix, OpenCart или любой другой, поддерживающей PHP, — интеграция займёт ещё меньше времени.

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

Чем это отличается от других решений на рынке

Рынок защиты от ботов не пустует. Есть крупные международные игроки, есть бесплатные виджеты от Google и Яндекса. Но у каждого из них есть существенные недостатки, которые не позволяют назвать их оптимальным решением для малого и среднего бизнеса в Рунете. Сравним основные варианты в таблице.

Вывод из этого сравнения очевиден. Ниша bot-guard.ru — это малый и средний бизнес в Рунете, который зажат между «бесплатно, но бесполезно против серьёзных ботов» (reCAPTCHA, SmartCaptcha) и «эффективно, но по цене корпоративного контракта» (Cloudflare Enterprise, DataDome). Мы предлагаем то, чего категорически не хватало на рынке: простую установку без смены инфраструктуры, прозрачную статистику по всем типам угроз в одном личном кабинете, невидимую для человека проверку вместо раздражающей капчи и бесплатный доступ на время тестирования.

Попробуйте сами

Боты не будут ждать, пока вы решитесь на защиту. Каждый день без неё — это потерянные заявки, забитая спамом почта и риск взлома. Подключение к bot-guard занимает несколько минут, а в период бета-тестирования это ещё и бесплатно. Зайдите на сайт, вставьте сниппет, и вы увидите реальную картину ботовой активности на вашем ресурсе. Возможно, вы удивитесь, сколько мусорного трафика проходило раньше.