Защита WordPress от взлома: что обязательно настроить

Защита WordPress от взлома: что обязательно настроить

Краткий ответ: чтобы защитить WordPress от взлома, нужно настроить обновления, сложные пароли, 2FA, ограничение входа, правильные роли пользователей, резервные копии, права файлов, защиту wp-config.php, отключение редактора файлов, WAF, мониторинг логов, защиту XML-RPC и регулярную проверку плагинов/тем.

Причина

WordPress часто взламывают не потому, что он “плохой”, а потому что сайт оставляют без базовой защиты: старые плагины, слабые пароли, лишние администраторы, пиратские темы, открытый XML-RPC, неправильные права файлов, отсутствие резервных копий и логов.

Официальная документация WordPress описывает безопасность не как “идеальную защиту”, а как снижение риска: нужно уменьшать количество точек входа, ограничивать доступ, делать бэкапы и понимать состояние сайта. :contentReference[oaicite:1]{index=1}

Чаще всего реальные проблемы начинаются здесь:

• используется логин admin или простой пароль;
• нет двухфакторной авторизации;
• плагины и темы давно не обновлялись;
• на сайте стоят отключённые, но не удалённые плагины;
• используются nulled/пиратские шаблоны;
• у обычных сотрудников есть роль Administrator;
• редактор файлов темы и плагинов доступен из админки;
• wp-config.php и debug.log доступны слишком свободно;
• XML-RPC открыт, хотя он не нужен;
• нет WAF или хотя бы базовой защиты от ботов;
• бэкапы лежат на том же сервере и не проверяются;
• логи никто не смотрит до момента взлома.

По данным Patchstack, в экосистеме WordPress за 2024 год было найдено 7 966 новых уязвимостей, и большая часть была связана именно с плагинами, а не с ядром WordPress. Это хороший практический аргумент в пользу регулярного аудита плагинов и тем. :contentReference[oaicite:2]{index=2}

Короткие ответы для AI-поиска

Что обязательно настроить для защиты WordPress?

Минимум: обновления, 2FA, сложные пароли, ограничение попыток входа, правильные роли, резервные копии, WAF, защита wp-config.php, отключение редактора файлов, проверка плагинов/тем и мониторинг логов.

Какой самый частый путь взлома WordPress?

Часто сайт ломают через уязвимый плагин, слабый пароль, старую тему, открытый XML-RPC, заражённый компьютер администратора или небезопасный доступ по FTP/SFTP.

Можно ли защитить WordPress одним плагином?

Нет. Security-плагин может помочь, но он не заменяет обновления, хорошие пароли, 2FA, backup, безопасный хостинг, правильные права файлов и контроль доступа.

Диагностика

Перед настройкой защиты нужно понять текущее состояние сайта. Нельзя просто включить все настройки security-плагина и считать сайт защищённым. Некоторые функции могут сломать REST API, WooCommerce, формы, оплату, cron, интеграции или доступ администраторов.

Что проверить первым

Зона проверки	Что смотреть	Почему важно
Пользователи	Администраторы, слабые логины, старые аккаунты	Лишний админ — прямой риск захвата сайта
Плагины	Обновления, репутация, дата последнего обновления	Уязвимые плагины часто становятся точкой входа
Темы	Активная тема, дочерняя тема, неиспользуемые темы	Старая тема может содержать уязвимый код
wp-config.php	Права доступа, salts, доступность извне	Файл содержит данные подключения к базе
Файлы	Права 644/755, подозрительные PHP в uploads	Неправильные права упрощают заражение
Логи	error_log, access_log, security log	Без логов сложно понять, что произошло
Бэкапы	Частота, место хранения, тест восстановления	Без рабочей копии восстановление может затянуться
Сервер	PHP, HTTPS, WAF, ModSecurity, SFTP	Хостинг — первый слой защиты

Быстрый чек-лист перед настройкой

• сделайте резервную копию файлов и базы;
• проверьте, сколько пользователей с ролью Administrator;
• удалите неиспользуемые темы и плагины;
• обновите WordPress, плагины и темы после backup;
• проверьте сайт на PHP-ошибки в debug.log;
• проверьте, работает ли HTTPS;
• проверьте, есть ли доступ по SFTP/SSH вместо обычного FTP;
• проверьте, не лежат ли backup-архивы внутри public_html;
• проверьте, не доступен ли debug.log по прямой ссылке;
• проверьте, нет ли неизвестных PHP-файлов в uploads.

