Полное руководство по XMLRPC для WordPress (+ как его отключить)

Безопасность веб-сайта — сложная задача, которую нужно решить правильно . В частности, с проблемами безопасности, связанными с XML-RPC, которые обычно используются при атаках на сайты WordPress. В Интернете есть много информации, предлагающей всевозможные решения, но какие из них правильные? В этой статье мы объясним, как, какие существуют решения и какое решение на самом деле является лучшим. Давайте погрузимся!

XMLRPC старше самого WordPress. Эта система была введена в WordPress для решения проблемы медленного интернет-соединения, помогая пользователям писать новые сообщения в автономном режиме, а затем загружать их на сервер. Возможность удаленного подключения WordPress к другим приложениям была возможна только с помощью файла xmlrpc.php.

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

Хотя у WordPress теперь есть собственный REST API, файл xmlrpc.php по-прежнему присутствует внутри ядра и включен по умолчанию, подвергая сайт WordPress различным кибератакам. В этой статье мы узнаем, как использовать этот файл, связанные с ним уязвимости и как с этим справиться, не подвергая риску безопасность вашего сайта.

Что такое файл xmlrpc.php?

В своей простейшей форме XML-RPC (удаленный вызов процедур) был создан для межплатформенного взаимодействия. Этот протокол используется для вызовов процедур с использованием HTTP в качестве транспорта и XML в качестве кодировщика. Клиент выполняет эти вызовы, отправляя HTTP-запрос на сервер и получая в ответ HTTP-ответ. XML-RPC вызывает функции через HTTP-запрос, а затем эти функции выполняют некоторые действия и отправляют взамен жестко закодированные ответы.

Давайте сравним это с вызовом REST API, чтобы полностью понять концепцию.

REST использует параметры URL для идентификации ресурсов, в то время как RPC использует параметры запроса для предоставления в качестве аргументов функции.

WordPress использовал XMLRPC, чтобы пользователи могли удаленно взаимодействовать со своим сайтом. Он по-прежнему использует его для питания своего мобильного приложения и поддержки таких плагинов, как JetPack, WooCommerce и т. д. Использование файла xmlrpc.php имеет свои недостатки, но является ли его полное отключение единственным жизнеспособным решением? Чтобы ответить на этот вопрос, нам сначала нужно взглянуть на уязвимости, связанные с этим, и какие есть решения, чтобы их избежать.

Как злобные хакеры могут быть с файлом xmlrpc.php?

Используя XMLRPC, хакеры используют удаленные вызовы процедур (RPC) и вызывают функции для получения нужных данных. На большинстве сайтов WordPress файл xmlrpc.php легко отследить, и, просто отправив произвольные XML-данные, хакеры контролируют сайт, чтобы запустить код, который они подготовили для выполнения определенного типа атаки.

Чтобы понять, как компрометируется WordPress XMLRPC, давайте рассмотрим самые популярные кибератаки, связанные с ним.

Брутфорс-атака

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

Другие используют надежный пароль, а также имеют механизмы безопасности, такие как reCaptcha и автоматическую блокировку IP-адресов, которая эффективна против атак методом грубой силы, но если хакер решит использовать XMLRPC; ей даже не нужен доступ к администратору WordPress.

Очень распространенный инструмент от Kali Linux, WPSCAN, используется для перечисления всех имен пользователей, и как только это будет сделано, хакеры подберут пароль, используя файл xmlrpc.php , отправив следующий HTTP-запрос на сайт-жертву.

POST /xmlrpc.php HTTP/1.1
User-Agent: Fiddler
Host: www.example.com
Content-Length: 164

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

В приведенном выше примере хакер может отправить тысячи вариантов, пока не получит правильный пароль.

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

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/7.1.21
Cache-Control: private, must-revalidate
Expires: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>403</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Incorrect username or password.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>

Ответ вернул код HTTP 200 и сообщение о том, что предоставленные имя пользователя и пароль неверны. Проходя через канал XMLRPC, хакеру не нужно беспокоиться о reCaptchas или плагинах ограничения попыток входа. Она может продолжать запускать варианты до тех пор, пока не будет получен правильный пароль.

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

DDoS-атака

Распределенный отказ в обслуживании (DDoS) — одна из самых смертоносных кибератак, которая может парализовать сервер, обрушивая на него сотни и тысячи одновременных запросов. Хакеры используют функцию pingback WordPress вместе с файлом xmlrpc.php для выполнения таких атак.

В идеале хакер нацеливается на конечную точку или страницу, которая может быть затронута несколько раз и требует больше времени для ответа. Таким образом, одно попадание может оказать максимальное влияние на ресурсы сервера, и в нашем случае XMLRPC хорошо помогает хакеру в раскрытии таких конечных точек.

Несколько уже скомпрометированных сайтов WordPress используются для выполнения метода pingback.ping для нацеливания на одну жертву. Подавляющие HTTP-запросы GET и POST блокируют обычный трафик и в конечном итоге приводят к сбою сервера.

Сначала хакер проверяет, включен ли файл xmlrpc.php, отправив следующий запрос.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 175

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>demo.sayHello</methodName>
<params>
<param>
<value>admin</value>
</param>
</params>
</methodCall>

Как только подтверждается, что XMLRPC включен на целевом веб-сайте, злоумышленник начинает атаковать его, используя сеть эксплуатируемых сайтов для отправки нескольких запросов pingback на сайт-жертву. Это может быть автоматизировано с нескольких хостов и использовано для массовой DDoS-атаки на сайт-жертву.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 293

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://173.244.58.36/</string></value>
</param>
<param>
<value><string>https://example.com/blog/how-to-make-a-salad</string></value>
</param>
</params>
</methodCall>

