Как заблокировать POST-запросы xmlrpc.php
Я заметил, что мой сервер Apache сегодня не работает, и, заходя на панель управления хостингом, я вижу скачок в пропускной способности диска и IOPS. В то же время мой журнал полон этих строк:
108.162.215.47 - - [03/Feb/2019:06:25:01 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"
108.162.215.47 - - [03/Feb/2019:06:25:02 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"
108.162.215.47 - - [03/Feb/2019:06:25:04 +0100] "POST /xmlrpc.php HTTP/1.1" 403 426 "-" "python-requests/2.21.0"
172.69.33.204 - - [03/Feb/2019:06:25:04 +0100] "POST /xmlrpc.php HTTP/1.1" 403 2471 "-" "python-requests/2.21.0"
xmlrpc.php - это файл, используемый Wordpress для связи с удаленным сервером. Известно, что он является источником многих атак, и часто рекомендуется блокировать доступ к нему (см., Например, https://www.hostinger.com/tutorials/xmlrpc-wordpress).
- Итак, я прав, что эти xmlrpc-атаки могут быть причиной скачка пропускной способности диска, даже если я не вижу скачка ЦП одновременно?
- Журнал показывает, что эти запросы были заблокированы (403), так почему мой сервер apache вышел из строя?
- Что я должен сделать, чтобы это не повторилось в будущем? У меня установлен fail2ban на моем сервере, но, возможно, мне нужна специальная конфигурация для xmlrpc (я все еще новичок в отношении администрирования сервера)
1 ответ
В WordPress, xmlrpc.php API-интерфейс, который может использоваться, например, мобильным приложением WordPress для связи с веб-сайтом и выполнения определенных действий. Тем не менее, его плохой дизайн также позволяет злоумышленнику эффективный способ попытки перебора пароля администратора WordPress, а если ваш сайт допускает комментарии и / или пингбэки, способ добавления спама с комментариями / пингбэками на ваш сайт.
Если вы не используете мобильное приложение WordPress или функцию pingback, возможно, вы захотите полностью отключить xmlrpc.php,
Однако простого отключения его на уровне WordPress может быть недостаточно: так как спамер / злоумышленник обычно генерирует много запросов, передача их по стеку через Apache и интерпретатор PHP к реальному коду WordPress может потребовать значительной нагрузки даже если WordPress просто отклоняет запрос. В результате вы захотите выполнить отклонение как можно раньше.
Отказ от него в Apache - это простая операция сопоставления строк в скомпилированном, высоко оптимизированном C-коде, которая может быть очень эффективной. Для отклонения на уровне WordPress требуется интерпретатор PHP и, возможно, также база данных WordPress, что делает операцию отклонения намного более дорогостоящей с точки зрения необходимой мощности процессора.
В конфигурации Apache 2.2 (или 2.4 с включенным устаревшим модулем синтаксиса контроля доступа) вы можете сделать это, добавив такой блок к <VirtualHost> блок вашего сайта:
<files xmlrpc.php>
order allow,deny
deny from all
</files>
Используя новый синтаксис контроля доступа Apache 2.4, он будет:
<files xmlrpc.php>
Require all denied
</files>
С помощью fail2ban блокировать злоумышленников, отправляющих такие запросы на уровне ядра (используя iptables контролируется fail2ban) было бы еще более эффективным, но поскольку большинство таких злоумышленников имеют в своем распоряжении несколько IP-адресов, вы, вероятно, увидите, что источник атаки начинает перемещаться с одного IP-адреса на другой, пытаясь получить несколько попыток, прежде чем каждый новый IP-адрес будет заблокирован. Блок на уровне Apache гарантирует, что все запросы на xmlrpc.php будет заблокирован
Наблюдаемый вами скачок пропускной способности диска может сводиться к записи всех сообщений журнала для всех этих отклонений.
Однажды у меня возникла похожая проблема, а затем жалоба клиента была связана с тем, что Apache ограничивал трафик: из-за всех попыток спаммера законный трафик отодвигался в сторону. Когда ограничения ресурсов Apache были скорректированы, тогда база данных WordPress начала падать из-за огромного количества запросов (она находилась в довольно слабой системе). Блокировка исходного IP-адреса привела к тому, что источник перешел на другой IP-адрес и через несколько часов возобновил наводнение. блокировка xmlrpc.php на уровне Apache это было легко исправить, и спустя некоторое время злоумышленник заметил, что их усилия оказались бесплодными, и прекратил попытки. Но всегда будут другие...