Безопасность WordPress редко ломается из-за одной настройки. Обычно риск появляется из сочетания факторов: устаревший плагин, лишние права у пользователя, слабая защита учётной записи, открытый доступ к служебным файлам и резервная копия, которую никто не проверял на восстановление.
Поэтому защита рабочего сайта — это не установка одного security-плагина, а система. Она должна уменьшать вероятность инцидента, ограничивать последствия и позволять быстро восстановить сайт, если проблема всё же произошла.
Главный принцип: несколько независимых уровней защиты
WordPress рекомендует рассматривать безопасность шире самой CMS: важны сервер, файловые права, пароли, обновления, резервные копии, плагины, журналы и контроль доступа. Если один уровень окажется слабым, остальные должны не дать проблеме сразу превратиться в полную потерю сайта.
Практически это означает, что нельзя считать сайт защищённым только потому, что в админке установлен firewall-плагин. Он может быть полезен, но не заменяет обновления, безопасный хостинг и корректные права.
1. Обновляйте ядро, плагины и темы осознанно
Официальное руководство WordPress по hardening отдельно подчёркивает необходимость поддерживать WordPress в актуальном состоянии. То же относится к активно используемым плагинам и темам.
На простом сайте часть обновлений можно автоматизировать. На WooCommerce, сайте с кастомным кодом или важными интеграциями разумнее сочетать обновления с резервной копией и проверкой ключевых сценариев: формы, checkout, личный кабинет, API и административные страницы.
Если сайт давно не обновлялся, не стоит нажимать «обновить всё» без подготовки. Сначала нужно понять версию PHP, совместимость темы и критичных плагинов, сделать копию и определить порядок изменений.
2. Уберите лишние плагины и темы
Неактивный код тоже требует внимания. Если расширение больше не используется, его лучше удалить, а не хранить годами «на всякий случай». Чем меньше компонентов установлено, тем проще контролировать обновления, совместимость и происхождение кода.
- удаляйте ненужные плагины;
- оставляйте только реально используемые темы;
- не устанавливайте сборки из неизвестных источников;
- проверяйте, поддерживается ли расширение разработчиком;
- не держите несколько плагинов с одинаковой функцией без причины.
3. Разделяйте учётные записи и права
Администратор нужен далеко не каждому пользователю. Редактору контента обычно не требуется доступ к плагинам и настройкам, а технической интеграции может быть достаточно отдельного пользователя с минимально нужными capabilities.
Хорошая практика — отдельные учётные записи для людей, а не общий логин «admin» на всю команду. Тогда проще отключить доступ конкретному человеку и понять, кто выполнял изменения.
Пароли и двухфакторная защита
Для административных учётных записей используйте уникальные длинные пароли и, где это возможно, двухфакторную аутентификацию. Пароль от WordPress не должен совпадать с паролем почты, хостинга или других сервисов.
4. Защитите wp-config.php и запретите ненужное редактирование файлов
wp-config.php содержит параметры подключения к базе и другие чувствительные настройки. Его нельзя публиковать в репозиториях, отправлять в открытые чаты или оставлять доступным через неправильно настроенный веб-сервер.
На production-сайте часто имеет смысл отключить встроенный редактор файлов темы и плагинов, если он не нужен рабочему процессу. Это не заменяет остальные меры, но уменьшает количество способов менять PHP-код через админку.
define( 'DISALLOW_FILE_EDIT', true );Перед добавлением констант нужно учитывать текущую конфигурацию проекта и не дублировать уже существующие определения.
5. Проверьте права файлов и владельца
Слишком широкие права вроде постоянного 777 на каталогах не являются нормальным способом «починить загрузку». Права зависят от схемы пользователя веб-сервера и PHP, но общий принцип простой: процесс должен иметь только тот доступ, который действительно нужен.
Особенно внимательно стоит относиться к wp-config.php, каталогам загрузок, временным директориям и кастомным скриптам.
6. Резервная копия — часть безопасности, а не архив на всякий случай
Бэкап не предотвращает атаку, но резко меняет последствия инцидента. Полноценная копия WordPress обычно включает и файлы, и базу данных. Хранить единственную копию только на том же сервере рискованно: при проблеме с сервером можно потерять и сайт, и бэкап.
Важно не только создавать копии, но и периодически проверять восстановление. Подробный процесс разобран в отдельной статье про резервное копирование WordPress.
7. Защита форм не равна защите админки
Антибот-механизмы вроде Cloudflare Turnstile полезны против автоматического спама в формах, но они решают другую задачу. Turnstile не заменяет проверку прав пользователя, обновления, безопасные пароли или серверные ограничения.
Если на сайте есть публичные формы, можно отдельно настроить серверную антибот-проверку. Практический пример есть в материале Cloudflare Turnstile для WordPress.
8. Логи и мониторинг помогают увидеть проблему раньше
Если сайт начал отдавать 500, резко изменились файлы или появились неизвестные администраторы, без журналов расследование превращается в угадывание. Полезны серверные access/error logs, логи PHP, история изменений в хостинге и, для сложных проектов, отдельный аудит важных действий.
Логи тоже нельзя хранить бесконтрольно: в них не должны попадать пароли, API-токены, cookies и другие секреты.
9. Что делать после подозрения на взлом
Не стоит сразу удалять случайные файлы на production без фиксации состояния. Сначала ограничьте доступ, сохраните необходимые логи и копию текущего состояния для анализа, затем определите источник изменений.
- сменить скомпрометированные пароли и секреты;
- проверить пользователей WordPress и серверные учётные записи;
- сверить ядро с официальными файлами;
- проверить плагины, темы и mu-plugins;
- найти неизвестные PHP-файлы и модифицированные точки входа;
- обновить или заменить уязвимый компонент;
- восстановить чистую версию данных при необходимости;
- проверить сайт после очистки и только затем возвращать обычный доступ.
Что можно проверить через WP-CLI
Для ядра WordPress можно использовать проверку контрольных сумм официального дистрибутива. Это не универсальный антивирус, но полезный способ обнаружить изменённые core-файлы.
wp core verify-checksumsДля плагинов возможности зависят от источника установки и наличия официальных checksum. Любой автоматический результат нужно интерпретировать в контексте конкретного сайта.
Минимальный практический чек-лист
- WordPress, тема и плагины поддерживаются и обновляются;
- лишние плагины и темы удалены;
- у каждого человека отдельная учётная запись;
- администраторские права выданы только тем, кому они нужны;
- пароли уникальные, для админов включена дополнительная защита;
wp-config.phpне доступен публично и не хранится в открытом Git;- права файлов соответствуют серверной схеме;
- есть автоматические резервные копии файлов и базы;
- хотя бы одна копия хранится отдельно от production;
- есть доступ к логам и понятный план восстановления.
Когда нужен технический аудит
Аудит особенно полезен, если сайт давно не обслуживался, использует много плагинов, пережил взлом, содержит WooCommerce или зависит от API-интеграций. В таких проектах важно проверить не только админку, но и PHP, cron, права файлов, сервер, секреты и точки входа.
Для постоянного контроля можно использовать техническую поддержку WordPress. Если нужна разовая диагностика или исправление конкретной проблемы, подойдёт доработка WordPress.
Частые вопросы
Нужен ли security-плагин каждому WordPress-сайту?
Не обязательно один и тот же набор инструментов подходит всем. Плагин может добавить firewall, 2FA, сканирование или журналирование, но он не заменяет обновления, правильные роли, серверную безопасность и резервные копии.
Можно ли полностью защитить WordPress от взлома?
Абсолютной гарантии нет. Цель практической безопасности — снизить вероятность инцидента, ограничить возможный ущерб и иметь рабочий сценарий восстановления.
Нужно ли скрывать адрес wp-admin?
Смена URL может уменьшить часть автоматического шума, но не является основной защитой. Гораздо важнее сильная аутентификация, обновления, минимальные права и контроль попыток входа.
Автообновления безопаснее ручных?
Зависит от проекта. Для небольших сайтов автоматизация помогает быстрее получать исправления. На сложном production полезно иметь резервную копию, staging и регрессионную проверку критичных функций.
Что важнее: бэкап или firewall?
Они решают разные задачи. Firewall уменьшает часть атакующего трафика, а бэкап нужен для восстановления после ошибок, повреждения данных или успешного инцидента. Нужна не замена одного другим, а система.
Вывод
Безопасный WordPress — это сайт, где обновления контролируются, права минимальны, секреты не гуляют по репозиториям, резервные копии реально восстанавливаются, а при проблеме есть логи и понятный порядок действий.
Если нужно проверить текущий WordPress-сайт по этим пунктам и составить план исправлений, можно отправить URL и описание проекта через контакты A.S Groups.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.