Back

Как защитить сайт на WordPress

Как защитить сайт на WordPress

WordPress используется более чем на 43% всех сайтов в интернете, что делает эту CMS самой атакуемой платформой в мире. Но вот что большинство владельцев сайтов понимают неправильно: само ядро системы редко является проблемой. Согласно исследованиям безопасности от Patchstack, подавляющее большинство уязвимостей WordPress исходит из плагинов и тем — а не из ядра WordPress. Это означает, что ваша защищённость практически полностью зависит от того, как вы обслуживаете и настраиваете свой сайт.

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

Ключевые выводы

  • Почти все уязвимости WordPress возникают в плагинах и темах, а не в ядре — регулярно проверяйте и удаляйте ненужные расширения.
  • Надёжная аутентификация (уникальные пароли, 2FA на основе TOTP и passkeys) — ваша самая эффективная защита от несанкционированного доступа.
  • Защита на уровне сервера, такая как отключение файлового редактора, принудительное использование HTTPS и правильные права доступа к файлам, значительно сокращают поверхность атаки.
  • Надёжные, проверенные резервные копии — ваша последняя линия обороны. Резервная копия, которую вы никогда не восстанавливали, — это резервная копия, которой вы не можете доверять.

Почему большинство сайтов на WordPress взламывают

Прежде чем переходить к решениям, полезно понять реальную поверхность атаки. Большинство успешных взломов эксплуатируют:

  • Устаревшие или заброшенные плагины и темы
  • Слабые или повторно используемые пароли
  • Неправильно настроенные права доступа к файлам
  • Хостинговые среды без защиты на уровне сервера

Ядро WordPress (в настоящее время версии 6.x) активно поддерживается специальной командой безопасности, использует bcrypt для хеширования паролей и автоматически устанавливает минорные обновления безопасности. Риск почти всегда кроется в экосистеме вокруг него.

Руководство по усилению защиты WordPress: основы

Обновляйте всё — без исключений

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

Что ещё важнее — проверяйте, что у вас установлено. Каждый неактивный плагин — это поверхность атаки. Если вы его не используете, удалите его — не просто деактивируйте.

Перед установкой любого плагина проверьте:

  • Дату последнего обновления (избегайте всего, что не обновлялось 12+ месяцев)
  • Количество активных установок
  • Присутствует ли он в репозитории плагинов WordPress.org
  • Открытые темы поддержки, упоминающие проблемы безопасности

Никогда не устанавливайте взломанные или пиратские темы и плагины. Они часто содержат бэкдоры.

Используйте надёжную аутентификацию для всех учётных записей

Ядро WordPress не включает встроенную двухфакторную аутентификацию. Вам понадобится плагин или внешний провайдер идентификации для её добавления.

Современные практики аутентификации:

  • Используйте парольную фразу (четыре или более случайных слова) или случайно сгенерированный пароль, хранящийся в менеджере паролей, таком как Bitwarden или 1Password
  • Включите 2FA на основе TOTP (приложение-аутентификатор) для всех административных учётных записей — 2FA на основе SMS лучше, чем ничего, но слабее
  • Где ваш стек это поддерживает, рассмотрите passkeys/WebAuthn для входа, устойчивого к фишингу
  • Используйте WordPress Application Passwords для REST API и сторонних интеграций вместо ваших основных учётных данных

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

Примените базовую защиту на уровне сервера

Несколько изменений конфигурации значительно уменьшают вашу поверхность атаки:

  • Отключите файловый редактор в wp-config.php, чтобы предотвратить выполнение кода в случае компрометации административной учётной записи:
    define( 'DISALLOW_FILE_EDIT', true );
  • Защитите wp-config.php, ограничив доступ через конфигурацию сервера и убедившись, что он недоступен публично
  • Установите правильные права доступа к файлам: директории на 755, файлы на 644
  • Используйте SFTP или SSH вместо обычного FTP при передаче файлов
  • Принудительно используйте HTTPS — каждый сайт на WordPress должен иметь действительный TLS-сертификат и перенаправлять HTTP на HTTPS

Добавьте веб-файрвол приложений и ограничение частоты запросов

WAF фильтрует вредоносный трафик до того, как он достигнет WordPress. Вы можете реализовать это на трёх уровнях:

  1. Уровень CDN/прокси — сервисы вроде Cloudflare предлагают WAF и защиту от DDoS с управлением ботами
  2. Уровень сервера — ModSecurity на Apache или Nginx
  3. Уровень плагина — плагины безопасности вроде Wordfence или Sucuri добавляют правила файрвола на уровне приложения и ограничение частоты входа

Ограничение попыток входа критически важно. Брутфорс-атаки на wp-login.php постоянны и автоматизированы.

Примечание об XML-RPC: Не отключайте XML-RPC огульно, не понимая ваших зависимостей. Некоторые плагины и мобильные приложения полагаются на него. Если вы его не используете, блокировка разумна — но делайте это на уровне сервера, а не с помощью хрупких правил .htaccess.

Создавайте резервные копии надёжно и тестируйте восстановление

Резервная копия, которую вы никогда не тестировали, — это не резервная копия. Используйте правило 3-2-1: три копии, два разных типа носителей, одна вне площадки. Автоматизируйте резервное копирование и регулярно проверяйте, что восстановление действительно работает.

Защитите ваш сайт на WordPress: краткий контрольный список

  • Ядро WordPress, плагины и темы актуальны
  • Неиспользуемые плагины и темы удалены
  • Все административные учётные записи используют надёжные, уникальные пароли
  • 2FA включена для каждого администратора
  • DISALLOW_FILE_EDIT установлен в wp-config.php
  • Права доступа к файлам установлены правильно (755/644)
  • HTTPS принудительно используется по всему сайту
  • WAF и ограничение частоты входа активны
  • Автоматические резервные копии выполняются регулярно, а восстановление протестировано
  • Роли пользователей следуют принципу минимальных привилегий

Заключение

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

Часто задаваемые вопросы

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

Да. Брутфорс-атаки и атаки с подстановкой учётных данных на wp-login.php постоянны и автоматизированы. Одного надёжного пароля недостаточно, потому что пароли могут быть скомпрометированы или повторно использованы. 2FA на основе TOTP через приложение-аутентификатор добавляет второй уровень, который останавливает большинство попыток несанкционированного входа.

Это зависит от вашей конфигурации. XML-RPC — это устаревший API, который некоторые плагины и мобильное приложение WordPress всё ещё используют. Если ничто на вашем сайте на него не полагается, его отключение уменьшает поверхность атаки. Блокируйте его на уровне сервера, а не через правила htaccess, которые можно обойти легче.

Частота зависит от того, как часто меняется ваш контент. Для активных сайтов ежедневные автоматические резервные копии — разумная базовая линия. Важнее частоты — регулярное тестирование восстановления. Следуйте правилу 3-2-1: три копии, два разных типа хранилища, одна хранится вне площадки.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay