Стандартный адрес /bitrix/admin/ — первое, что пробуют
автоматические сканеры и боты при переборе учётных данных.
Смена адреса административной панели не заменяет полноценную защиту,
но заметно снижает фоновый шум от массовых автоматических атак.
Разберём, как это сделать штатными средствами и какие подводные
камни есть у этого способа.
Штатная настройка через проактивную защиту
В разделе Настройки → Инструменты
разработчика → Проактивная защита →
Изменение стандартных названий доступна опция смены
адреса каталога административной части. После включения путь вида
/bitrix/admin/ заменяется на произвольный, заданный
администратором, например /my-secret-panel/.
Что происходит технически
Функция не переименовывает физический каталог /bitrix/admin/
на диске — вместо этого она добавляет правило в
urlrewrite.php, которое перенаправляет запросы
с нового адреса на реальный каталог, и одновременно блокирует прямой
доступ по старому пути через правила .htaccess. Это
важно понимать: попытка достучаться напрямую до
/bitrix/admin/ после включения защиты должна возвращать
ошибку доступа, а не саму панель.
Нужна помощь с Битрикс?
Проверка после включения
# старый адрес должен быть недоступен
curl -I https://example.ru/bitrix/admin/
# новый адрес должен открывать форму входа
curl -I https://example.ru/my-secret-panel/
После включения обязательно проверить оба адреса — если старый путь
всё ещё отвечает панелью входа, правила блокировки не применились
корректно (частая причина — конфликт с собственными правками
.htaccess в корне сайта, сделанными до включения защиты).
Что важно сохранить: закладки и интеграции
Смена адреса ломает все сохранённые в браузере закладки на старый
путь, а также любые внешние интеграции, которые обращаются
к конкретным URL в каталоге /bitrix/admin/ напрямую
(некоторые вебхуки, скрипты синхронизации, написанные без учёта
такой смены). Перед включением стоит проверить, не завязано ли
что-то на прямой путь к админке помимо обычного входа человеком
через браузер.
Ограничения способа
Смена адреса — мера против автоматического массового перебора по известному пути, а не защита от целенаправленной атаки: адрес админки виден в исходном коде страниц (ссылки в шаблоне, если они используют абсолютный путь), в логах сервера, куда может быть доступ у скомпрометированного смежного сервиса, и потенциально утекает через историю поисковых систем, если каталог случайно не был закрыт от индексации. Это дополнительный слой, а не замена двухфакторной аутентификации и защиты от перебора паролей.
Сочетание с другими мерами
-
Ограничение доступа к новому адресу по IP через
.htaccess, если состав администраторов постоянен и подключается с известных адресов. - Обязательная двухфакторная аутентификация для всех учётных записей с правами администратора.
- Ограничение количества попыток входа — штатный модуль проактивной защиты умеет блокировать IP после серии неудачных попыток авторизации.
Частые ошибки
- Старый адрес не проверен на блокировку после включения. Панель остаётся доступна по обоим адресам одновременно.
- Не учтены внешние интеграции, обращающиеся к прежнему пути. Вебхуки и скрипты синхронизации перестают работать без явной ошибки, понятной сразу.
- Смена адреса воспринимается как достаточная защита. Без двухфакторной аутентификации и ограничения попыток входа целенаправленная атака всё равно эффективна.
Итог
Смена адреса административной панели через штатную проактивную
защиту убирает большую часть автоматического фонового шума
от ботов, перебирающих стандартный путь /bitrix/admin/,
но не заменяет двухфакторную аутентификацию и ограничение попыток
входа. После включения обязательно проверить, что старый адрес
реально заблокирован, а не просто дублирует новый.