Безопасность сайта на Битрикс держится не на одном антивирусном модуле из коробки - за пять с лишним лет работы с проектами на 1С-Битрикс я видел, что взлом обычно проходит через связку из трёх-четырёх мелких недосмотров: старую версию модуля, открытую админку без ограничений по IP и забытый тестовый файл с правами 777. Разберу, где чаще всего находят вход в такие сайты и что реально снижает риск, а не просто создаёт видимость защиты.
Почему сайты на 1С-Битрикс - частая цель
CMS с долгой историей и большой долей рынка интернет-магазинов и корпоративных сайтов в России попадает в список приоритетных целей у ботов, которые сканируют IP-диапазоны хостингов на предмет уязвимых версий. Атакующему не нужно целиться конкретно в ваш сайт - достаточно массового скана по сигнатурам известных дыр в старых редакциях модулей.
На практике вижу три сценария заражения: автоматический перебор через известные CVE в устаревших компонентах, брутфорс пароля админа через форму авторизации без ограничения попыток и заливка шелла через уязвимый инфоблок или фотогалерею, куда можно закинуть файл с расширением php. Ни один из них не требует от злоумышленника глубоких знаний - работают готовые скрипты, которые перебирают тысячи доменов за ночь.
Типичные дыры: где чаще всего находят вход
Неактуальное ядро и модули
Битрикс выпускает обновления безопасности регулярно, но на многих проектах их откладывают месяцами из-за страха что-то сломать в кастомном шаблоне. В результате известные уязвимости в старых версиях модулей остаются рабочими годами - я встречал сайты, где ядро не обновлялось с 2021 года, притом что «Проверка безопасности» в административной панели явно показывала критичные предупреждения.
Открытая админка и слабая авторизация
Путь /bitrix/admin/ по умолчанию доступен с любого IP-адреса, а форма входа без ограничения попыток превращается в мишень для брутфорса. Добавьте сюда пароль вида «Company2020» у администратора, который выдавали при запуске сайта и ни разу не меняли, и получите почти гарантированный вход при достаточном терпении атакующего.
Компоненты и шаблоны от сторонних разработчиков
Отдельная больная тема - самописные компоненты и купленные на маркетплейсе шаблоны, где переменные из $_REQUEST или $_GET выводятся на страницу без экранирования. Это прямой путь к XSS и SQL-инъекциям, причём разработчик шаблона часто уже недоступен для доработки, а качество кода никто не проверял перед установкой.
Ниже - таблица с дырами, которые встречаются чаще всего в моей практике аудита чужих проектов.
| Уязвимость | Как проявляется | Что делать |
|---|---|---|
| Неактуальное ядро и модули | Известные CVE остаются рабочими, эксплойты доступны публично | Обновлять раз в 1-2 месяца, проверять «Проверку безопасности» в панели |
| Открытая админка без ограничений | /bitrix/admin/ доступен с любого IP, идёт постоянный брутфорс | Ограничить доступ по IP через .htaccess, включить двухфакторную авторизацию |
| Права на файлы 777 | Веб-сервер и PHP-скрипты пишут в те же папки, куда можно залить шелл | Выставить 644/755, отключить выполнение PHP в /upload |
| Сторонние компоненты и шаблоны | Неэкранированный вывод параметров запроса, отсюда XSS и SQL-инъекции | Аудит кода перед установкой, отключение debug-вывода на проде |
| Ключи интеграций в открытом виде | Данные эквайринга или API СДЭК лежат в файле без ограничения доступа | Хранить ключи вне веб-корня, закрыть каталог от прямого обращения |
Проактивная защита: что настраивать до инцидента, а не после
Проактивная защита в Битриксе - не только штатный модуль с таким названием, а подход в целом: закрыть типовые пути атаки заранее, а не разбирать последствия ночью в выходной. С модуля стоит начать в любом случае - он у большинства тарифов включён, но часть функций (веб-антивирус, контроль активности, HTTP-фильтр) активируется отдельно и по умолчанию работает не на полную мощность.
Из того, что делаю на каждом проекте вне зависимости от масштаба:
- Меняю путь к административной панели на нестандартный и ограничиваю доступ по IP для сотрудников с постоянным адресом
- Включаю двухфакторную авторизацию для всех аккаунтов с правами администратора, без исключений для «удобства»
- Отключаю индексацию служебных каталогов и закрываю /bitrix/php_interface/ и /upload/ от выполнения PHP
- Настраиваю HTTP-фильтр модуля проактивной защиты на блокировку типовых сигнатур SQL-инъекций и XSS
- Убираю тестовые и демо-файлы, которые часто остаются после разработки - install.php, backup-архивы, старые дампы базы
Отдельно слежу за интеграциями с внешними сервисами - эквайрингом вроде Т‑Банка или доставкой через СДЭК. Ключи и токены таких API нередко живут прямо в коде компонента вместо переменных окружения, и при компрометации сайта это открывает доступ не только к самому магазину, но и к платёжным данным или личному кабинету службы доставки.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Настройка сервера и firewall под Битрикс
Часть защиты решается не в самой CMS, а на уровне сервера. Из практики - минимальный набор, который закрывает большинство автоматических атак ещё до того, как запрос дойдёт до PHP:
- Ограничение количества запросов с одного IP (rate limit) на nginx или через панель хостинга - снижает эффективность брутфорса и DDoS на форму авторизации
- WAF на уровне хостинга или облачного прокси - фильтрует типовые паттерны атак до попадания в приложение
- Закрытие портов, кроме 80/443 и SSH с ограниченным списком IP
- Регулярное обновление PHP и веб-сервера - часть уязвимостей находится не в Битриксе, а в окружении
- Отдельный пользователь и права на файловую систему для каждого сайта, если на сервере их несколько - иначе компрометация одного проекта открывает доступ ко всем соседям
На практике этот пункт чаще всего пропускают на дешёвом виртуальном хостинге, где нет доступа к настройкам сервера в принципе. Если бюджет и задача дают такую возможность - перенос на VPS с собственным контролем над окружением снимает половину проблем разом.
Резервное копирование и план действий при компрометации
Резервная копия не заменяет защиту, но определяет, во сколько часов простоя обойдётся инцидент. Держу правило: минимум ежедневный бэкап базы, еженедельный - полного окружения с файлами, копии - вне сервера, где лежит сайт, иначе при компрометации хостинга теряется и сайт, и его резервные копии одновременно.
Если компрометация всё же произошла, порядок действий такой:
- Изолировать сайт - закрыть доступ извне (maintenance-режим или блокировка на уровне сервера), чтобы не расширять ущерб и не давать боту продолжать работу
- Сравнить текущие файлы ядра с эталонными версиями через штатный инструмент «Проверка безопасности» - это быстро покажет изменённые системные файлы
- Проверить cron-задания, новые файлы в /upload/ и /bitrix/php_interface/ на предмет подброшенных шеллов
- Сменить все пароли и API-ключи интеграций - не только админку, но и доступы к базе, FTP, эквайрингу
- Восстановить из чистой резервной копии, если найти все изменения вручную не получается за разумное время
Для проверки целостности файлов ядра и типовых системных путей у меня есть отработанный скрипт на bash, который сверяет контрольные суммы с эталоном и присылает отчёт - беру его за основу почти на каждом аудите, экономит несколько часов ручной сверки. Похожие заготовки для типовых задач администрирования собраны в библиотеке готовых скриптов.
Мониторинг и логи - как заметить проблему раньше, чем клиенты
Без мониторинга компрометация обнаруживается либо когда сайт попадает в чёрные списки поисковиков, либо когда клиенты начинают жаловаться на редиректы на сторонние ресурсы. Оба сценария означают, что вредоносный код прожил на сайте уже несколько дней или недель.
Что смотрю регулярно на сопровождаемых проектах:
- Логи веб-антивируса и HTTP-фильтра модуля проактивной защиты - фиксируют попытки атак ещё до их успеха
- Историю входов в административную панель - новые IP или время входа вне рабочих часов клиента
- Список активных пользователей и их прав - лишние учётные записи с правами администратора появляются чаще, чем кажется
- Изменения файлов ядра и шаблонов через контрольные суммы
Уведомления о подозрительной активности удобно собирать в одном месте - например, через сценарий в n8n, который раз в час дёргает лог модуля безопасности и присылает алерт в мессенджер при первом же неуспешном входе с нового IP. Настраивается один раз, а экономит время на ручную проверку логов каждый день.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Сколько стоит аудит безопасности сайта на Битрикс
Разовая консультация с разбором конкретных настроек и рисков - от 3 000 ₽. Если нужен полноценный аудит с проверкой кода компонентов, прав доступа и настройкой сервера - оценка идёт по объёму работ после обзора текущего состояния сайта.
Хватит ли штатного модуля проактивной защиты без дополнительных настроек
Модуль закрывает часть типовых атак из коробки, но многие функции - HTTP-фильтр, веб-антивирус, контроль активности - требуют ручной активации и настройки под конкретный проект. Без этого часть возможностей модуля просто не работает.
Как часто нужно обновлять ядро и модули Битрикс
Оптимально - раз в 1-2 месяца, сразу после выхода обновлений безопасности, а не по остаточному принципу. Перед обновлением на проде стоит проверять совместимость с кастомным кодом на тестовом окружении, чтобы не сломать интеграции с эквайрингом или доставкой.
Можно ли восстановить сайт после компрометации без потери данных
В большинстве случаев да, если есть чистая резервная копия и логи для определения момента заражения. Без бэкапа восстановление сводится к ручной очистке файлов и базы от вредоносного кода, что занимает заметно больше времени и не даёт стопроцентной гарантии, что все следы удалены.