SprytАтаки на WordPress-сайт через XML-RPC: как защититься
Сегодня случайно заметил, что сайты на сервере как-то медленно загружаются. Проверил нагрузку на ресурсы, оказалось что процессор практически на 100% загружен (и это началось еще в полдень):
В этом посте решил поделиться информацией о том, как найти и обезвредить уязвимость (интересно будет тем, кто не сильно разбирается в администрировании, но хочет защитить свой сайт).
Что это такое
XML-RPC — протокол, с помощью которого можно удаленно управлять сайтом: добавлять записи/файлы, удалять и редактировать их.
Однако, злоумышленники на сайтах созданных на WordPress используют его для своих нужд:
- организуют DDoS-атаки;
- подбирают пароль брутфорсом.
Как определить
Для профилактики, советую использовать плагины типа Wordfence Security, который и был установлен у меня.
В данном плагине есть функционал «Live Traffic«, с помощью, которого в реальном времени можно наблюдать все обращения к страницам сайта. Я заметил, что каждую секунду с различных IP идет запрос к файлу http://IP/xmlrpc.php:
Если плагин не установлен и его невозможно установить по различным причинам, то на этот случай также есть метод (через настройки httpd.conf). Но в любом случае имейте ввиду: если имеется непонятная нагрузка на сервер, то попробуйте первым делом проверить, доступен ли файл xmlrpc.php для чтения.
Способы защиты
Рассмотрим несколько вариантов, которые, в принципе, можно выполнить все вместе.
Отключение XML-RPC
Disable XML-RPC — плагин отключающий функционал XML-RPC: просто устанавливаем и активируем.
Запрет доступа к xmlrpc.php
С помощью файла .htaccess закрываем доступ к xmlrpc.php:
<Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
После чего по адресу, например, https://moneyscience.ru/xmlrpc.php будет отображаться следующее сообщение:
Выключение уведомлений и обратных ссылок
Еще не будет лишним в настройках Worpdress (раздел «Обсуждение«) снять галочки со след. пунктов:
После выполнения всех действий, нагрузка на сервер вернулась к нормальным значениям.
Сообщение Атаки на WordPress-сайт через XML-RPC: как защититься появились сначала на НаукаДенег.
Комментарии (8):
при запрете через htaccess или плагином будет все равно идти некоторая нагрузка на апач и сам wp. поэтому при большой активности может не спасти. лучше закрыться в nginx:
location /xmlrpc.php
{
return 444;
}
это при любых попытках атак сводит нагрузку к нулю. Точно так же можно закрывать и wp-admin и wp-login.php на время атак. Не путай кстати, через xmlrpc пароли не брутят, это разные атаки.
Виртуальный сервер, но, в принципе, указанные методы можно и на шареде использовать.
Спасибо за дополнение!
Вот инфа по брутфорсу через xmlrpc.php — https://github.com/1N3/Wordpress-XMLRPC-Brute-Force-Exploit, вроде бы довольно известный эксплойт для WP
Вместо установки плагинов, если файл не нужен, ещё один способ, это просто закомментировать (удалить) содержимое файла.
Коллега, ну ты чего пугаешь молодёжь? Какая нагрузка на вп может быть, если файл заблокирован на уровне апача? До вп запрос даже не дойдёт. «Нагрузка на апач» — тоже смешно, ведь апач (при всей моей любви к nginx) такой же вебсервер, и умеет эффективно запрещать доступ, к тому же не всегда перед апачем ставят nginx.
В общем, аргументация так себе, но способ предложен рабочий, особенно для тех, кто использует nginx + php-fpm.
а ты проверь, ради интереса) хотя б на 10-20 запросах в секунду. такой себе лайтовый школоло-«ддос». Посмотришь, в каком там месте и насколько эффективно апач это отпинывает. Там на одном только чтении файла htacces io будет висеть и поднимет load average в небеса. Не говоря уж о том что апач и cpu будет грузить. А о плагинах для «защиты» так и говорить смешно. Могу даже поискать контакты ддосера, где-то попадался средь клиентов) глядишь и поможет тебе в таких экспериментах
Да, провёл эксперимент, и всё оказалось несколько печальнее, чем ожидал. Я лет 8 не уже не использовал апач ни на одном проекте, и надеялся, но он за эти годы стал лучше, но увы. Как-то перешёл на более крупные проекты, и апач стал не нужен, везде nginx, где-то мощные сервера, где-то бэки с nginx за балансировщиком на HAproxy/nginx и т.д. Площадки для эксперимента с hdd не нашлось, а на ssd io мне la практически не поднял, но cpu грузится сильнее, чем с использованием nginx. В любом случае, думаю ты согласишься с двумя утверждениями из моего предыдущего коммента:
1. до вп дело не дойдёт
2. апач вполне может фильтровать доступ (но что лучше апач вообще не использовать, и что лучше сервер на ssd — тема для отдельного разговора).
Посетителям, которые придут на эту страницу из поиска при борьбе с нагрузкой рекомендую обращаться за помощью к VPSadm — он спец в своём деле и технические статьи хорошие пишет ).
Войдите или зарегистрируйтесь чтобы оставить комментарий
У тебя именно сервер или сайты на хостинге были?