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

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

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

Актуальный OWASP Top 10 относит к основным рискам веб-приложений нарушения контроля доступа, ошибки конфигурации, проблемы цепочки поставки программного обеспечения, криптографические ошибки, инъекции и сбои аутентификации. Для сайта на CMS эти категории напрямую связаны с состоянием ядра, расширений, пользователей, шаблонов и инфраструктуры.

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

Что может произойти после взлома CMS

Компрометация сайта не всегда выглядит как удалённая главная страница с сообщением злоумышленника. Значительная часть атак старается оставаться незаметной.

После получения доступа атакующий может:

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

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

Сначала определите поверхность атаки

Перед настройкой защиты необходимо составить перечень компонентов проекта.

Проверьте:

• версию CMS;
• установленные расширения и темы;
• серверную операционную систему;
• версию PHP, Node.js или другого runtime;
• Composer- и npm-зависимости;
• веб-сервер;
• базу данных;
• административные и редакторские учётные записи;
• формы и загрузку файлов;
• API и вебхуки;
• cron и планировщики;
• почтовые сервисы;
• облачные хранилища;
• CDN и WAF;
• резервное копирование;
• доступы подрядчиков;
• тестовые и старые версии сайта.

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

Практика 1. Обновляйте CMS и контролируйте цепочку поставки

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

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

Что необходимо обновлять

• ядро CMS;
• плагины, модули и дополнения;
• активную и неактивные темы;
• PHP и серверные расширения;
• веб-сервер;
• операционную систему;
• Composer-зависимости;
• npm-пакеты;
• библиотеки редактора, галереи и загрузчика файлов;
• панель управления сервером;
• агент резервного копирования;
• контейнерные образы;
• WAF и его наборы правил.

Удаляйте неиспользуемые компоненты

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

Удаляйте:

• неиспользуемые плагины;
• старые темы;
• демонстрационные компоненты;
• архивы установщиков;
• резервные копии внутри web-root;
• временные файлы миграции;
• устаревшие версии API;
• тестовые скрипты;
• неиспользуемые библиотеки.

Проверяйте происхождение расширений

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

Перед установкой оцените:

• кто поддерживает проект;
• когда выпускалось последнее обновление;
• поддерживается ли текущая версия CMS;
• как публикуются сообщения об уязвимостях;
• сколько сторонних зависимостей используется;
• нужны ли расширению запрашиваемые права;
• существует ли понятный способ удаления;
• можно ли обойтись штатными функциями CMS.

Не обновляйте production вслепую

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

1. инвентаризация компонентов;
2. уведомления о новых версиях и уязвимостях;
3. резервная копия перед изменением;
4. тестовая среда;
5. проверка основных сценариев;
6. план отката;
7. журнал обновлений;
8. наблюдение после публикации.

Разделяйте обновления по срочности

Проверяйте зависимости автоматически

В процесс разработки можно включить:

composer audit
npm audit

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

Практика 2. Используйте минимальные права и сильную аутентификацию

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

Каждому пользователю нужна отдельная учётная запись

Общий логин «admin» для нескольких сотрудников не позволяет определить, кто изменил настройки, установил модуль или удалил страницу.

Отдельные учётные записи дают возможность:

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

Применяйте принцип минимальных привилегий

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

Разделяйте роли:

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

Официальная документация WordPress отдельно описывает роли и возможности для ограничения действий пользователей. Аналогичные механизмы существуют в других современных CMS.

Включите многофакторную аутентификацию

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

Приоритетные варианты:

• аппаратный ключ безопасности;
• WebAuthn или passkey;
• TOTP-приложение;
• резервные одноразовые коды.

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

Установите правила паролей

• уникальный пароль для каждого сервиса;
• достаточная длина;
• использование менеджера паролей;
• запрет распространённых и скомпрометированных комбинаций;
• отсутствие общих паролей команды;
• немедленная смена после подозрения на утечку;
• безопасное хранение резервных кодов.

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

Защитите форму входа

Для административной панели полезны:

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

OWASP рекомендует применять надёжную аутентификацию, защищать восстановление доступа и ограничивать автоматизированные попытки входа.

