Как отключить проактивный фильтр и защиту административного раздела Битрикс через API

После изменения внешнего IP административный раздел может перестать открываться, а проактивный фильтр — отклонять запрос, необходимый для диагностики интеграции. Если войти в управление сайтом невозможно, настройки можно изменить через PHP API на сервере. Пароль администратора для этого не нужен: требуется SSH-доступ и возможность запустить PHP с доступом к файлам и базе конкретной установки. Метод относится к «1С-Битрикс: Управление сайтом» и коробочному Битрикс24. В облачном Битрикс24 выполнить такой скрипт нельзя.

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

Какой способ выбрать

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

Ни один из этих способов не заменяет пароль и не отменяет двухфакторную аутентификацию. Если блокировка появилась на внешнем WAF или в конфигурации nginx, изменение настроек Битрикс её не устранит.

Быстро: восстановить доступ с помощью файла-флажка

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

1. Подключитесь к файлам нужного сайта по FTP/SFTP либо SSH. Убедитесь, что открыли ту установку, административный раздел которой заблокирован. 2. Найдите точный путь файла-флажка в сохранённых настройках модуля или в документации вашей установки. Если путь неизвестен, перейдите к способу через API: создание файла с произвольным названием не поможет. 3. Создайте по этому пути пустой обычный файл. Например, только если в настройках указан /bitrix/modules/ipcheck_disable_ourproject267, в каталоге сайта bitrix/modules нужно создать файл ipcheck_disable_ourproject267, без расширения .txt. Это пример, а не готовое имя для вашего сайта. 4. Откройте /bitrix/admin/ и войдите со штатными учётными данными. Перейдите в «Настройки → Проактивная защита → Защита административного раздела» и исправьте разрешённые IP-адреса. 5. Удалите созданный файл-флажок. Проверьте вход с разрешённого адреса и отказ с контролируемого неразрешённого адреса, сохраняя рабочий SSH-сеанс.

Файл не меняет активность отдельных правил в базе. Пока он существует, обходится общая IP-проверка модуля, поэтому временно не применяются и другие правила стоп-листа. После удаления правила снова участвуют в проверке. Проактивный фильтр при этом остаётся включённым: для его отключения нужен отдельный вызов API либо штатная кнопка в административном разделе.

Аварийно: временно пропустить событие OnPageStart

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

Сначала скачайте неизменённую копию /bitrix/modules/main/include.php на свой компьютер. Храните её вне публичного каталога сайта: резервная копия с расширением .bak в доступной по HTTP папке может раскрыть PHP-код. Откройте рабочий файл редактором, сохраняющим исходную кодировку, и найдите этот цикл:

foreach (GetModuleEvents("main", "OnPageStart", true) as $arEvent)
{
    ExecuteModuleEventEx($arEvent);
}

Временно закомментируйте весь цикл, включая фигурные скобки. Например:

// foreach (GetModuleEvents("main", "OnPageStart", true) as $arEvent)
// {
//     ExecuteModuleEventEx($arEvent);
// }

Если добавить // только перед строкой foreach, оставив остальной блок, получится другое выполнение кода: тело больше не будет перебором событий. Так делать нельзя. Если указанного фрагмента в вашей версии нет, не удаляйте похожие блоки наугад.

Сохраните файл, откройте административный раздел и исправьте разрешённые IP. Сразу после этого верните исходный include.php из сохранённой копии, затем проверьте доступ с разрешённого и запрещённого адресов. При ошибке PHP после редактирования прежде всего восстановите исходный файл через тот же FTP/SFTP-доступ. Если после загрузки исправленного файла сервер продолжает использовать прежний код, проверьте политику обновления OPcache у своего хостинга; не перезапускайте все службы без необходимости.

У этого способа есть принципиальная граница: IP-правила модуля проверяются на OnPageStart, а проактивный фильтр — на OnBeforeProlog. Поэтому обход первого события может убрать IP-отказ, но не выключает фильтр. Документация порядка выполнения страницы показывает эти события отдельно. В настройках активность правил также останется прежней: вы временно пропустили их выполнение, а не изменили конфигурацию через API.

Точно: отключить нужный механизм через API

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

Два переключателя и их область действия

«Проактивная защита» — название модуля, а не одного выключателя. Помимо фильтра в нём есть контроль целостности, защита сессий и другие средства. Кнопка отключения проактивной защиты на странице фильтра управляет именно фильтром; это различие важно при работе через API. Документация страницы фильтра описывает проверку входящих данных, а описание модуля показывает более широкий набор механизмов.

SetActive() у фильтра не возвращает признак успеха: результат нужно проверять через IsActive(). Поэтому конструкция if (!CSecurityFilter::SetActive(false)) неверна. В исходном коде модуль регистрирует или снимает обработчики событий; это постоянное изменение конфигурации, действующее и после завершения PHP-процесса.