Логи важны не только после взлома. В документации WordPress прямо указано, что логи помогают понять, что происходило на сайте: какие действия, когда и с каких IP выполнялись. :contentReference[oaicite:3]{index=3}

Решение

Защита WordPress должна строиться слоями. Один слой может не сработать, но несколько настроек вместе заметно снижают риск взлома.

1. Обновляйте WordPress, плагины и темы

Старые версии WordPress, плагинов и тем — один из главных рисков. Официальная документация WordPress подчёркивает, что старые версии становятся более открытыми для атак, потому что после публикации исправления информация об уязвимости часто становится известной. :contentReference[oaicite:4]{index=4}

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

• сделать backup;
• обновить сначала staging-копию, если сайт коммерческий;
• обновить плагины по одному или небольшими группами;
• проверить формы, оплату, корзину, личный кабинет;
• очистить кеш;
• проверить debug.log и error_log;
• удалить всё, что больше не используется.

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

2. Настройте сильные пароли и 2FA

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

Особенно важно включить 2FA для:

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

OWASP относит ошибки идентификации и аутентификации к важным рискам веб-приложений, поэтому слабые пароли и плохая логика входа — это не мелочь, а реальная зона риска. :contentReference[oaicite:5]{index=5}

3. Ограничьте попытки входа

WordPress по умолчанию не всегда жёстко ограничивает перебор паролей. Поэтому стоит настроить ограничение попыток входа, блокировку по IP, CAPTCHA/Turnstile или WAF-правила для wp-login.php.

Что важно не сломать:

• вход обычных пользователей;
• личный кабинет;
• WooCommerce login/register;
• REST API, если используется мобильное приложение;
• интеграции CRM и внешних сервисов;
• доступ администратора из разных стран, если это рабочая необходимость.

4. Уберите логин admin и лишних администраторов

Не используйте admin, administrator, webmaster, test, demo как логины администраторов. WordPress прямо указывает, что легко угадываемые имена администратора обычно атакуются первыми. :contentReference[oaicite:6]{index=6}

Проверьте роли:

• Administrator — только тем, кто реально управляет сайтом;
• Editor — для контента без доступа к плагинам и настройкам;
• Shop manager — для управления WooCommerce без полного контроля сайта;
• Author/Contributor — для авторов материалов;
• Subscriber — для обычных пользователей.

5. Отключите редактор файлов в админке

Если злоумышленник получит доступ к аккаунту администратора, встроенный редактор темы и плагинов может стать быстрым способом добавить вредоносный PHP-код. WordPress рекомендует отключать редактирование файлов через константу DISALLOW_FILE_EDIT. :contentReference[oaicite:7]{index=7}

Это не заменяет полноценную защиту, но снижает ущерб при компрометации админского аккаунта.

6. Защитите wp-config.php

wp-config.php содержит доступы к базе данных, ключи безопасности и важные настройки сайта. WordPress описывает этот файл как один из самых важных файлов установки. :contentReference[oaicite:8]{index=8}

Что настроить:

• ограничить права доступа к файлу;
• не хранить копии wp-config.php с расширением .bak, .old, .txt;
• закрыть прямой доступ через .htaccess, если сервер Apache;
• не отправлять файл по email и в мессенджеры;
• обновить salts после подозрения на взлом;
• не хранить доступы от базы в публичных репозиториях.

7. Настройте правильные права файлов

Для WordPress часто используют права 755 для папок и 644 для файлов. Официальная документация WordPress приводит команды для установки 755 на директории и 644 на файлы. :contentReference[oaicite:9]{index=9}

Не ставьте 777 на весь сайт. Это небезопасно. Если плагин требует 777, лучше разобраться с владельцем файлов, группой, PHP-FPM и настройками хостинга.

8. Удалите ненужные плагины и темы

Отключённый плагин всё равно лежит на сервере. Если в его файлах есть уязвимость или вредоносный код, он может оставаться риском. WordPress рекомендует обновлять плагины и удалять те, которые не используются. :contentReference[oaicite:10]{index=10}

Оставьте:

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