Контролируйте жизненный цикл доступа

Не реже одного раза в месяц проверяйте:

• кто имеет административные права;
• какие учётные записи не использовались;
• кто покинул компанию;
• какие подрядчики завершили работу;
• какие API-ключи активны;
• где используются служебные пароли;
• когда обновлялись токены и секреты.

Практика 3. Сократите поверхность атаки и укрепите сервер

CMS работает внутри более крупной системы. Ошибка веб-сервера, файловых прав или PHP-конфигурации может обойти защитные механизмы приложения.

Не запускайте сайт с избыточными системными правами

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

Конкретные файловые права зависят от владельцев, модели деплоя, контейнеров, веб-сервера и CMS. Универсальные значения нельзя копировать без проверки. Важны принципы:

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

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

Пользовательские файлы не должны исполняться как PHP, CGI или другой серверный код. Каталог загрузки лучше отделить от приложения, а при возможности хранить файлы за пределами web-root или в объектном хранилище.

Для NGINX правило должно соответствовать фактическому пути проекта:

location ~* ^/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

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

Отключите просмотр каталогов

Сервер не должен выводить список файлов при отсутствии индексного документа:

autoindex off;

Для Apache применяется:

Options -Indexes

Не храните резервные копии в публичной директории

Файлы вида:

backup.zip
database.sql
site-old.tar.gz
config.php.bak
.env

не должны быть доступны по URL. Резервные копии хранятся в отдельном защищённом хранилище.

Разделяйте рабочую и тестовую среды

Тестовый сайт часто защищён хуже production, но содержит копию базы, те же пароли и действующие API-ключи.

Тестовая среда должна иметь:

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

Защитите секреты

Пароли базы, API-ключи и токены не должны храниться:

• в публичном репозитории;
• в JavaScript для браузера;
• в шаблонах;
• в журнале ошибок;
• в резервной копии без шифрования;
• в сообщениях мессенджера;
• в комментариях к коду.

Используйте переменные окружения или специализированное хранилище секретов. Доступ предоставляется только нужному процессу.

Ограничьте пользователя базы данных

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

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

Отключайте ненужные интерфейсы

Если проект не использует публичную регистрацию, удалённую публикацию, устаревший API или отдельный протокол, его следует отключить или ограничить.

Решение принимается после проверки функций проекта. Например, бездумное отключение XML-RPC в WordPress может нарушить работу интеграций, мобильных приложений или Jetpack. Безопасность любит точные решения, а не ритуальное удаление файлов по статье десятилетней давности.

Практика 4. Безопасно обрабатывайте ввод, вывод и файлы

Любые данные из формы, URL, cookie, API, базы и внешнего сервиса считаются недоверенными, пока приложение не проверило их в нужном контексте.

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

Защита от SQL-инъекций

Не собирайте SQL с помощью конкатенации пользовательских значений:

$sql = "SELECT * FROM users WHERE email = '"
    . $email
    . "'";

Используйте подготовленные выражения, query builder или корректно настроенный ORM:

$statement = $pdo->prepare(
    'SELECT id, email FROM users WHERE email = :email'
);

$statement->execute([
    'email' => $email
]);

Проверка формата email полезна, но сама по себе не защищает SQL. Защиту обеспечивает разделение кода запроса и данных.

Защита от XSS

Данные необходимо экранировать в момент вывода с учётом контекста:

• HTML-текст;
• HTML-атрибут;
• URL;
• JavaScript;
• CSS;
• JSON.

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

WYSIWYG и разрешённый HTML

Если редактору разрешено добавлять HTML, используйте allowlist допустимых тегов и атрибутов. Удаляйте:

• скрипты;
• обработчики событий;
• опасные URL-схемы;
• встроенные объекты;
• неразрешённые iframe;
• стили, способные скрывать или подменять интерфейс.

Защита от CSRF

Запрос, изменяющий состояние, должен проверять CSRF-токен или использовать другой надёжный механизм подтверждения происхождения.

Дополнительные меры:

