10 мин

2.4K

Когда говорят о безопасности, обсуждение быстро сводится к CVE/BDU Какая версия уязвима? Существует ли публичный эксплойт? И успел ли вендор выпустить исправление? Это конечно важно, но на практике инсталляции Bitrix могут скомпрометировать не из-за одной «критической уязвимости года».

Гораздо чаще проблема складывается из обычных причин:

• проактивный фильтр когда-то отключили из-за ложного срабатывания;

• обновление ядра ломает доработанный сайт, поэтому его откладывают;

• в корне сайта лежит restore.php;

• журнал ошибок доступен через браузер;

• администраторы работают под общей учетной записью без MFA;

• резервная копия хранится на том же сервере и доступна приложению на запись.

Каждая такая ошибка может выглядеть незначительной. Вместе они образуют удобный маршрут от разведки до захвата сервера.

В этой статье разберем десять проблем безопасности, характерных для самостоятельно размещаемых инсталляций 1С-Битрикс и Bitrix24. Основной акцент будет не на отдельных CVE, а на конфигурации, эксплуатации и разработке.

1. Отключенный модуль безопасности и проактивный фильтр

В Bitrix есть собственный модуль security, включающий Проактивный фильтр (Web Application Firewall), журналирование событий, защиту редиректов, механизмы контроля сессий и другие функции.

На практике модуль или отдельные его компоненты нередко отключают:

• после конфликтов с пользовательским кодом;

• из-за ложных срабатываний;

• во время диагностики;

• после миграции или восстановления;

• потому что никто не знает, зачем он нужен.

В исходном коде Bitrix состояние проактивного фильтра проверяется через CSecurityFilter::IsActive(). Собственная проверка конфигурации Bitrix рассматривает отключенный фильтр как серьезную проблему.

Но простого переключателя «включено» недостаточно. Защита фактически ослаблена и тогда, когда список исключений WAF содержит целые каталоги, модули или группы пользователей.

Что стоит проверить:

• активен ли модуль security;

• включен ли проактивный фильтр;

• какие пути и параметры добавлены в исключения;

• кто имеет право обходить фильтр;

• включено ли журналирование событий;

• кто и как реагирует на эти события.

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

2. Уверенность, что WAF исправит уязвимый код

Противоположная крайность выглядит так: «У нас включен WAF, поэтому код можно пока не исправлять».

WAF полезен как дополнительный уровень защиты и средство временного виртуального патчинга. Но он не способен гарантированно остановить:

• нарушение контроля доступа;

• IDOR;

• злоупотребление бизнес-логикой;

• действия скомпрометированного пользователя;

• состояния гонки(Race Condition);

• небезопасную обработку файлов;

• сложные цепочки атак;

• запросы, попавшие под исключения.

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

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

3. Устаревшее ядро, модули и пользовательский код

Инсталляция Bitrix состоит не только из ядра CMS. В ней могут одновременно присутствовать:

• модули Marketplace;

• собственные модули и компоненты;

• PHP-библиотеки;

• JavaScript-зависимости;

• интеграции с CRM, платежами и службами доставки;

• веб-сервер, PHP, СУБД и операционная система.

Достаточно одного заброшенного компонента, чтобы вся система осталась уязвимой.

Особое внимание требуется пользовательскому коду. Для него может не существовать CVE, бюллетеня безопасности или готовой сигнатуры сканера. При этом в обработчиках легко встретить SQL-инъекции, XSS, SSRF, небезопасную десериализацию, недостаточную проверку прав или произвольную загрузку файлов.

Минимальный процесс управления уязвимостями должен включать:

• реестр установленных модулей и зависимостей;

• владельца каждого пользовательского компонента;

• контроль версий и статуса поддержки;

• SCA(Software Composition Analysis) для сторонних зависимостей;

• SAST и ручной анализ критичного кода;

• регулярное получение уведомлений от Bitrix и поставщиков;

• сроки исправления, зависящие от риска и доступности компонента из интернета.

Полезно формировать SBOM(Software Bill of Materials) для каждого релиза. Сканирование во время сборки показывает состояние только на конкретный момент: новая уязвимость в уже выпущенной зависимости может появиться через неделю или месяц.

4. Доработки, после которых Bitrix невозможно обновить

Одна из самых опасных архитектурных проблем появляется, когда разработчики изменяют файлы ядра напрямую.

Пока проект работает, это воспринимается как технический долг. Когда выходит обновление безопасности, долг превращается в блокирующую проблему:

1. обновление перезапишет изменения;

2. изменения нельзя быстро восстановить;