Для ограничения административного раздела нельзя подменять обновление отдельного правила вызовом CSecurityIPRule::SetActive(false): последний управляет общим обработчиком IP-проверки. Нам нужен конкретный объект правила, а не отключение проверки всех адресных ограничений сайта. Пользовательские пароли, роли, двухфакторная аутентификация и настройки внешнего межсетевого экрана в описанном сценарии не изменяются.

Подготовка: найти установку и PHP, сохранить рабочий доступ

Оставьте открытым SSH-сеанс. Если доступ идёт через VPN или внешний шлюз, менять их настройки для этой операции не требуется. Сначала установите реальный корень сайта. /home/bitrix/www — распространённый путь в BitrixVM, но в панели хостинга или собственном окружении он может отличаться. Путь ниже необходимо заменить на свой.

SITE_ROOT=/home/bitrix/www
test -f "$SITE_ROOT/bitrix/modules/main/include/prolog_before.php" && printf 'Bitrix bootstrap found\n'
php -v
php --ini

test проверяет наличие файла загрузки ядра, а не просто существование каталога bitrix. php -v показывает версию CLI-интерпретатора. php --ini сообщает, какой конфигурационный файл он использует: CLI и веб-сервер могут работать с разными версиями PHP и расширениями. Если установлен набор нескольких интерпретаторов, используйте полный путь к подходящему PHP во всех следующих командах. Не обновляйте PHP на рабочем сервере ради запуска этого инструмента.

Запуск выполняется от учётной записи, которой доступны код сайта и его соединение с базой. В примерах файл инструмента расположен в /root, поэтому используется привилегированный SSH-сеанс. При работе от владельца сайта используйте его закрытый домашний каталог и соответствующие пути. Не размещайте инструмент или снимок настроек в корне сайта: они не должны скачиваться посетителями.

Скачайте ZIP с PHP-инструментом, распакуйте на рабочем компьютере и перенесите единственный PHP-файл на сервер. Пример для OpenSSH; operator@server.example и путь загрузки замените на свои.

scp bitrix-security-api.php operator@server.example:~/bitrix-security-api.php

На сервере перенесите файл в закрытый каталог. Команда install одновременно копирует файл и задаёт права: 600 разрешает чтение и запись только владельцу. Исходный путь в примере указывает на домашний каталог оператора.

sudo install -m 600 /home/operator/bitrix-security-api.php /root/bitrix-security-api.php
sudo php -l /root/bitrix-security-api.php
sudo php /root/bitrix-security-api.php /home/bitrix/www status

Проверка синтаксиса должна закончиться сообщением No syntax errors detected. Затем status загружает ядро указанного сайта, подключает модуль security и выводит состояние фильтра и стандартные правила административного раздела. Сам этот режим настроек не меняет. При ошибке подключения к базе сначала исправьте окружение CLI, права и путь; ошибка PHP ещё не означает, что ограничение по IP снято.

Прочитать состояние и выбрать нужное отключение

Пример сокращённого ответа status ниже. Значения иллюстративные: номер правила, версия и список адресов зависят от установки. В настоящем ответе выводятся также остальные поля найденного правила, чтобы его можно было проверить перед изменением.

{
  "filter_active": true,
  "admin_rules": [
    {"ID": "7", "ACTIVE": "Y", "RULE_TYPE": "A", "ADMIN_SECTION": "Y", "SORT": "10"}
  ],
  "main_version": "26.800.0"
}

filter_active: true означает, что зарегистрирован обработчик фильтра. ACTIVE: Y относится к конкретному IP-правилу. Это разные признаки. Инструмент выбирает стандартное административное правило по тем же полям, которыми пользуется соответствующая страница управления: тип A, административный раздел Y, общий сайт, сортировка 10, без начала и окончания активности.

Если admin_rules пуст, стандартное правило не найдено. Инструмент не создаёт новое правило и не объявляет отсутствие записи успешным отключением. Если найдено несколько подходящих правил, он откажется менять административную защиту: выбор по первой попавшейся строке был бы ненадёжным. Пользовательское правило с другими параметрами тоже требует отдельного анализа. Назначение полей активности, IP и масок описано в документации редактора правил.

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

sudo php /root/bitrix-security-api.php /home/bitrix/www filter-off /root/filter-before-20261014.json

Команда отключает фильтр, но не IP-защиту. Для другого сценария используется admin-off:

sudo php /root/bitrix-security-api.php /home/bitrix/www admin-off /root/admin-before-20261014.json

Если нужно снять оба ограничения:

sudo php /root/bitrix-security-api.php /home/bitrix/www both-off /root/security-before-20261014.json

До первого изменения инструмент создаёт JSON-снимок вне корня сайта с правами 600. Он сохраняет исходную активность фильтра, поля выбранного правила и режим операции. Существующий файл не перезаписывается: для новой операции нужен новый путь. Это защищает первоначальное состояние от случайной замены снимком уже отключённой защиты.

В результате both-off ожидаются filter_active: false и ACTIVE: N у найденного правила. Сразу после этого выполните status отдельным PHP-процессом: проверка в новом процессе подтверждает сохранённые настройки, а не только внутреннее состояние уже работающего скрипта.

sudo php /root/bitrix-security-api.php /home/bitrix/www status

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