• cookie с подходящим SameSite;
• проверка Origin;
• повторная аутентификация для опасных действий;
• отказ от изменения данных через GET;
• ограниченный срок действия токена.

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

Безопасная загрузка файлов

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

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

Практический процесс:

1. Проверить авторизацию и право загрузки.
2. Проверить размер.
3. Разрешить только необходимые расширения.
4. Проанализировать фактическое содержимое.
5. Сгенерировать новое случайное имя.
6. Не использовать исходное имя как путь.
7. Сохранить файл вне web-root или в изолированном хранилище.
8. Запретить исполнение.
9. Для рискованных форматов выполнить антивирусную проверку.
10. Отдавать файл с безопасным Content-Type и Content-Disposition.

Изображение лучше декодировать повторно

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

Ограничьте размеры и ресурсы

Проверяйте:

• размер файла;
• размер изображения в пикселях;
• число файлов;
• частоту загрузки;
• время обработки;
• объём распакованного архива;
• доступное место хранилища.

Небольшой архив может распаковаться в гигантский объём данных. Поэтому автоматическая распаковка пользовательских архивов требует отдельных лимитов.

Не используйте самодельные фильтры SQLi и XSS в NGINX

Регулярное выражение, ищущее слова union или select в URL, легко обходится, создаёт ложные срабатывания и не понимает контекст запроса.

Основная защита реализуется в приложении:

• параметризованные запросы;
• валидация;
• контекстное экранирование;
• CSRF-токены;
• контроль доступа;
• безопасная работа с файлами.

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

Практика 5. Защитите сетевой периметр, сессии и браузер

Используйте HTTPS на всём сайте

Авторизация, административная панель, формы и API должны работать только по HTTPS. HTTP-запросы перенаправляются на канонический HTTPS-адрес.

Drupal в официальной документации также рекомендует использовать HTTPS для всего сайта.

Настройте безопасные cookie

Для cookie сессии обычно необходимы:

• Secure — передача только по HTTPS;
• HttpOnly — запрет чтения из JavaScript;
• SameSite — ограничение межсайтовой отправки;
• узкая область Domain и Path;
• достаточно короткий срок жизни;
• смена идентификатора после входа и повышения привилегий.

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

Используйте HSTS осторожно

После полной проверки HTTPS можно добавить:

Strict-Transport-Security: max-age=31536000

includeSubDomains применяется только тогда, когда все поддомены действительно работают по HTTPS. Добавление домена в preload требует отдельной подготовки и не должно выполняться в качестве эксперимента.

Настройте основные защитные заголовки

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: SAMEORIGIN

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

Внедряйте Content Security Policy постепенно

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

Начните с режима наблюдения:

Content-Security-Policy-Report-Only:
    default-src 'self';
    object-src 'none';
    base-uri 'self';
    frame-ancestors 'self';

После анализа отчётов сформируйте рабочую политику. Для собственных inline-скриптов лучше использовать nonce или hash, а не глобальный 'unsafe-inline'.

Используйте WAF как дополнительный слой

WAF может:

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

При этом WAF не заменяет:

• обновление CMS;
• проверку прав;
• безопасный код;
• MFA;
• резервные копии;
• мониторинг.

Проверяйте правила WAF перед блокировкой

Новые правила лучше сначала включать в режиме регистрации или оценки аномалий. Иначе защита может заблокировать редактор, импорт, оплату или API, а первый сигнал о проблеме придёт от клиента, традиционно выбранного системой в качестве бесплатного тестировщика production.

Ограничивайте частоту запросов

Rate limiting полезен для:

• формы входа;
• восстановления пароля;
• регистрации;
• форм обратной связи;
• поиска;
• дорогих API-методов;
• загрузки файлов;
• отправки кодов подтверждения.

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

Практика 6. Создавайте резервные копии и проверяйте восстановление

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

CISA рекомендует использовать автоматическое резервное копирование критичных данных и готовить процедуры восстановления. В рекомендациях по противодействию программам-вымогателям также подчёркивается необходимость изолированных копий и проверки восстановления.

Что включать в резервную копию

