Чек-лист безопасности полезен ровно настолько, насколько по нему реально проходят. Поэтому здесь важнее не длина списка, а порядок: пункты отсортированы так, чтобы первые пять закрывали большую часть реальных сценариев взлома, а не самые интересные.
Разберём проверки по слоям — сервер, Битрикс, мониторинг — и в конце соберём приоритеты.
Прежде чем начинать: подавляющее большинство взломов сайтов на Битриксе происходит не через изощрённые уязвимости. Это необновлённое ядро или решение с известной публичной уязвимостью, слабый пароль администратора и оставленный кем-то файл в корне сайта.
Отсюда практический вывод: если времени на весь аудит нет, начните с трёх вещей — обновите систему и модули, включите 2FA для администраторов, проверьте список активных администраторов. Это займёт полдня и закроет больше, чем весь остальной список.
Зачем аудит безопасности
Аудит безопасности — это последовательная проверка сайта по слоям: конфигурация сервера, настройки самого Битрикса, права доступа и мониторинг. Битрикс — популярная CMS в России, а значит популярная цель, и типичные проблемы у неё повторяются:
- Устаревшие версии с известными уязвимостями
- Открытые административные пути
- Избыточные права пользователей
- Уязвимые сторонние модули
В 2022–2024 годах волна взломов Битрикс-сайтов затронула тысячи проектов. Большинство атак эксплуатировали известные уязвимости в необновлённых системах.
Чеклист: конфигурация сервера
1. Версии ПО
# Проверка версий
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-конфигурация
; /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.log3. Права на файлы
# Проверка прав
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-конфигурация
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. Версия и обновления
// Проверка версии ядра
// /bitrix/modules/main/classes/general/version.php
define("SM_VERSION", "24.200.200");
// Или через админку
// Настройки → Инструменты → Диагностика → Проверка системыКритично:
- Ядро Битрикс обновлено до актуальной версии
- Все модули обновлены
- Подписка на обновления активна
2. Проактивная защита
Админка → Настройки → Проактивная защита:
- WAF — включён, правила обновлены
- Контроль активности — включён
- Защита от DDoS — настроена
- Стоп-лист — автоматическая блокировка
- Монитор качества — без критичных ошибок
// Принудительное включение проактивной защиты
// /bitrix/.settings.php
'security' => [
'value' => [
'security_session' => true,
'security_session_timeout' => 15,
'security_session_expansion' => 'N',
],
],3. Настройки безопасности
// /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. Права пользователей
-- Найти пользователей с административными правами
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. Аудит модулей
# Список установленных модулей
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. Логи безопасности
# Структура логов
/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 -1002. Мониторинг файлов
# Установка 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 для регулярных проверок
# /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.php4. Alerting
// /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. Изоляция
# Отключаем сайт
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 ACCEPT2. Анализ
# Поиск изменённых файлов за последние 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. Восстановление
# Восстановление из бэкапа
# 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 и список администраторов. И только после этого разворачивать чистую копию: точечная чистка почти всегда заканчивается повторным заражением, потому что где-то остаётся второй веб-шелл.
Как сделать так, чтобы чек-лист безопасности работал?
Превратить его в расписание, а не в разовое мероприятие. Часть пунктов проверяется автоматически: обновления, свободное место, изменения файлов, доступность сайта. Часть — раз в квартал глазами: список администраторов, права, актуальность модулей. Чек-лист, по которому прошли один раз при запуске, устаревает за месяцы, и его ценность стремится к нулю.