3. проверить совместимость негде;

4. откат не отработан;

5. установку исправления откладывают на неопределенный срок.

В результате формально доступный патч невозможно применить в приемлемое время.

Штатные обновления также ломают неправильные права на файлы, immutable-атрибуты, нехватка места, блокировка исходящих соединений, особенности прокси и процесс развертывания, возвращающий старые файлы из репозитория.

Безопасная практика выглядит иначе:

• ядро не изменяется напрямую;

• доработки размещаются в поддерживаемых локальных каталогах;

• используются события, локальные модули, шаблоны и переопределения компонентов;

• обновление проверяется в среде, близкой к production;

• перед установкой создается резервная копия;

• процедура отката регулярно тестируется;

• для обновлений безопасности определен максимально допустимый срок задержки.

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

5. bitrixsetup.php, restore.php и другие забытые инструменты

После установки или восстановления в webroot могут остаться:

• bitrixsetup.php;

• restore.php;

• миграционные скрипты;

• импортеры баз данных;

• файловые менеджеры;

• диагностические страницы;

• временные инструменты технической поддержки;

• старые копии с расширениями .bak, .old, .save или .zip.

Иногда доступ к ним «защищают» сложным именем файла или секретом в query string. Это не контроль доступа, а расчет на то, что URL никто не узнает.

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

Правильный жизненный цикл временного инструмента:

1. загрузить перед согласованными работами;

2. ограничить доступ через VPN, сетевой ACL и аутентификацию;

3. выполнить работы;

4. проверить результат;

5. удалить инструмент;

6. просмотреть журнал обращений за период его доступности.

Поиск таких файлов стоит включить как во внутренний аудит файловой системы, так и во внешнее сканирование сайта.

6. Дампы, логи, .git и конфигурация в webroot

Корень сайта часто превращается в склад эксплуатационных артефактов:

/backup_2026.sql.gz
/site-old.zip
/.git/HEAD
/.env
/phpinfo.php
/debug.log
/local/php_interface/dbconn.php.bak

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

Запрещающее правило Nginx или Apache полезно, но не должно быть единственной защитой. Конфигурация меняется, появляются новые виртуальные хосты и алиасы, а резервные файлы получают неожиданные расширения.

Надежнее придерживаться простого правила: чувствительных файлов не должно быть в webroot каталоге.

Дополнительно необходимо:

• отключить листинг каталогов;

• запрещать доступ к dot-файлам;

• блокировать выдачу дампов, архивов, журналов и конфигурационных расширений;

• использовать список разрешенных типов для публичных загрузок;

• проверять сайт с внешнего узла, а не только просматривать конфигурацию сервера.

Внешняя проверка важна: именно она показывает фактический результат работы CDN, reverse proxy, виртуального хоста и правил маршрутизации.

7. Отладка и журналы, которые сами становятся утечкой

В production не должны оставаться включенными:

• режим отладки исключений Bitrix;

• $DBDebug;

• $DBDebugToFile;

• PHP display_errors;

• Xdebug;

• подробная трассировка SMTP или cURL;

• временные отладочные константы.

Расширенная ошибка может показать SQL-запрос, путь к файлу, класс, версию модуля, имя хоста и детали внутренней логики. Журналы иногда содержат еще больше: cookie, токены, тела запросов, персональные данные и строки подключения.

При анализе исходного кода Bitrix можно увидеть несколько путей журналирования внутри корня документов:

• bitrix/modules/error.log;

• mysql_debug.sql;

• bitrix/modules/updater.log;

• modules/updater_partner.log;

• bitrix/modules/serverfilelog-*.dat.

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

Для пользовательских и exception-логов лучше использовать отдельный каталог, например:

/var/log/bitrix/

При этом недостаточно просто изменить путь. Нужны:

• минимальные права на чтение и запись;

• ротация и ограничение размера;

• установленный срок хранения;

• синхронизация времени;

• маскирование секретов;

• защита от подделки;

• передача копии в SIEM.

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

8. Слабая защита административного доступа

Панель администрирования является одной из самых ценных целей. При этом в проектах до сих пор встречаются:

• общие учетные записи администраторов;

• слабые или повторно используемые пароли;

• отсутствие MFA;

• постоянный доступ бывших сотрудников и подрядчиков;

• избыточные права редакторов;

• доступ к административной части из любой сети;

• отсутствие уведомлений о новых администраторах и изменении MFA.

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

Базовые меры:

• индивидуальные учетные записи;

• обязательная MFA для привилегированных пользователей;

• принцип минимальных привилегий;

• регулярный пересмотр доступа;