Что выполняет PHP API внутри инструмента

Ключевая последовательность для фильтра короткая. Это фрагмент API для понимания механизма; готовый CLI-инструмент дополнительно проверяет окружение, делает снимок и обрабатывает ошибки.

<?php
$_SERVER['DOCUMENT_ROOT'] = '/home/bitrix/www';
define('NO_KEEP_STATISTIC', true);
define('NO_AGENT_CHECK', true);
require $_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/prolog_before.php';
if (!\Bitrix\Main\Loader::includeModule('security')) {
    throw new RuntimeException('Security module unavailable');
}
$before = (bool) CSecurityFilter::IsActive();
CSecurityFilter::SetActive(false);
if (CSecurityFilter::IsActive()) {
    throw new RuntimeException('Filter remains active');
}

DOCUMENT_ROOT у CLI может быть пустым, поэтому его задают явно. prolog_before.php подключает ядро, настройки и соединение с базой этой установки. Константы уменьшают побочную работу статистики и агентов; они сами по себе защиту не отключают. Loader::includeModule('security') подключает классы модуля, после чего становятся доступны CSecurityFilter и CSecurityIPRule. Подключение модуля описано в документации API.

Для административного ограничения сначала получают подходящее правило, затем меняют только его ACTIVE. У GetList первым аргументом идёт список выбираемых полей, вторым — фильтр, третьим — сортировка. Переставлять аргументы по привычке от другого класса нельзя.

$result = CSecurityIPRule::GetList([], [
    '=RULE_TYPE' => 'A', '=ADMIN_SECTION' => 'Y', '=SITE_ID' => false,
    '=SORT' => 10, '=ACTIVE_FROM' => false, '=ACTIVE_TO' => false,
], ['ID' => 'ASC']);
$rules = [];
while ($row = $result->Fetch()) { $rules[] = $row; }
if (count($rules) !== 1) {
    throw new RuntimeException('Expected exactly one standard administrative rule');
}
$api = new CSecurityIPRule();
if (!$api->Update((int)$rules[0]['ID'], ['ACTIVE' => 'N'])) {
    throw new RuntimeException(strip_tags($api->LAST_ERROR));
}

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

Операция both-off не является одной атомарной транзакцией: сначала меняется фильтр, затем правило. Если второе действие завершится ошибкой, фильтр уже может быть отключён. Инструмент прямо сообщает об этом и сохраняет снимок. В таком случае сначала прочитайте status, затем выполните restore с тем же файлом; не повторяйте отключение с новым снимком поверх частично изменённого состояния.

Исправить причину и вернуть исходную защиту

Временное отключение — этап диагностики. После восстановления доступа исправьте разрешённые адреса в настройках защиты административного раздела. Учитывайте адрес, который видит PHP: за обратным прокси он может отличаться от IP компьютера администратора. Нельзя без проверки доверять присланному клиентом X-Forwarded-For; доверие к заголовкам должно быть настроено только для известных прокси.

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

sudo php /root/bitrix-security-api.php /home/bitrix/www restore /root/security-before-20261014.json
sudo php /root/bitrix-security-api.php /home/bitrix/www status

Для filter-off или admin-off укажите соответствующий файл снимка из выполненной команды. Восстановление возвращает только изменённые переключатели. Если фильтр был отключён ещё до операции, инструмент не включит его самовольно. Если вы исправили разрешённые IP или маски, они сохранятся: восстановление не загружает старый набор адресов поверх исправлений.

Перед возвратом административного правила инструмент проверяет его идентичность по ID и служебным полям. Удаление правила, замена его другим или изменение признаков стандартного правила приведёт к отказу автоматического восстановления. Это повод сверить настройки, а не принудительно включать неизвестную запись.

Проверка должна охватывать обе стороны ограничения. С разрешённого адреса административный раздел должен открываться, с отдельного контролируемого неразрешённого адреса — блокироваться. Используйте отдельный сеанс и сохраните рабочий SSH-доступ, пока не завершите проверку. Для фильтра подтвердите активность через status и успешность исправленного легитимного запроса. Само наличие true не доказывает, что все исключения настроены правильно.

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

Если доступа всё ещё нет

HTTP 403 сам по себе не указывает на модуль Битрикс. Такой ответ может сформировать nginx, Apache, внешний WAF, CDN или шлюз. Сравните состояние API с журналами соответствующего слоя и точным временем запроса. Отключение фильтра также не удаляет ранее созданные отдельные стоп-правила.

curl -sS -D - -o /dev/null --max-time 10 https://portal.example.ru/bitrix/admin/
sudo tail -n 100 /var/log/nginx/error.log

Первый пример показывает статус и заголовки без загрузки тела ответа в терминал. Домен замените на свой; не передавайте пароль в командной строке. Второй показывает конец журнала nginx, если он находится по указанному пути. Реальный путь найдите в конфигурации своего веб-сервера. Отсутствие записи в журнале приложения при наличии отказа на внешнем WAF указывает, что запрос до Битрикс мог вообще не дойти.

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