Как закрыть сайт на 1С-Битрикс от ботов и сканеров

Сайты на 1С-Битрикс регулярно становятся целью автоматизированных сканеров, парсеров, спам-ботов и попыток перебора служебных адресов. Причина проста: это популярная CMS с узнаваемой структурой, поэтому массовые инструменты могут проверять типовые URL и поведение приложения сразу на тысячах сайтов.

При этом защита Битрикс имеет свои особенности. Нельзя просто закрыть всё, что начинается с /bitrix/: внутри этой структуры находятся не только административные страницы, но и служебные ресурсы, AJAX-обработчики, компоненты, файлы ядра и механизмы, которые нужны самому сайту.

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

Важно: защита 1С-Битрикс не должна строиться на грубом запрете каталога /bitrix/. Иначе можно нарушить AJAX, формы, компоненты, административные функции и часть фронтенда.

Какие автоматизированные запросы чаще всего видит сайт на Битрикс

попытки открыть административный раздел;
перебор типовых служебных URL;
сканирование компонентов и технических обработчиков;
парсинг каталога и карточек товаров;
массовые запросы к поиску и фильтрам;
спам через формы;
обращения к AJAX-endpoint-ам;
запросы к API и интеграционным точкам;
поиск устаревших или неправильно настроенных компонентов.

Почему 1С-Битрикс легко узнаётся автоматическими сканерами

У Битрикс есть характерная структура каталогов, служебные пути, ресурсы ядра и типовые административные адреса. Даже если убрать явные признаки из HTML, автоматизированный сканер может определить CMS по совокупности ответов сервера и структуре запросов.

Поэтому попытка «спрятать» CMS сама по себе не является защитой. Гораздо важнее своевременно обновлять платформу, ограничивать ненужные точки входа и фильтровать подозрительные запросы до того, как они дойдут до PHP и ядра Битрикс.

Не нужно пытаться сделать Битрикс невидимым. Надёжнее сделать так, чтобы обнаружение CMS не давало атакующему практического преимущества.

Административный раздел нужно защищать отдельно

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

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

Не блокируйте служебные ресурсы без проверки

Часть запросов к каталогам Битрикс возникает при нормальной работе сайта. Стили, JavaScript, компоненты, AJAX и служебные механизмы могут использовать URL, которые внешне выглядят техническими. Поэтому перед блокировкой нужно проверить, что конкретный путь действительно не используется фронтендом.

AJAX — частая причина ложных блокировок

Современный сайт на Битрикс активно использует AJAX: формы, фильтры, корзина, избранное, быстрый просмотр, поиск, оформление заказа и личный кабинет. Если защитное правило ориентируется только на необычный URL или POST-запрос, оно легко может остановить реального посетителя.

Поэтому для AJAX-endpoint-ов нужно учитывать метод запроса, origin, cookies, сессию, структуру параметров и реальный сценарий работы сайта.

Поиск и умный фильтр могут стать источником нагрузки

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

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

Защита каталога от парсеров

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

анализировать скорость обхода карточек;
искать повторяющиеся маршруты;
контролировать массовые обращения к фильтрам;
сопоставлять IP, ASN и браузерные признаки;
ограничивать агрессивные распределённые сценарии;
не мешать поисковым роботам индексировать каталог.

Почему robots.txt не защищает от нежелательного парсинга

robots.txt предназначен для добросовестных роботов и управления индексированием. Произвольный парсер может полностью игнорировать эти правила. Поэтому файл полезен для SEO, но не является средством контроля доступа.

Формы на Битрикс тоже нужно защищать

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

Серверная валидация, токены, honeypot, ограничения частоты и внешняя фильтрация помогают снизить объём фальшивых отправок. При этом важно не сломать легитимные AJAX-запросы и интеграции.

Обновления платформы и модулей критичны

Даже идеальная фильтрация трафика не заменяет обновление самой CMS. Если уязвимость находится в ядре или модуле и остаётся неисправленной, риск сохраняется. Поэтому ядро Битрикс, Marketplace-модули и кастомные компоненты должны регулярно проверяться и обновляться.