• быстрое отключение уволенных сотрудников и завершенных подрядчиков;

• ограничение панели через VPN, identity-aware proxy или сетевые ACL;

• журналирование входов, сбросов паролей, изменений групп, прав и MFA;

• оповещения об аномальной активности.

Отдельно проверьте, кому разрешен обход Проактивного фильтра. Удобное право для доверенного редактора увеличивает последствия кражи его учетной записи.

9. Небезопасная конфигурация веб-сервера, PHP и файловой системы

Даже хорошо написанный код работает внутри операционного окружения. Ошибка на этом уровне может свести на нет защиту приложения.

Типичные проблемы:

• устаревшие версии TLS и слабые шифры;

• отсутствие обязательного HTTPS;

• раскрытие версий PHP и веб-сервера;

• публичные status-страницы;

• ненужные HTTP-методы;

• глобальные права 0777;

• возможность веб-процесса изменять весь код сайта;

• выполнение PHP в каталогах загрузки;

• база данных или кеш доступны из интернета;

• приложение, резервное копирование и администрирование используют общие учетные данные.

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

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

Также стоит контролировать заголовок Host, прямой доступ к origin-серверу в обход CDN/WAF и набор разрешенных имен виртуальных хостов.

10. Отсутствие независимого контроля на сервере

Модуль безопасности CMS видит только часть происходящего. Он может зарегистрировать подозрительный HTTP-запрос, но не обязательно обнаружит:

• новый веб-шелл;

• изменение системного cron;

• добавление SSH-ключа;

• запуск подозрительного дочернего процесса PHP;

• исходящее соединение с управляющим сервером;

• кражу данных непосредственно из СУБД;

• отключение или очистку локальных журналов.

Поэтому инсталляции требуют независимого уровня наблюдения:

• Антивирус;

• EDR;

• HIDS или контроль целостности файлов;

• централизованный сбор журналов;

• SIEM корреляция;

• мониторинг процессов и исходящих соединений;

• оповещения об изменении кода, конфигурации и привилегий.

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

Резервные копии также должны быть независимы от приложения. Если PHP-процесс способен удалить production-базу и все ее резервные копии, это не полноценная стратегия восстановления.

Когда запускать SAST, DAST и внешние сканеры

Разовая проверка перед запуском не создает непрерывной безопасности. Изменяется код, инфраструктура, зависимости и внешний периметр.

Практичный базовый график может выглядеть так:

Нагрузочные проверки, тесты восстановления, массовой загрузки, платежей, email/SMS и отказа в обслуживании следует проводить в изолированной среде, если такие тесты в продуктивной среде явно не согласовано.

При этом продуктивную среду нельзя полностью исключать из программы тестирования. Только на нем видны реальные различия в TLS, заголовках, маршрутизации, WAF, CDN, DNS и доступности служебных файлов.

С чего начать аудит существующей инсталляции

Если полноценная программа AppSec еще не построена, начните с короткого списка:

1. Проверьте версию ядра, модулей, PHP, веб-сервера и операционной системы.

2. Убедитесь, что штатный механизм обновления работает и протестирован.

3. Проверьте модуль security, Проактивный фильтр, исключения и MFA.

4. Найдите в webroot установщики, дампы, архивы, логи, .git и диагностические файлы.

5. Отключите отладочный вывод и перенесите журналы из webroot каталога.

6. Запретите выполнение скриптов в каталогах загрузки и временных данных.

7. Пересмотрите административные учетные записи и привилегии.

8. Проверьте резервное копирование реальным восстановлением.

9. Запустите внешний скан, SAST, SCA и аутентифицированный аудит сервера.

10. Назначьте владельца и срок устранения каждой найденной проблемы.

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

Вместо вывода

Безопасность Bitrix редко определяется одной кнопкой или одним обновлением. Это комплексное решение разработчиков, администраторов, DevOps, специалистов по безопасности и владельцев системы.

Хорошо защищенная инсталляция:

• обновляется без ручного редактирования ядра;

• не хранит секреты и эксплуатационные артефакты в webroot;

• не показывает пользователям внутренние ошибки;

• ограничивает административный доступ;

• использует WAF как дополнительный уровень, а не замену исправлениям;

• проверяет пользовательский код и зависимости;

• отправляет события на независимую систему мониторинга;

• умеет восстановиться после сбоев и компрометации.

Дополнительно я собрал расширенный cheat sheet с моделью «Проблема — Риск — Решение». Он доступен в репозитории по ссылке - BITRIX - ТОП-10 ПРОБЛЕМ БЕЗОПАСНОСТИ.