Беру задачи в работу — отвечаю в течение дня
Бесплатная первичная оценка. Отвечу в течение дня. Работаю с Битрикс с 2010 года.
Сценарии
Переходите на /bitrix/admin/ — страница бесконечно грузится, показывает белый экран или ошибку PHP. Сайт при этом может работать нормально.
Пароль не подходит, учётная запись заблокирована или ссылка для восстановления не приходит. Зайти в панель управления невозможно.
Каждая страница в панели управления открывается по 15–30 секунд. Сохранение настроек зависает. Работать с сайтом невозможно.
Визуальный редактор не открывается, настройки модулей не сохраняются, инфоблоки выдают ошибку. Сама админка доступна, но функциональность нарушена.
При попытке сохранить изменения в админке — ошибка 403 Forbidden. Проактивная защита или WAF/mod_security блокируют POST-запросы.
В списке администраторов появились чужие учётные записи. Настройки изменены. Непонятно, что ещё затронуто и как перекрыть доступ злоумышленникам.
Не нашли свой случай? Проблем с админкой больше десятка типов. Опишите ситуацию, и я определю, что именно случилось.
Разбор эксперта
Панель управления — это не просто набор страниц. Это собственный маршрутизатор, система авторизации, менеджер сессий и десятки модулей с взаимозависимостями. Когда ломается один элемент цепочки — вход, сессия, права, кеш, JavaScript-компоненты — последствия проявляются непредсказуемо: от белого экрана до выборочного отказа функций.
Проблема «не работает админка» может возникнуть на уровне веб-сервера (403, mod_security), PHP (белый экран, fatal error), сессий (разлогинивание, Redis), авторизации (пароли, OTP, проактивная защита), прав доступа (роли, группы, b_group_task) или интерфейса (JS-ошибки, сломанный визуальный редактор). Каждый уровень требует своих инструментов диагностики.
Специалист не угадывает причину — он проверяет цепочку целиком. Сначала авторизация и сессии (PHP session handler, Redis, cookie-параметры). Затем права доступа (группы, роли, таблица b_group_task). Потом защитные механизмы (проактивный фильтр, WAF, .htaccess). Далее кеш и агенты. И наконец — JavaScript-компоненты админки. Каждый шаг документируется.
Процесс
Расскажите, что происходит при попытке войти в админку: какая ошибка, когда началось, были ли обновления или смена хостинга. Первичная оценка — бесплатно. Я отвечу в течение дня и скажу, что потребуется для восстановления доступа.
Проверяю цепочку авторизации: сессии, пароли, права доступа, проактивную защиту, настройки веб-сервера, кеш и агенты. Определю точную причину — от истёкшей сессии Redis до заблокированного IP в b_security_filter. Если обнаружатся дополнительные проблемы — сообщу сразу.
Называю стоимость и сроки до начала работ. Вы всегда знаете заранее, сколько это будет стоить. Если в процессе выясняются новые обстоятельства — согласуем отдельно, аргументированно и прозрачно.
Проверяю работоспособность админки, убеждаюсь, что все функции доступны. 14 дней гарантии — если проблема вернётся без изменений в коде с вашей стороны, исправлю бесплатно.
Первичная оценка — бесплатно
Кейсы
После переезда на новый сервер с кластерной конфигурацией администраторы не могли нормально работать — сессия сбрасывалась каждые несколько минут. Приходилось заново вводить логин и пароль десятки раз в день.
На новом сервере сессии хранились в Redis с двумя нодами, но Битрикс был настроен на файловый session handler. Сессии создавались на одной ноде, а последующие запросы попадали на другую, где файла сессии не существовало. Дополнительно session.cookie_lifetime был установлен в 0.
Диагностика 30 минут, устранение 1.5 часа. Переключил session handler на Redis через настройки Битрикс, настроил единый Redis-инстанс для сессий, установил корректный cookie_lifetime.
Утром в понедельник никто из офиса не мог войти в админку — при вводе пароля страница возвращалась на форму входа без ошибки. С мобильного интернета всё работало.
В пятницу стажёр несколько раз ввёл неверный пароль. Проактивная защита Битрикс внесла внешний IP офиса в таблицу b_security_filter как заблокированный. Все сотрудники офиса выходили через один NAT-адрес, поэтому блокировка затронула всех.
Диагностика 20 минут, устранение 40 минут. Удалил IP из b_security_filter через прямой доступ к базе, настроил whitelist для офисных IP, увеличил порог блокировки.
Админка открывалась нормально, но при попытке сохранить статью с HTML-разметкой или изменить настройки модулей — ошибка 403. Простой текст сохранялся, текст с кодом — нет.
На сервере был установлен mod_security с набором правил OWASP CRS. Правила SQLI и XSS срабатывали на HTML-теги и SQL-подобные конструкции в POST-запросах админки Битрикс. Логи mod_security показывали десятки false-positive срабатываний.
Диагностика 40 минут, устранение 1.5 часа. Настроил исключения mod_security для директории /bitrix/admin/ по конкретным правилам (ID 941100, 942100), сохранив защиту для публичной части сайта.
После обновления Битрикс контент-менеджер перестал видеть раздел «Контент» и управление инфоблоками в админке. У других администраторов всё работало. Проблема появилась только у одного сотрудника.
При обновлении пересоздались записи в таблице b_group_task — связки между группами пользователей и правами на модули. Группа «Контент-менеджеры», в которой состоял сотрудник, потеряла права на модуль iblock. Остальные администраторы были в группе с полными правами, где проблема не проявилась.
Диагностика 25 минут, устранение 45 минут. Восстановил записи в b_group_task для группы контент-менеджеров, проверил права на все используемые модули, задокументировал текущую матрицу доступа.
Админка стала невыносимо медленной — каждая страница грузилась по 20–30 секунд. Публичная часть сайта работала нормально. Хостер подтвердил, что ресурсов достаточно.
В таблице b_agent скопилось 340 просроченных агентов с ошибками выполнения. Битрикс выполняет агенты при каждом хите в админку, и 340 попыток запуска неработающих агентов создавали задержку в 20+ секунд. Проблему усугублял агент отправки почты, который пытался отправить 1200 писем из очереди.
Диагностика 30 минут, устранение 1 час. Почистил очередь агентов: удалил неактуальные, исправил интервалы, перевёл почтовые отправки на cron. Время загрузки админки — менее 2 секунд.
Единственный администратор сайта включил двухфакторную аутентификацию (OTP) и потерял телефон. Резервные коды не сохранены. Войти в админку невозможно, других администраторов нет.
Битрикс хранит OTP-секрет в таблице b_user в поле OTP_SECRET. При включённом OTP без валидного TOTP-кода авторизация невозможна даже с правильным паролем. Штатного способа сбросить OTP без доступа к админке не существует.
Диагностика 15 минут, устранение 30 минут. Сбросил OTP через прямой доступ к базе данных (очистка полей OTP_SECRET и ACTIVE_OTP в b_user), повторно настроил двухфакторную аутентификацию с сохранением резервных кодов.
Системный администратор ограничил доступ к /bitrix/admin/ по IP-адресу через .htaccess. После смены провайдера в офисе IP изменился — теперь никто не может войти в админку.
В .htaccess в директории /bitrix/admin/ стояло правило deny from all / allow from с жёстко прописанным старым IP. Новый IP не был добавлен, а FTP-доступ к серверу тоже оказался ограничен из той же сети. Доступ к серверу — только через панель хостинга.
Диагностика 10 минут, устранение 20 минут. Обновил .htaccess через файловый менеджер хостинга, заменил IP-ограничение на проверку по подсети, добавил резервный IP для аварийного доступа.
После обновления Битрикс до последней версии визуальный редактор в админке перестал открываться. При нажатии на «Редактировать» — пустая область вместо редактора. Остальные функции админки работали.
Обновление заменило JavaScript-файлы визуального редактора, но старые версии остались в кеше браузера и CDN. Дополнительно кастомный шаблон компонента использовал устаревший API редактора (BX.CEditor), который был удалён в новой версии.
Диагностика 45 минут, устранение 2 часа. Сбросил серверный кеш и настроил версионирование статических файлов. Адаптировал кастомный шаблон компонента к новому API визуального редактора.
Владелец обнаружил в списке администраторов три незнакомые учётные записи. Настройки сайта были изменены, в шаблоне появился подозрительный JavaScript. Непонятно, что ещё затронуто.
Злоумышленники проэксплуатировали уязвимость в необновлённом модуле vote. Через неё внедрили PHP-шелл в /bitrix/tools/, создали администраторские аккаунты и добавили бэкдор в init.php. Проактивная защита была отключена предыдущим разработчиком.
Диагностика 2 часа, устранение 6 часов. Удалил вредоносные аккаунты, PHP-шелл и бэкдор. Обновил все модули, включил проактивную защиту, сменил пароли и соли хеширования. Провёл аудит изменённых файлов за последние 30 дней.
После обновления модуля «Торговый каталог» менеджеры потеряли доступ к управлению товарами и ценами. Админка открывалась, но вместо каталога — сообщение «Доступ запрещён».
Обновление модуля catalog пересоздало записи в таблице b_group_task с новыми идентификаторами задач. Кастомные группы пользователей (менеджеры, контент-редакторы) ссылались на старые ID задач, которых больше не существовало. Стандартная группа «Администраторы» не пострадала, так как имеет полный доступ по умолчанию.
Диагностика 35 минут, устранение 1.5 часа. Восстановил связки прав в b_group_task для всех кастомных групп. Создал SQL-скрипт для автоматической проверки целостности прав после будущих обновлений.
Стоимость
бесплатно
Вы описываете проблему, я оцениваю ситуацию и говорю, что потребуется. Без обязательств.
от 7 000 ₽
Минимальный заказ — 2 часа. С третьего часа — 3 500 ₽/час. Точную стоимость называю до начала работ, после диагностики.
по запросу
Для регулярного сопровождения. Ниже стоимость часа, квант времени 30 минут, нет минимального заказа.
Смотреть пакеты услугНе починил — не платите. Стоимость всегда согласована до начала работ. Никаких сюрпризов в счёте.
FAQ
Ответы на типичные ситуации с недоступной админкой Битрикс
Контакт
Опишите, что происходит — какую ошибку выдаёт админка, когда это началось и что изменилось перед этим. Я оценю ситуацию и скажу, что потребуется для восстановления доступа.