Как проверить безопасность 1С-Битрикс до обновления

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

1. Как узнать версию ядра и модулей Битрикс

Начинаю с административной страницы «Marketplace → Обновление платформы» и, если нужен полный разбор до работ, подключаю аудит информационной безопасности: записываю версию главного модуля, редакцию продукта и состояние доступных обновлений. Версия в интерфейсе — исходная точка, а не повод объявлять сайт чистым или заражённым. Если на сервере есть собственные правки ядра, сначала выясняю, кто и зачем их внёс. Обновление может заменить системные файлы, поэтому неподтверждённый патч нельзя просто затереть и надеяться, что никто не заметит.

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

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

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

• Запишите версию главного модуля и редакцию
• Составьте список сторонних модулей
• Проверьте совместимость с целевым обновлением

2. Какие права проверить в каталогах и загрузках

Права проверяю на уровне ОС и веб-сервера: кто владеет файлами, под каким пользователем работает PHP, куда ему действительно нужна запись. Универсальная команда chmod для всего дерева сайта здесь неуместна. Рекурсивно выставить 750 каталогам и 640 файлам — значит легко отрезать веб-процессу нужную запись или чтение, а в иной схеме владельцев эти цифры вообще не решат проблему. Сначала фиксирую текущие владельцев и режимы, затем согласую изменения с конфигурацией хостинга.

Отдельно прохожу каталоги загрузок и временные данные, включая /upload, /bitrix/tmp и /bitrix/backup, если такие пути используются в конкретной установке. Проверяю, нет ли там исполняемых файлов, открытого листинга, общедоступных архивов или лишней записи со стороны других системных пользователей. Запись в upload сама по себе нужна сайту для приёма файлов; риск зависит от того, может ли веб-сервер исполнить загруженный PHP и кто ещё может туда писать. Поэтому «всё закрыть» — не настройка безопасности, а будущая заявка о сломанной загрузке.

Для каждого изменения сохраняю исходное состояние и проверяю действие от имени реального пользователя PHP, а не только из SSH под root. После настройки прогоняю штатную «Проверку системы» и проверяю сценарии загрузки, кеширования и обновления. В Bitrix права доступа продукта и Unix-права — разные уровни: запрет в интерфейсе не заменяет ограничение на уровне ОС, а корректный chmod не настраивает роли редакторов. Эти два слоя нельзя смешивать в одну цифру.

Проверка владельца иногда важнее самой маски прав. Если загрузку создал deploy-пользователь, а PHP работает от отдельной учётной записи, веб-приложение может не суметь обновить этот файл; расширение доступа «для всех» замаскирует причину и расширит область записи. Я выясняю, кто создаёт файлы при загрузке и деплое, проверяю группы и наследование, затем тестирую операцию тем же пользователем, которым она выполняется в эксплуатации. Нужна не красивая цифра в отчёте, а минимально необходимый доступ при сохранении рабочих операций.

• Уточните владельца и пользователя PHP
• Проверьте запись только там, где она нужна
• Убедитесь, что загрузки не исполняются как код

3. Что покажет штатная проверка безопасности

В административной части использую штатную «Проверку системы» и, если она доступна в редакции и установлена, «Проактивную защиту → Поиск троянов → Сканирование файлов». Это проверки разных задач: первая сверяет технические параметры и доступность системных файлов, вторая ищет совпадения с шаблонами потенциально вредоносного кода. Она не составляет список всех известных CVE для каждого расширения и не заменяет аудит исходного кода. Не нашлось подозрительных совпадений — это полезный результат, но не гарантия отсутствия уязвимости.

Каждое срабатывание рассматриваю как повод проверить файл, а не как приговор. Официальная документация предупреждает о ложных срабатываниях: легитимный код проекта может совпасть с шаблоном сканера. Сверяю путь, время изменения, владельца, назначение и отличие от чистой версии. Для изменений в правах редакторов полезен отдельный разбор доступа к инфоблокам: он помогает не путать прикладную роль пользователя с системной записью файла. Если файл относится к кастомной разработке, прошу разработчика объяснить конкретный фрагмент. Удалять файл автоматически после одного предупреждения — плохой способ обеспечить доступность сайта.

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

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

• Запустите «Проверку системы»
• Просмотрите сканирование файлов, если доступно
• Разберите каждый результат вручную

4. Совместимы ли PHP и расширения с обновлением

Проверяю PHP, который обслуживает сайт, а не только версию в командной строке: php -v показывает CLI и может вести на другой бинарный файл, чем PHP-FPM или веб-сервер. Сверяю активную версию с требованиями текущей версии продукта и целевого обновления в официальной документации и в админке. На дату этой проверки документация Битрикс указывает PHP от 8.2.0 с 1 февраля 2026 года и рекомендует 8.4 или новее. Эти требования меняются; перед работой смотрите актуальную страницу, а не переносите цифру из старой инструкции.

В панели управления запускаю «Проверку системы» и читаю пояснения к ошибкам. При необходимости сравниваю список расширений PHP для CLI и веб-окружения, но не считаю gd, curl, mbstring и json универсальным списком: обязательность зависит от функций сайта и конфигурации. Например, документация отдельно связывает GD с CAPTCHA. Если модуль нужен установленному функционалу, отсутствие расширения может сломать именно этот сценарий; обещать «белый экран» от любого отсутствующего пункта было бы преувеличением.

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

Проверяю и конфигурацию веб-окружения на тестовой копии, потому что именно там часто скрывается разница между «PHP подходит» и «сайт работает». У одного проекта может быть несколько пулов PHP-FPM, а CLI запускается через другой путь и читает иной ini-файл. Уточняю, где заданы настройки сайта, какие модули включены для конкретного пула, и не изменит ли обновление поведение загрузки файлов или обработки изображений. После смены версии возвращаюсь к тем же проверочным сценариям и сравниваю результат, а не ограничиваюсь тем, что главная страница открылась.

• Проверьте PHP именно веб-процесса
• Сверьте требования для целевой версии
• Проверьте нужные сайту расширения и сценарии

5. Как проверить целостность и подготовить откат

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

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

После обновления повторяю контроль целостности и создаю новый эталон уже для обновлённой системы, как рекомендует документация. Сверяю версию ядра, проверяю журнал установки и прогоняю согласованные сценарии сайта. В условном проекте ООО «Пальмира Групп» я бы начал именно с тестовой копии: например, при 18 тысячах файлов и двух сторонних модулях фиксирую список изменений, проверяю восстановление и только потом планирую окно работ. Это пример порядка действий, не статистика и не обещание уложиться в конкретное время.

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

• Сохраните отчёт контроля до обновления
• Проверьте восстановление копии файлов и БД
• После работ проверьте сайт и соберите новый эталон

Частые вопросы