9. Не используйте nulled-плагины и пиратские темы

Пиратские темы и плагины часто содержат скрытые вставки, backdoor, SEO-спам, редиректы или загрузчики вредоносного кода. Даже если сайт работает нормально, заражение может проявиться позже.

Безопаснее покупать плагины у официальных разработчиков или использовать репозиторий WordPress.org. WordPress также рекомендует брать темы и плагины из доверенных источников. :contentReference[oaicite:11]{index=11}

10. Настройте WAF

WAF фильтрует подозрительные запросы до того, как они попадут в WordPress. Это помогает против части атак на wp-login.php, xmlrpc.php, SQL-инъекций, XSS, сканеров уязвимостей и вредных ботов.

WordPress описывает два подхода: firewall-плагины на уровне WordPress и внешние WAF/reverse proxy, которые фильтруют трафик до попадания на сервер. :contentReference[oaicite:12]{index=12}

Практически можно использовать:

• серверный ModSecurity;
• Cloudflare WAF;
• security-плагин с firewall;
• ограничение wp-login.php по IP, если администраторы работают с фиксированных адресов;
• rate limiting для login, XML-RPC и форм.

11. Проверьте XML-RPC

XML-RPC нужен не всем сайтам. Его могут использовать мобильные приложения, Jetpack, внешние публикации и некоторые интеграции. Если он не нужен, его лучше закрыть или ограничить.

Перед отключением проверьте, не используют ли сайт:

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

12. Настройте резервные копии

Бэкап — это не защита от взлома, а защита от потери сайта после взлома. WordPress рекомендует регулярно делать копии файлов и базы данных, а также хранить их в доверенном месте. :contentReference[oaicite:13]{index=13}

Хорошая схема backup:

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

13. Настройте HTTPS и безопасность админки

Админка и логин должны работать по HTTPS, чтобы пароли и cookies не передавались в открытом виде. В wp-config.php для этого есть FORCE_SSL_ADMIN, который защищает вход и административную область. :contentReference[oaicite:14]{index=14}

Также стоит проверить:

• корректный SSL-сертификат;
• редирект с HTTP на HTTPS;
• нет ли смешанного контента;
• правильно ли указан siteurl/home;
• не ломаются ли callback URL у оплат и интеграций.

14. Настройте мониторинг изменений файлов

После заражения часто появляются новые PHP-файлы в uploads, изменяется .htaccess, добавляются неизвестные администраторы, появляются странные cron-задачи и скрытые вставки в теме.

Мониторить нужно:

• новые PHP-файлы в wp-content/uploads;
• изменения в wp-config.php;
• изменения в .htaccess;
• новые админские аккаунты;
• странные задания cron;
• изменения в functions.php;
• файлы с eval, base64_decode, gzinflate, str_rot13;
• редиректы на неизвестные домены.

Код

Важно: код ниже влияет на доступ к админке, работу плагинов, XML-RPC, REST API, wp-config.php, debug.log и серверные правила. Перед изменениями сделайте backup файлов и базы. Проверяйте сайт после каждой правки, особенно если есть WooCommerce, формы, личный кабинет, CRM, Jetpack или внешние интеграции.

Отключить редактор файлов темы и плагинов

Куда вставлять: wp-config.php, выше строки “That’s all, stop editing”.

define( 'DISALLOW_FILE_EDIT', true );

Включить HTTPS для админки

Куда вставлять: wp-config.php. Используйте только если SSL-сертификат уже установлен и HTTPS работает корректно.

define( 'FORCE_SSL_ADMIN', true );

Закрыть доступ к wp-config.php через .htaccess

Куда вставлять: .htaccess в корне сайта, ближе к началу файла. Работает для Apache/LiteSpeed. Перед изменением сохраните копию .htaccess.

<Files "wp-config.php">
    Require all denied
</Files>

Закрыть доступ к debug.log через .htaccess

Куда вставлять: .htaccess в корне сайта. Это особенно важно, если debug.log находится в wp-content и может открываться по прямой ссылке.

<Files "debug.log">
    Require all denied
</Files>

Отключить XML-RPC через .htaccess

Куда вставлять: .htaccess в корне сайта. Не используйте, если вам нужен Jetpack, мобильное приложение WordPress или внешние публикации через XML-RPC.