Межсайтовая атака портов (XSPA)

Межсайтовые атаки на порты (XSPA) очень распространены, когда хакер внедряет вредоносный скрипт для получения информации о TCP-портах и ​​IP-адресах. В случае WordPress XMLRPC используется вместе с механизмом обратного вызова для обхода любой маскировки IP-адресов, такой как базовый WAF, такой как Cloudflare.

В атаке XSPA хакер использует метод pingback.ping для проверки сообщения на целевом веб-сайте, который в свою очередь отправляет в ответ IP-адрес. Хакер использует сниффер, чтобы создать конечную точку для отправки пингбека и активного URL-адреса сообщения в блоге.

Хакеры отправляют следующий запрос с ее сервера.

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

Если ответ содержит код ошибки и значение больше 0, это означает, что порт открыт для прямой отправки пакетов HTTP.

Неэффективные методы блокировки XMLRPC-атак

На данный момент в статье мы установили, что файл xmlrpc.php подвержен некоторым серьезным кибератакам, таким как DDoS, Bruteforce и Cross-site Port Attack, поэтому крайне важно правильно с ним обращаться, чтобы блокировать эти атаки. .

Полностью удалив XMLRPC

Вы можете просто удалить файл XMLRPC, после чего ваш сервер начнет выдавать ошибку 404 любому, кто попытается получить к нему доступ. Недостатком этого решения является то, что файл будет создаваться заново каждый раз, когда вы обновляете WordPress.

Полностью отключив XMLRPC

Другой более жизнеспособный вариант — отключить файл xmlrpc.php . Вы можете сделать это, просто добавив блок кода в файл .htaccess . Убедитесь, что вы сделали это до того, как WordPress добавил постоянные правила .htaccess .

<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

Это отключит файл xmlrpc.php для каждого приложения или службы, которые его используют. Вы можете внести в белый список определенный IP-адрес, если вы все еще хотите получить доступ к своему сайту WordPress через XMLRPC. Для этого вам нужно добавить следующую команду:

<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>

Плюсы

• Устраняет риски злоупотребления XMLRPC в кибератаках.
• Долгосрочные преимущества производительности и экономия ресурсов сервера.

Минусы

• Отключение XMLRPC аналогично отключению удаленного доступа для приложений, использующих эту версию удаленного доступа. Это означает, что Jetpack, мобильное приложение WP или любое другое решение, которое подключается к вашему сайту WordPress через XMLRPC, больше не может подключаться к вашему сайту.
• Устаревший код для пользовательских приложений также может не работать.

Почему установка плагина безопасности на самом деле вредит вашему сайту

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

Вот несколько причин, по которым защита вашего сайта с помощью плагина — не лучший выбор.

• Плагины безопасности эффективны только на уровне приложений и не защищают ваш сервер от взлома.
• Они добавляют на ваш сайт ненужный код, который снижает его производительность и увеличивает время до первого байта (TTFB).
• Некоторые из этих плагинов приносят больше вреда, чем пользы, и используются хакерами для создания бэкдоров на вашем сайте.
• Эти плагины требуют частого управления, что увеличивает рабочую нагрузку.

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

Как Accelerated Domains справляется с проблемами XMLRPC для своих клиентов?

Ускоренные домены решают сложные проблемы с производительностью, безопасностью и масштабируемостью наиболее эффективным образом. Accelerated Domains предлагает управляемую безопасность на уровне предприятия, которая блокирует любые кибератаки, в том числе связанные с XMLRPC.

Интеллектуальный модуль безопасности Accelerated Domains размещается перед сервером и фильтрует около 40% всего HTTP-трафика. Он обнаруживает даже самые изощренные кибератаки на ранней стадии благодаря своим интеллектуальным эвристическим возможностям, основанным на непрерывной подаче данных и практических знаниях и анализе трафика Servebolt. Ускоренные домены творят чудеса, никоим образом не снижая производительность вашего сайта. На самом деле, это ускоряет его.

Упреждающий модуль безопасности Accelerated Domains автоматически защищает ваш сайт от DDoS-атак. Обладая пропускной способностью сети около 60 Тбит/с, он хорошо оснащен, чтобы противостоять даже некоторым из крупнейших DDoS-атак в Интернете. Точно так же он обеспечивает эффективный механизм защиты от атак грубой силы с помощью функции автоматического ограничения скорости, при которой количество запросов, сгенерированных из одного источника, идентифицируется и ограничивается для предотвращения злонамеренных действий.

Плюсы

• Ускоренные домены смягчают большинство уязвимостей безопасности, связанных с XMLRPC, поэтому нет необходимости отключать его.
• Позволяет пользователю продолжать использовать плагины, такие как Jetpack, приложение WooCommerce и другие инструменты, которые зависят от файла xmlrpc.php.
• Простая интеграция в любой домен, поэтому нет необходимости изменять файл .htaccess .
• Нет необходимости устанавливать дополнительные плагины.

Минусы

• У него нет.

Последние мысли

Кибератаки изо дня в день становятся все более изощренными, и вам, как веб-мастеру и владельцу бизнеса, жизненно важно понимать их и знать инструменты для борьбы с ними. Большинство атак можно избежать с помощью упреждающего подхода, такого как постоянный мониторинг и обновление программного обеспечения, или путем добавления таких инструментов, как ускоренные домены, которые делают все это на автопилоте. После включения Accelerated Domains интеллектуально фильтрует трафик и при необходимости предпринимает необходимые действия для защиты вашего исходного сервера и вашего веб-сайта от кибератак.