Безопасность CMS: 7 практик, которые спасут от взлома

Введение: модель угроз для типичного сайта на CMS

Угроза №1 — массовые автоматические атаки по известным уязвимостям тем и плагинов. №2 — слабые пароли и повторное использование учётных данных. №3 — плохая конфигурация сервера: избыточные права, исполняемый PHP в /uploads, отсутствие WAF и логирования. Мы строим защиту по слоям: от кода CMS и плагинов — к веб-серверу, сети и резервным копиям.

• Поверхность атаки:админ-панель, формы, REST API, загрузки файлов, XML-RPC, cron.
• Векторы:SQLi, XSS, CSRF, LFI/RFI, brute force, уязвимые зависимости, poisoned plugin updates.
• Цели злоумышленника:спам/редиректы, бекдоры, кража БД, пивот в инфраструктуру.

Практика №1. Обновления ядра, плагинов и зависимостей

Большинство инцидентов — последствия неустановленных патчей. Обновления закрывают CVE, меняют алгоритмы хеширования, усиливают аутентификацию и очищают небезопасные API. Обновляем всё: ядро CMS, темы, плагины, composer/npm-зависимости, PHP и OpenSSL.

Процесс обновлений

1. Прод/стейдж/локал. На стейдже автосборка, smoke-тест, затем релиз на прод.
2. Снапшот БД и файлов перед обновлением.
3. Лог изменений: что обновлено, версия, дата, ответственный.
4. Мониторинг 24 часа после релиза (ошибки 5xx/4xx, скорость, аномалии в логах).

Практика №2. Минимальные привилегии и сегментация

Ни один сайт не должен работать от root. Привилегии — минимальные. Доступ — сегментирован. В панели CMS только нужные роли, в системе — отдельные пользователи для PHP-FPM, БД и деплоя.

Права файлов и каталогов

• Файлы: 0644, каталоги: 0755, конфиги: 0600.
• В /uploads: запрет исполнения PHP/CGI.
• Отдельный пользователь для php-fpmи владельца веб-контента.

Примеры конфигурации

location ~* ^/uploads/.*\.(php|phar|phtml)${ return 403;}
location /uploads/{ autoindex off; add_header X-Content-Type-Options nosniff;}

<Directory "uploads"> php_flag engine off RemoveHandler .php .phtml .php3 .php4 .php5 .php7 .phar <FilesMatch "\.(php|phar|phtml)$"> Require all denied </FilesMatch>
</Directory>

В БД создайте отдельного пользователя с SELECT/INSERT/UPDATE/DELETEи без DROP/ALTER, если CMS не требует миграций на проде.

Практика №3. Безопасная аутентификация: 2FA, пароли, ограничение доступа

Лучшая защита панели — сложные пароли + 2FA + ограничение по IP/стране. Брутфорс останавливается rate-limit и блокировками.

• Пароли: длина 12+, менеджер паролей, уникальные на каждого пользователя.
• 2FA: TOTP (Google Authenticator/Authy), резервные коды.
• Ограничение по IP: доступ в /admin только с белых списков.
• Блокировка по неудачным попыткам: Fail2Ban/WAF-правила.

[nginx-auth]
enabled=true
port=http,https
filter=nginx-auth
logpath=/var/log/nginx/*error*.log
maxretry=5
bantime=3600

Отключите XML-RPC и стандартные «/xmlrpc.php» если CMS это поддерживает, либо ограничьте по IP.

Практика №4. Конфигурация сервера: HTTPS, HSTS, WAF, заголовки

HTTPS обязателен. Включаем HSTS, строгие политики контента и типы защиты в заголовках. В идеале — WAF на уровне веб-сервера или CDN.

Базовые security-заголовки

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

Content-Security-Policy (минимум)

add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:;
script-src 'self' 'nonce-{{nonce}}' https:; style-src 'self' 'unsafe-inline' https:;
object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

Для форм — включите SameSite=Laxдля cookies сессий, флаг Secureи HttpOnly.

Практика №5. Защита от SQLi, XSS и CSRF на уровне приложения

Любой пользовательский ввод — недоверенный. Применяем валидацию, экранирование, токены и параметризованные запросы.

• SQLi: только prepared statements/ORM, запрет конкатенации SQL.
• XSS: экранирование HTML, очистка WYSIWYG, CSP, запрещённый innerHTMLдля пользовательских данных.
• CSRF: токены в каждой POST-форме, проверка Origin/Referer.
• Загрузка файлов: проверка mime и расширения, перегенерация имени, хранение за пределами web-root, в идеале — на объектном хранилище.

location /{ if ($query_string ~* "(union.*select|select.+from|concat\()"){ return 403;} if ($request_uri ~* "\.(bak|sql|swp|git|env)$"){ return 403;}}

Отключите опасные функции PHP: disable_functions=exec,passthru,shell_exec,system,proc_open,popen,show_source. Включите open_basedir, expose_php=Off.

Практика №6. Резервное копирование, контроль целостности и восстановление

Бэкапы — последняя линия защиты. Их отсутствие превращает любой инцидент в катастрофу. Стратегия 3–2–1: три копии, два типа носителей, одна — вне площадки.

Что бэкапить

• База данных (полные + инкрементальные).
• Каталоги приложения и /uploads.
• Конфиги веб-сервера, php.ini, crontab, unit-файлы systemd.
• Секреты: .env/ключи — в отдельном хранилище секретов.

График и хранение

• Снимки БД: ежедневно/каждые 6 часов для критичных систем.
• Файлы: ежедневно. Хранение 7–30 дней плюс ежемесячные — до 6–12 месяцев.
• Хранилище: S3-совместимое с версионированием и MFA-delete.

Контроль целостности

Используйте хеш-деревья или инструменты: Tripwire, AIDE, Wordfence/Bitrix Inspector. Настройте уведомления о любых изменениях в веб-корне вне процесса деплоя.

Практика №7. Наблюдаемость и реагирование: логи, алерты, playbook

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

Что логировать

• Доступ и ошибки веб-сервера: $remote_addr, UA, referrer, request_time, статус, размер ответа.
• Авторизации, изменения ролей, изменения настроек, установки/удаления плагинов.
• Исключения приложения, медленные запросы БД.

Алерты

• Рост 4xx/5xx на X% за Y минут.
• Всплеск POST на /wp-login.php, /admin/, /xmlrpc.php.
• Изменения в веб-корне вне деплоя (inotify, hash-сканер).

Incident Response Playbook

1. Изоляция: бэкап текущего состояния, перевод в режим readonly/maintenance.
2. Сбор артефактов: логи, дампы, хеши изменённых файлов.
3. Устранение: удаление бекдоров, патчи, ротация ключей/паролей.
4. Восстановление: из чистого бэкапа + патчи.
5. Постмортем: причина, точка входа, изменения в контролях.

Практика 7½. Сокращение поверхности атаки

• Удаляйте неиспользуемые плагины/темы и демо-файлы.
• Отключите directory listing: autoindex off/ Options -Indexes.
• Скройте версию CMS в метатегах и HTTP-заголовках.
• Ограничьте доступ к /wp-admin, /bitrix/, /administratorпо IP или через VPN.

Hardening для популярных CMS

Чек-лист перед релизом и ежемесячная рутина

Итог

Безопасность CMS — это не разовая «настройка безопасности», а режим работы: регулярные обновления, минимальные права, сильная аутентификация, безопасная конфигурация сервера, защита от инъекций и XSS, бэкапы и мониторинг с планом реагирования. Эти семь практик снимают основной риск и превращают случайный инцидент из кризиса в рутинную операцию восстановления.