• базу данных;
• загруженные пользователями файлы;
• код пользовательских модулей и шаблонов;
• конфигурацию CMS;
• конфигурацию веб-сервера;
• настройки PHP;
• задания cron;
• конфигурацию контейнеров;
• правила firewall;
• настройки почты;
• документацию восстановления.

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

Используйте несколько уровней хранения

Практичным ориентиром является схема 3–2–1:

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

Не храните единственную копию рядом с сайтом

Если архив находится на том же сервере и доступен тому же пользователю, атакующий может удалить или зашифровать его вместе с сайтом.

Защитите хранилище резервных копий

• отдельная учётная запись;
• MFA;
• минимальные права;
• шифрование;
• версионирование;
• ограничение удаления;
• журнал доступа;
• уведомление об ошибке задания;
• контроль объёма и срока хранения.

Определите RPO и RTO

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

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

Проверяйте восстановление

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

Регулярный тест должен включать:

1. создание чистой тестовой среды;
2. развёртывание кода;
3. восстановление базы;
4. восстановление файлов;
5. подключение безопасных тестовых секретов;
6. проверку входа;
7. проверку страниц, форм и загрузок;
8. фиксацию фактического времени восстановления.

Контролируйте целостность файлов

Сравнивайте код сайта с репозиторием, контрольными суммами официального дистрибутива или эталонной сборкой.

Особого внимания требуют:

• новые PHP-файлы в загрузках;
• изменённые системные файлы;
• неизвестные задания cron;
• новые административные пользователи;
• изменения конфигурации;
• обфусцированный код;
• неожиданные правила перенаправления.

Практика 7. Настройте мониторинг и план реагирования

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

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

Какие события CMS нужно регистрировать

• успешные и неуспешные входы;
• сброс пароля;
• изменение MFA;
• создание и удаление пользователей;
• изменение ролей;
• установка и удаление расширений;
• изменение системных настроек;
• загрузка файлов;
• массовый экспорт;
• изменение шаблонов;
• ошибки проверки доступа;
• срабатывания WAF;
• изменение cron;
• очистка журналов;
• смена ключей и токенов.

Не записывайте секреты в журналы

В логах не должны появляться:

• пароли;
• полные токены;
• ключи API;
• cookie сессии;
• номера банковских карт;
• содержимое конфиденциальных форм;
• персональные данные без необходимости.

Централизуйте журналы

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

Настройте уведомления

Полезные сигналы:

• серия неудачных входов;
• успешный вход администратора с нового устройства или страны;
• создание нового администратора;
• изменение системного файла вне релиза;
• появление PHP в каталоге загрузки;
• всплеск POST-запросов;
• рост 403, 404 или 500;
• исходящий трафик к неизвестному адресу;
• отключение резервного копирования;
• изменение DNS;
• окончание сертификата;
• аномальная отправка почты.

Подготовьте план реагирования

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

План должен содержать:

• контакты ответственных;
• порядок изоляции;
• способ сохранения доказательств;
• место хранения резервных копий;
• порядок ротации секретов;
• способ восстановления;
• контакты хостинга;
• правила уведомления пользователей и партнёров;
• порядок документирования;
• критерии возвращения сайта в работу.

Что делать при подозрении на взлом

1. Не удаляйте всё сразу

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

2. Ограничьте ущерб

В зависимости от ситуации:

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

3. Не доверяйте заражённой системе

Удаление одного найденного файла не означает очистку. Атакующий мог создать дополнительную учётную запись, cron, модифицировать базу и разместить несколько бэкдоров.

4. Определите точку входа

Проверьте:

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

5. Восстановите систему из доверенного источника

Безопаснее развернуть чистую среду, установить актуальные версии и восстановить проверенные данные, чем продолжать редактировать заражённый сервер.

6. Смените секреты

• пароли CMS;
• пароли базы;
• SSH-ключи;
• API-токены;
• почтовые пароли;
• ключи подписи;
• cookie-секреты;
• доступы к резервным копиям;
• учётные данные CDN и регистратора.

7. Устраните первопричину

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

8. Проведите разбор инцидента

Зафиксируйте:

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

Особенности безопасности популярных CMS

WordPress