<Files "xmlrpc.php">
    Require all denied
</Files>

Запретить выполнение PHP в uploads

Куда вставлять: создайте файл .htaccess внутри папки /wp-content/uploads/. Работает для Apache/LiteSpeed. На Nginx это настраивается в конфиге сервера.

<FilesMatch ".php$">
    Require all denied
</FilesMatch>

Базовые security headers через .htaccess

Куда вставлять: .htaccess. Перед добавлением проверьте сайт, потому что строгие заголовки могут повлиять на iframe, внешние скрипты и интеграции.

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

Проверить активных администраторов через WP-CLI

Куда выполнять: SSH в корне сайта.

wp user list --role=administrator

Проверить активные плагины через WP-CLI

Куда выполнять: SSH в корне сайта.

wp plugin list --status=active

Проверить установленные темы через WP-CLI

Куда выполнять: SSH в корне сайта.

wp theme list

Найти PHP-файлы в uploads через SSH

Куда выполнять: SSH в корне сайта. Команда только показывает файлы, не удаляет их.

find wp-content/uploads -type f -name "*.php"

Найти подозрительные вставки в файлах

Куда выполнять: SSH в корне сайта. Это только первичный поиск, не окончательный вывод о заражении.

grep -R "base64_decode|eval(|gzinflate|str_rot13" wp-content --include="*.php"

Результат

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

Проверьте после настройки:

• работает ли вход в админку;
• работает ли восстановление пароля;
• работают ли формы;
• работает ли WooCommerce checkout, если магазин есть;
• работает ли REST API, если он нужен;
• не заблокирован ли нужный XML-RPC;
• не сломались ли iframe, карты, видео и внешние виджеты;
• создаются ли бэкапы;
• открываются ли логи только через сервер, а не по прямой ссылке;
• нет ли ошибок 403/500 после правил .htaccess.

Если после настройки защиты сайт стал медленнее, проверьте WAF, security-плагин, сканер файлов и нагрузку на сервер. Для общей производительности можно использовать отдельное руководство как ускорить сайт на WordPress.

Дополнительные способы

Ограничить доступ к wp-admin по IP

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

Использовать SFTP вместо FTP

Обычный FTP передаёт данные менее безопасно. Лучше использовать SFTP или SSH-доступ, если хостинг это поддерживает.

Проверить компьютер администратора

Если на компьютере администратора есть вредоносное ПО, даже защищённый WordPress может быть скомпрометирован через украденные пароли, cookies или FTP-доступ. WordPress прямо указывает, что защита сайта не поможет, если компьютер администратора заражён keylogger или malware. :contentReference[oaicite:15]{index=15}

Настроить отдельные доступы для разработчиков

Не давайте всем один общий admin-аккаунт. Для каждого разработчика, контент-менеджера и подрядчика должен быть отдельный пользователь с минимально нужной ролью. После завершения работ доступ нужно отключать.

Проверить WooCommerce отдельно

Интернет-магазин хранит заказы, личные данные клиентов, адреса доставки, купоны, интеграции оплат и доставки. Для WooCommerce особенно важны 2FA, защита checkout, обновления, безопасные плагины оплаты и корректный кеш.

Ограничить загрузку файлов

Если пользователи могут загружать файлы через формы, личный кабинет или frontend-публикации, проверьте типы файлов, размер, обработку MIME-type и запрет выполнения PHP в uploads.

Проверить резервные копии восстановлением

Backup считается рабочим только после тестового восстановления. Архив, который невозможно распаковать, база с ошибками или backup без wp-content/uploads могут не спасти сайт.

Частые ошибки

Ошибка 1. Считать security-плагин полной защитой

Плагин — только один слой. Он не заменяет обновления, хорошие пароли, 2FA, backup, безопасный хостинг и контроль прав пользователей.

Ошибка 2. Не удалять старые плагины

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

Ошибка 3. Давать всем роль Administrator

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

Ошибка 4. Хранить бэкапы внутри public_html

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

Ошибка 5. Отключать XML-RPC без проверки

Если сайт использует Jetpack, мобильное приложение или внешнюю публикацию, отключение XML-RPC может сломать нужную функцию.

Ошибка 6. Ставить права 777

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

Ошибка 7. Не смотреть логи

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

