Я заметил, что мой сервер 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 например)
В 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 это было легко исправить, и некоторое время спустя злоумышленник заметил, что их усилия были бесплодны, и прекратил попытки. Но всегда будут другие ...