• используйте актуальное ядро и расширения;
• удаляйте неиспользуемые плагины и темы;
• ограничивайте роли пользователей;
• включайте MFA для администраторов;
• запрещайте редактирование файлов из панели, если оно не требуется;
• защищайте каталог загрузки;
• контролируйте REST API и XML-RPC по фактической необходимости;
• используйте уникальные ключи и salts;
• проверяйте происхождение расширений.

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

Drupal

• следите за security advisories;
• обновляйте ядро и contributed modules;
• проверяйте trusted host settings;
• контролируйте файловые права;
• ограничивайте доступ к административным маршрутам;
• не используйте неподдерживаемые модули;
• проверяйте конфигурацию HTTPS;
• разделяйте публичные и приватные файлы.

Официальный раздел Drupal Security объединяет рекомендации по безопасной конфигурации, разработке и обработке генерируемых PHP-файлов.

Joomla, OpenCart и другие CMS

Общие правила остаются теми же:

• поддерживаемая версия ядра;
• расширения из надёжных источников;
• минимальные права;
• MFA;
• защита загрузок;
• отдельные учётные записи;
• резервные копии;
• мониторинг изменений.

Наличие «плагина безопасности» не освобождает от этих мер. Расширение безопасности само становится частью поверхности атаки и тоже требует обновлений.

Что не является полноценной защитой

Скрытие адреса административной панели

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

Удаление информации о версии

Скрытие версии сокращает объём подсказок для автоматического сканера, но версию часто можно определить по файлам и поведению системы. Необновлённая CMS остаётся уязвимой.

Изменение префикса таблиц

Нестандартный префикс не исправляет SQL-инъекцию. Если атакующий получил возможность выполнять произвольные запросы, названия таблиц обычно можно определить.

Установка одного защитного плагина

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

Блокировка отдельных IP

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

Сертификат HTTPS

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

Регулярный график безопасности

Чек-лист безопасности CMS

• CMS использует поддерживаемую версию.
• Критические обновления устанавливаются без неоправданной задержки.
• Неиспользуемые темы и расширения удалены.
• Происхождение компонентов проверено.
• Зависимости проверяются на известные уязвимости.
• Для каждого сотрудника создана отдельная учётная запись.
• Административные права выданы только нужным пользователям.
• MFA включена для привилегированных аккаунтов.
• Общие пароли не используются.
• Неактивные доступы удаляются.
• Форма входа защищена от автоматического перебора.
• Веб-приложение не работает от root.
• Запись разрешена только в необходимые каталоги.
• В каталоге загрузки запрещено исполнение кода.
• Резервные копии не находятся в web-root.
• Секреты не хранятся в репозитории.
• Пользователь базы имеет минимальные права.
• Неиспользуемые API и интерфейсы отключены.
• SQL-запросы параметризованы.
• Вывод экранируется по контексту.
• Изменяющие запросы защищены от CSRF.
• Загрузка файлов использует allowlist.
• Файлы переименовываются и изолируются.
• Размеры и частота загрузок ограничены.
• Весь сайт работает по HTTPS.
• Cookie имеют подходящие флаги безопасности.
• Защитные заголовки протестированы.
• CSP сначала проверяется в Report-Only.
• WAF не используется вместо исправления кода.
• Rate limiting настроен для чувствительных операций.
• Резервные копии создаются автоматически.
• Есть копия вне основного сервера.
• Хранилище резервных копий защищено MFA.
• Восстановление регулярно тестируется.
• Контролируется целостность файлов.
• Действия администраторов журналируются.
• Секреты не попадают в логи.
• Настроены уведомления об аномалиях.
• Существует план реагирования на инцидент.
• Ответственные знают порядок изоляции и восстановления.

Вывод

Безопасность CMS не сводится к установке защитного плагина или изменению адреса административной панели. Она строится из нескольких независимых уровней.

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

Четвёртый уровень находится в приложении: параметризованные запросы, экранирование, CSRF-защита и строгая обработка файлов. Пятый включает HTTPS, безопасные сессии, защитные заголовки, WAF и ограничение частоты запросов.

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

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