Диагностика проблем

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

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

Что делать: удалить неизвестного пользователя после backup, сменить пароли, обновить salts, проверить логи входа, плагины, темы и файлы.

Проблема: сайт редиректит на чужой домен

Возможная причина: заражённый .htaccess, вредоносный JS, вставка в теме, заражённый плагин, подмена в базе.

Что делать: проверить .htaccess, functions.php, header.php, wp_options, виджеты, плагины и файлы uploads.

Проблема: в uploads появились PHP-файлы

Возможная причина: уязвимая форма загрузки, плагин, который не проверяет MIME-type, backdoor.

Что делать: изолировать сайт, сделать копию, проверить файлы, запретить выполнение PHP в uploads, найти точку загрузки.

Проблема: сайт стал рассылать спам

Возможная причина: заражение, слабая форма, открытый SMTP, вредоносный cron, взломанный аккаунт.

Что делать: проверить email-логи, cron, плагины форм, неизвестных пользователей, вредоносные файлы и лимиты отправки.

Проблема: после настройки защиты не работает форма

Возможная причина: WAF, CAPTCHA, блокировка REST API, security headers, кеш nonce.

Что делать: проверить консоль браузера, Network, error_log, исключения WAF и настройки формы.

Проблема: после защиты не работает WooCommerce checkout

Возможная причина: блокировка AJAX, REST API, платежного callback, cookies, сессий или внешнего домена оплаты.

Что делать: проверить логи WooCommerce, Network, security-плагин, WAF, callback URL и кеш.

Проблема: сайт начал показывать ошибку 500 после .htaccess

Возможная причина: правило не поддерживается сервером, ошибка синтаксиса, конфликт с кешем или редиректами.

Что делать: вернуть старый .htaccess, добавлять правила по одному, проверить error_log. Если нужна отдельная диагностика, смотрите материал ошибка 500 WordPress.

FAQ

Как защитить WordPress от взлома быстро?

Обновите WordPress, плагины и темы, включите 2FA, удалите лишние плагины, настройте backup, ограничьте попытки входа, отключите редактор файлов, закройте wp-config.php и проверьте логи.

Нужен ли security-плагин для WordPress?

Да, часто он полезен: firewall, 2FA, логирование, сканирование файлов, ограничение входа. Но он не заменяет правильные обновления, роли пользователей, backup и безопасный сервер.

Нужно ли менять адрес wp-login.php?

Можно, но это не основная защита. Смена URL может снизить шум от ботов, но не заменяет 2FA, сильные пароли, rate limiting и WAF.

Нужно ли отключать XML-RPC?

Если XML-RPC не используется — лучше закрыть или ограничить. Если сайт использует Jetpack, мобильное приложение или внешние публикации, сначала проверьте зависимости.

Как понять, что WordPress уже взломан?

Признаки: неизвестные администраторы, редиректы, спам, странные PHP-файлы, изменённый .htaccess, падение трафика, предупреждения браузера, письма от хостинга, неизвестные cron-задачи.

Какие права файлов ставить?

Часто используют 755 для папок и 644 для файлов. Для wp-config.php могут использовать более строгие права, если это поддерживает сервер. Не ставьте 777 на весь сайт.

Можно ли полностью защитить WordPress?

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

Как часто делать backup?

Зависит от сайта. Для блога может хватить ежедневной или недельной копии. Для магазина, LMS или сайта с заявками лучше делать копии чаще и обязательно хранить их вне основного сервера.

Что важнее: WAF или 2FA?

Это разные слои. 2FA защищает вход пользователей, WAF фильтрует вредные запросы до WordPress. Лучше использовать оба.

Что делать, если сайт уже взломали?

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

Вывод

Защита WordPress от взлома начинается с базовых вещей: обновления, 2FA, сильные пароли, минимум администраторов, удаление лишних плагинов, безопасные права файлов, закрытый wp-config.php, рабочие бэкапы и мониторинг логов.

Дальше добавляются более строгие меры: WAF, ограничение входа, контроль XML-RPC, запрет выполнения PHP в uploads, security headers и проверка изменений файлов.

Главная цель — не “спрятать WordPress”, а снизить риск, быстро увидеть подозрительную активность и иметь рабочий план восстановления сайта.