Защита сайта на WordPress от взлома: аудит плагинов, REST API и XML-RPC
Практическое руководство по харднингу WordPress. Как отключить XML-RPC, закрыть перебор пользователей через REST API, защитить wp-config.php и debug.log, а также настроить безопасный Nginx.
Работая на более чем 40% всех сайтов в мире, WordPress остается главной мишенью для автоматизированных ботнетов и киберпреступников. Тысячи вредоносных сканеров ежеминутно прощупывают серверы в поисках уязвимых устаревших плагинов, открытых точек перебора логинов администраторов и забытых резервных копий конфигурационных файлов.
Большинство веб-мастеров пытаются решить проблему установкой тяжелых защитных плагинов, которые перегружают хостинг и замедляют загрузку страниц. Однако максимальный уровень безопасности достигается не плагинами, а грамотной изоляцией уязвимых векторов на уровне конфигурации Nginx, прав файловой системы и отключения устаревших протоколов вроде XML-RPC.
1. Отключение протокола XML-RPC (xmlrpc.php) от брутфорса и DDoS
Файл xmlrpc.php исторически создавался для удаленного управления сайтом через мобильные приложения. Сегодня он используется злоумышленниками как основной инструмент подбора паролей через метод system.multicall (позволяющий проверить тысячи комбинаций паролей за один HTTP-запрос) и для амплификации DDoS-атак. Если вы не используете интеграцию с Jetpack, заблокируйте его на уровне веб-сервера.
# Блокировка XML-RPC на уровне Nginx с немедленным сбросом соединения
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 403;
}
2. Защита от перебора логинов авторов через WordPress REST API
По умолчанию обращение к /wp-json/wp/v2/users на чистой установке WordPress отдает полный список всех зарегистрированных пользователей и авторов сайта в формате JSON вместе с их ID и логинами. Злоумышленникам остается только подобрать пароль к уже известному логину администратора.
// Добавьте в functions.php вашей темы или в отдельный mu-plugin:
add_filter('rest_endpoints', function($endpoints) {
if (isset($endpoints['/wp/v2/users'])) {
if (!current_user_can('list_users')) {
unset($endpoints['/wp/v2/users']);
}
}
if (isset($endpoints['/wp/v2/users/(?P<id>[\\d]+)'])) {
if (!current_user_can('list_users')) {
unset($endpoints['/wp/v2/users/(?P<id>[\\d]+)']);
}
}
return $endpoints;
});
3. Защита критических файлов wp-config.php и debug.log
В процессе отладки сайтов разработчики часто включают WP_DEBUG_LOG в wp-config.php. Если создаваемый файл /wp-content/debug.log доступен для прямого скачивания через браузер, злоумышленники извлекают из него дампы ошибок с паролями к базе данных и секретными токенами интеграций.
# Запрет прямого чтения служебных файлов WordPress
location ~* /(wp-config\.php|readme\.html|license\.txt|debug\.log) {
deny all;
return 404;
}
# Запрет вызова скрипта первичной инсталляции после запуска сайта
location = /wp-admin/install.php {
deny all;
return 404;
}
4. Запрет выполнения PHP-скриптов в директории загрузок /wp-content/uploads/
Папка загрузок должна быть доступна на запись для работы медиабиблиотеки. Если уязвимый плагин позволяет загрузить произвольный файл, злоумышленник загрузит PHP-шелл прямо в /wp-content/uploads/. Настройте веб-сервер так, чтобы он категорически отказывался исполнять любые интерпретируемые скрипты из этой папки.
# Запрет исполнения любых исполняемых скриптов в папке загрузок
location ~* /wp-content/uploads/.*\.php$ {
deny all;
return 404;
}
5. Безопасность цепочки поставок плагинов и запрет редактирования файлов
Более 90% брешей в WordPress связаны не с ядром, а со сторонними плагинами и темами. Удаляйте неиспользуемые плагины, обновляйте активные и отключите встроенный редактор кода в админ-панели строкой define('DISALLOW_FILE_EDIT', true); в wp-config.php — это не позволит хакеру изменить файлы даже в случае компрометации пароля администратора.
Чек-лист безопасности для разработчика
- ✓ Заблокировать публичный доступ к /xmlrpc.php в Nginx
- ✓ Закрыть доступ к эндпоинту /wp-json/wp/v2/users для неавторизованных гостей
- ✓ Запретить выполнение PHP-скриптов внутри директории /wp-content/uploads/
- ✓ Заблокировать прямое чтение wp-config.php, debug.log и readme.html
- ✓ Отключить редактирование файлов из админки (DISALLOW_FILE_EDIT = true)
- ✓ Запустить регулярный аудит безопасности сайта в Site Check
Резюме и ключевые выводы аудитора безопасности
При запуске веб-сервисов и приложений на базе современных фреймворков (Next.js, Astro, React, Supabase) безопасность периметра не должна быть второстепенным этапом. Более 85% утечек конфиденциальных данных и взломов баз данных происходят не из-за изощрённых уязвимостей нулевого дня (0-day), а по причине тривиальных ошибок конфигурации: забытых тестовых эндпоинтов, открытых файлов окружения, некорректных правил CORS и отсутствия строгих политик разграничения доступа (RLS).
Регулярный превентивный аудит внешнего контура с помощью Site Check позволяет обнаружить опасные сигнатуры за считанные секунды и закрыть векторы атак до того, как они попадут в поле зрения автоматизированных ботнетов.