Аудит безопасности Битрикс-сайта: чеклист

Практический чеклист для проверки безопасности 1С-Битрикс. Конфигурация, права, уязвимости, мониторинг.

Дмитрий Мещеряков
Дмитрий Мещеряков
📅 25 сентября 2026 г.📖 10 мин чтения

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

Разберём проверки по слоям — сервер, Битрикс, мониторинг — и в конце соберём приоритеты.

💡 Совет

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

Отсюда практический вывод: если времени на весь аудит нет, начните с трёх вещей — обновите систему и модули, включите 2FA для администраторов, проверьте список активных администраторов. Это займёт полдня и закроет больше, чем весь остальной список.

Зачем аудит безопасности

Аудит безопасности — это последовательная проверка сайта по слоям: конфигурация сервера, настройки самого Битрикса, права доступа и мониторинг. Битрикс — популярная CMS в России, а значит популярная цель, и типичные проблемы у неё повторяются:

  • Устаревшие версии с известными уязвимостями
  • Открытые административные пути
  • Избыточные права пользователей
  • Уязвимые сторонние модули
⚠️ Важно

В 2022–2024 годах волна взломов Битрикс-сайтов затронула тысячи проектов. Большинство атак эксплуатировали известные уязвимости в необновлённых системах.

Чеклист: конфигурация сервера

1. Версии ПО

bash
# Проверка версий
php -v          # PHP 8.1+ рекомендуется
mysql --version # MySQL 8.0+ или MariaDB 10.5+
nginx -v        # Актуальная stable-ветка

Критично:

  • PHP ≥ 8.1 (8.0 EOL в ноябре 2023)
  • MySQL ≥ 8.0 или MariaDB ≥ 10.5
  • nginx/Apache с последними патчами безопасности

2. PHP-конфигурация

ini
; /etc/php/8.1/fpm/php.ini — безопасные настройки

; Отключаем опасные функции
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

; Скрываем версию PHP
expose_php = Off

; Ограничиваем ресурсы
memory_limit = 256M
max_execution_time = 30
max_input_time = 60
post_max_size = 32M
upload_max_filesize = 32M

; Безопасность сессий
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Strict
session.use_strict_mode = 1

; Отключаем вывод ошибок на продакшене
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log

3. Права на файлы

bash
# Проверка прав
find /var/www/site -type f -perm 0777 -ls
find /var/www/site -type d -perm 0777 -ls

# Правильные права
# Файлы: 644, директории: 755
# Исключения для upload и cache: 775
find /var/www/site -type f -exec chmod 644 {} \;
find /var/www/site -type d -exec chmod 755 {} \;
chmod -R 775 /var/www/site/upload
chmod -R 775 /var/www/site/bitrix/cache
chmod -R 775 /var/www/site/bitrix/managed_cache

# Владелец — веб-сервер
chown -R www-data:www-data /var/www/site

Чеклист:

  • Нет файлов/директорий с правами 777
  • Владелец файлов — пользователь веб-сервера
  • Только upload/cache доступны для записи

4. nginx-конфигурация

nginx
server {
    # HTTPS обязателен
    listen 443 ssl http2;
    
    # Безопасные заголовки
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';" always;
    
    # Скрываем версию nginx
    server_tokens off;
    
    # Запрещаем доступ к служебным файлам
    location ~ /\.(ht|git|svn) {
        deny all;
    }
    
    # Закрываем bitrix/php_interface
    location ~* ^/bitrix/(modules|php_interface)/ {
        deny all;
    }
    
    # Закрываем .settings.php и подобные
    location ~* \.(settings|connection)\.php$ {
        deny all;
    }
    
    # Ограничиваем доступ к админке по IP
    location /bitrix/admin/ {
        allow 192.168.1.0/24;  # Ваш офис
        allow 10.0.0.0/8;       # VPN
        deny all;
        
        try_files $uri $uri/ @bitrix;
    }
    
    # Rate limiting для /bitrix/tools/
    location /bitrix/tools/ {
        limit_req zone=tools burst=5 nodelay;
        try_files $uri @bitrix;
    }
}

# Rate limit zone
limit_req_zone $binary_remote_addr zone=tools:10m rate=10r/s;

Чеклист:

  • HTTPS включён и работает
  • Безопасные заголовки добавлены
  • Доступ к .git, .ht* заблокирован
  • Админка ограничена по IP или VPN
  • Rate limiting для критичных эндпоинтов

Чеклист: конфигурация Битрикс

1. Версия и обновления

php
// Проверка версии ядра
// /bitrix/modules/main/classes/general/version.php
define("SM_VERSION", "24.200.200");

// Или через админку
// Настройки → Инструменты → Диагностика → Проверка системы

Критично:

  • Ядро Битрикс обновлено до актуальной версии
  • Все модули обновлены
  • Подписка на обновления активна

2. Проактивная защита