WAF не должен использоваться вместо обновлений. Его задача — уменьшить поверхность внешних атак и отсеять нежелательные запросы, но исправление уязвимого кода остаётся обязательным.

Особое внимание — сторонним модулям и кастомному коду

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

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

Не оставляйте тестовые и резервные файлы в публичной директории

После доработок и переносов на сервере могут оставаться архивы, старые копии файлов, дампы базы и тестовые скрипты. Автоматизированные сканеры ищут типовые имена таких объектов. Если файл доступен по HTTP, он может раскрыть конфиденциальную информацию.

Почему access-логи важнее одной Метрики

Большинство технических сканеров не выполняют JavaScript и поэтому могут почти не отображаться в Яндекс Метрике. Но сервер видит каждый запрос. Access-логи позволяют обнаружить перебор служебных URL, большое количество ошибок, аномальную частоту и повторяющиеся шаблоны обхода.

Источник	Что показывает
Яндекс Метрика	Пользовательские визиты, источники, цели и поведение.
Access-лог	Фактические HTTP-запросы, включая клиентов без JavaScript.
WAF / reverse proxy	Причины блокировок, проверки и сетевые признаки.
Логи Битрикс	Ошибки приложения, события модулей и внутренние проблемы.

Почему одного rate limit недостаточно

Ограничение частоты хорошо работает против агрессивного клиента с одного IP. Но распределённый сканер может использовать множество адресов и делать немного запросов с каждого. Тогда общий шаблон остаётся автоматическим, хотя локальный лимит не превышается.

Поэтому rate limit лучше сочетать с анализом ASN, URL, browser fingerprint, cookies и повторяемости поведения.

Что даёт WAF перед 1С-Битрикс

Если WAF или reverse proxy расположен перед сервером Битрикс, нежелательный запрос можно остановить до запуска PHP и ядра CMS. Это снижает нагрузку и позволяет применять более гибкие правила, не изменяя код сайта.

фильтрация сканеров;
ограничение подозрительных запросов к административным путям;
контроль массового парсинга;
защита форм и AJAX-endpoint-ов;
анализ IP, ASN и HTTP-характеристик;
браузерные проверки для спорного трафика;
доверенный пропуск поисковых роботов.

Как CRONARMOR защищает сайты на Битрикс

CRONARMOR работает как внешний защитный контур перед основным сервером. Для сайта на 1С-Битрикс правила настраиваются с учётом реальных AJAX-запросов, каталога, поиска, форм, интеграций и административной части.

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

Для 1С-Битрикс особенно важна точная настройка. Защитить CMS — значит не просто заблокировать «подозрительные» URL, а отделить необходимые служебные запросы от нежелательной автоматизации.

Практический чек-лист защиты 1С-Битрикс

Регулярно обновлять платформу и модули.
Проверить сторонние компоненты и кастомный код.
Защитить административный вход и включить 2FA.
Не хранить архивы и дампы в публичных каталогах.
Проверить формы и AJAX-endpoint-ы.
Отдельно контролировать поиск, фильтры и каталог.
Анализировать access-логи.
Не доверять одному User-Agent или IP.
Разрешать проверенных поисковых роботов.
Использовать WAF или reverse proxy перед CMS.

FAQ

Можно ли просто закрыть весь каталог /bitrix/?

Нет. Это может нарушить работу фронтенда, AJAX, компонентов и служебных механизмов. Ограничивать нужно конкретные ненужные или опасные точки.

Нужно ли блокировать всех ботов?

Нет. Поисковые системы и другие легитимные сервисы тоже являются автоматизированными клиентами. Их нужно отличать от нежелательного сканирования.

Почему сканеры не видны в Метрике?

Многие из них не выполняют JavaScript и не запускают счётчик. Их активность лучше видна в серверных логах.

Поможет ли только встроенный проактивный фильтр?

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

Нужно закрыть сайт на 1С-Битрикс от ботов и сканеров?

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