Админка → Настройки → Проактивная защита:

  • WAF — включён, правила обновлены
  • Контроль активности — включён
  • Защита от DDoS — настроена
  • Стоп-лист — автоматическая блокировка
  • Монитор качества — без критичных ошибок
php
// Принудительное включение проактивной защиты
// /bitrix/.settings.php
'security' => [
    'value' => [
        'security_session' => true,
        'security_session_timeout' => 15,
        'security_session_expansion' => 'N',
    ],
],

3. Настройки безопасности

php
// /bitrix/.settings.php
return [
    'crypto' => [
        'value' => [
            'crypto_key' => 'СГЕНЕРИРУЙТЕ_СЛУЧАЙНЫЙ_КЛЮЧ_МИНИМУМ_32_СИМВОЛА',
        ],
    ],
    'sessions' => [
        'value' => [
            'mode' => 'default',
            'handlers' => [
                'general' => [
                    'type' => 'file',
                    'lifetime' => 86400,
                ],
            ],
        ],
    ],
    'exception_handling' => [
        'value' => [
            'debug' => false, // ВАЖНО: false на продакшене
            'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT,
            'log' => [
                'settings' => [
                    'file' => '/var/log/bitrix/exceptions.log',
                ],
            ],
        ],
    ],
];

Чеклист:

  • debug выключен на продакшене
  • Уникальный crypto_key установлен
  • Логи настроены и пишутся

4. Права пользователей

sql
-- Найти пользователей с административными правами
SELECT u.ID, u.LOGIN, u.EMAIL, u.LAST_LOGIN, g.NAME as GROUP_NAME
FROM b_user u
JOIN b_user_group ug ON u.ID = ug.USER_ID
JOIN b_group g ON ug.GROUP_ID = g.ID
WHERE g.ID = 1  -- Администраторы
ORDER BY u.LAST_LOGIN DESC;

-- Найти неактивных админов (не заходили > 90 дней)
SELECT u.ID, u.LOGIN, u.LAST_LOGIN
FROM b_user u
JOIN b_user_group ug ON u.ID = ug.USER_ID
WHERE ug.GROUP_ID = 1 
  AND (u.LAST_LOGIN < DATE_SUB(NOW(), INTERVAL 90 DAY) OR u.LAST_LOGIN IS NULL);

Чеклист:

  • Минимум администраторов (1-2 человека)
  • Неактивные админы деактивированы
  • Сложные пароли (12+ символов, спецсимволы)
  • 2FA включена для администраторов

5. Аудит модулей

bash
# Список установленных модулей
ls -la /var/www/site/bitrix/modules/

# Проверка сторонних модулей на уязвимости
# Ищем подозрительные паттерны
grep -r "eval(" /var/www/site/local/modules/
grep -r "base64_decode" /var/www/site/local/modules/
grep -r "\$_REQUEST" /var/www/site/local/modules/
grep -r "unserialize" /var/www/site/local/modules/

Чеклист:

  • Удалены неиспользуемые модули
  • Сторонние модули проверены на уязвимости
  • Aspro-модули обновлены (частые уязвимости)

Чеклист: мониторинг

1. Логи безопасности

bash
# Структура логов
/var/log/
├── nginx/
│   ├── access.log
│   └── error.log
├── php/
│   └── error.log
└── bitrix/
    ├── exceptions.log
    └── security.log

# Мониторинг подозрительной активности
tail -f /var/log/nginx/access.log | grep -E "(wp-|admin\.php|shell|eval)"

# Поиск атак в логах
grep -E "(sqlmap|nikto|nmap|masscan)" /var/log/nginx/access.log
grep "POST /bitrix/tools" /var/log/nginx/access.log | head -100

2. Мониторинг файлов

bash
# Установка AIDE (Advanced Intrusion Detection Environment)
apt install aide

# Инициализация базы
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Проверка изменений (запускать по cron)
aide --check

# Или простой мониторинг через inotify
apt install inotify-tools

# Мониторинг критичных директорий
inotifywait -m -r -e create,modify,delete /var/www/site/bitrix/modules/

3. Cron для регулярных проверок

bash
# /etc/cron.d/bitrix-security

# Ежедневная проверка прав
0 3 * * * root find /var/www/site -type f -perm 0777 -exec chmod 644 {} \;

# Еженедельный аудит файлов
0 4 * * 0 root aide --check > /var/log/aide/weekly.log 2>&1

# Ежедневная проверка обновлений
0 5 * * * root /var/www/site/bitrix/php_interface/cron_update_check.php

4. Alerting

php
// /local/php_interface/security_monitor.php
<?php
use Bitrix\Main\Mail\Event;

class SecurityMonitor
{
    private const ALERT_EMAIL = 'admin@example.com';
    
    public static function checkSuspiciousActivity(): void
    {
        global $DB;
        
        // Проверка failed login attempts
        $failedLogins = $DB->Query("
            SELECT COUNT(*) as cnt 
            FROM b_event_log 
            WHERE AUDIT_TYPE_ID = 'USER_LOGIN' 
              AND DESCRIPTION LIKE '%failed%'
              AND TIMESTAMP_X > DATE_SUB(NOW(), INTERVAL 1 HOUR)
        ")->Fetch();
        
        if ($failedLogins['cnt'] > 10) {
            self::alert('Много неудачных попыток входа: ' . $failedLogins['cnt']);
        }
        
        // Проверка новых админов
        $newAdmins = $DB->Query("
            SELECT u.LOGIN, ug.DATE_ACTIVE_FROM
            FROM b_user u
            JOIN b_user_group ug ON u.ID = ug.USER_ID
            WHERE ug.GROUP_ID = 1
              AND ug.DATE_ACTIVE_FROM > DATE_SUB(NOW(), INTERVAL 1 DAY)
        ");
        
        while ($admin = $newAdmins->Fetch()) {
            self::alert('Новый администратор: ' . $admin['LOGIN']);
        }
    }
    
    private static function alert(string $message): void
    {
        Event::send([
            'EVENT_NAME' => 'SECURITY_ALERT',
            'LID' => 's1',
            'C_FIELDS' => [
                'MESSAGE' => $message,
                'DATE' => date('Y-m-d H:i:s'),
            ],
        ]);
    }
}

Экстренные действия при взломе

1. Изоляция

bash
# Отключаем сайт
mv /var/www/site /var/www/site_compromised
echo "Сайт на обслуживании" > /var/www/site/index.html

# Или через nginx
# location / { return 503; }

# Блокируем исходящие соединения
iptables -A OUTPUT -j DROP
iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT

2. Анализ

bash
# Поиск изменённых файлов за последние 7 дней
find /var/www/site_compromised -mtime -7 -type f -ls > /tmp/changed_files.log

# Поиск подозрительных файлов
find /var/www/site_compromised -name "*.php" -exec grep -l "eval(base64_decode" {} \;
find /var/www/site_compromised -name "*.php" -exec grep -l "FilesMan\|WSO\|c99" {} \;

# Поиск webshell'ов
grep -r "passthru\|shell_exec\|system\|exec" /var/www/site_compromised --include="*.php"

3. Восстановление

bash
# Восстановление из бэкапа
# 1. Определить дату компрометации
# 2. Найти бэкап до этой даты
# 3. Восстановить файлы
# 4. Восстановить БД
# 5. Обновить все пароли
# 6. Обновить Битрикс и модули

Итоговый чеклист

Критично (P0)

  • PHP и MySQL актуальных версий
  • Битрикс обновлён
  • HTTPS включён
  • Админка ограничена по IP
  • Нет файлов с правами 777
  • debug=false на продакшене

Важно (P1)

  • Проактивная защита включена
  • 2FA для администраторов
  • Безопасные заголовки настроены
  • Логи пишутся и мониторятся
  • Регулярные бэкапы

Желательно (P2)

  • AIDE или аналог для мониторинга файлов
  • Alerting на подозрительную активность
  • WAF (ModSecurity или CloudFlare)
  • Регулярный внешний аудит

Как сделать так, чтобы этот чек-лист работал

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

Назначьте владельца и периодичность. Раз в квартал, конкретный человек, результат — письменный. Без этого аудит превращается в разовую акцию после инцидента.

Автоматизируйте то, что автоматизируется. Проверка версий ПО, прав на директории, наличия отладочных файлов в корне, списка администраторов — всё это скрипт, который можно запускать по расписанию и получать отчёт на почту. Руками стоит проверять только то, что требует суждения.

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

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

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

⚠️ Важно

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

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

С чего начать аудит безопасности Битрикс-сайта?

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

Что проверять в конфигурации сервера?

Версии ПО: PHP не ниже 8.1, MySQL от 8.0 или MariaDB от 10.5, свежие патчи веб-сервера. Настройки PHP: отключённые опасные функции, скрытая версия, запрет выполнения в каталогах загрузки. Права на файлы: ни одной директории с правами 777, владелец — пользователь веб-сервера, на запись доступны только каталоги загрузки и кэша. И конфигурацию веб-сервера: работающий HTTPS и заголовки безопасности.

Какие права на файлы считаются безопасными?

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

Что настроить в самом Битриксе?

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

Что делать при обнаружении взлома?

Сначала закрыть точку входа, потом отозвать все доступы — пароли администраторов, FTP и SSH, базы, API-ключи, включая ключи в authorized_keys. Затем инвентаризовать изменения по времени модификации файлов и сверке с репозиторием, проверить cron и список администраторов. И только после этого разворачивать чистую копию: точечная чистка почти всегда заканчивается повторным заражением, потому что где-то остаётся второй веб-шелл.

Как сделать так, чтобы чек-лист безопасности работал?

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