WordPress xmlrpc dos атака

XML-RPC pingbacks attacks

In this case, an attacker is able to leverage the default XML-RPC API in order to perform callbacks for the following purposes:

1. Distributed denial-of-service (DDoS) attacks — An attacker executes the pingback.ping the method from several affected WordPress installations against a single unprotected target (botnet level).
2. Cloudflare Protection Bypass — An attacker executes the pingback.ping the method from a single affected WordPress installation which is protected by CloudFlare to an attacker-controlled public host (for example a VPS) in order to reveal the public IP of the target, therefore bypassing any DNS level protection.
3. XSPA (Cross Site Port Attack) — An attacker can execute the pingback.ping the method from a single affected WordPress installation to the same host (or other internal/private host) on different ports. An open port or an internal host can be determined by observing the difference in time of response and/or by looking at the response of the request.

The following represents an simple example request using the PostBin provided URL as callback:

Example response:

PostBin Output:

Brute force attacks

Sometimes the only way to bypass request limiting or blocking in a brute force attack against WordPress site is to use the all too forgotten XML-RPC API.

The following request represents the most common brute force attack:

The above request can be sent in Burp Intruder (for example) with different sets of credentials. Note that, even if you guess the password or not, the response code will always be 200. I highly recommend looking for errors/messages within the body of the response.

Worried about sending way to much requests against the target? — No worries. WordPress XML-RPC by default allows an attacker to perform a single request, and brute force hundreds of passwords.

The following request requires permissions for both system.multicall and wp.getUsersBlogs methods:

The response will look like:

In the above example I tested 4 different credentials sets using a single request. You just have to replace ` Your Username ` and ` Your Password ` with your own combinations.

That is it, please comment if I missed something and happy hunting!

Other references:

• https://www.wordfence.com/blog/2015/10/should-you-disable-xml-rpc-on-wordpress/
• https://medium.com/@the.bilal.rizwan/wordpress-xmlrpc-php-common-vulnerabilites-how-to-exploit-them-d8d3c8600b32
• https://github.com/1N3/Wordpress-XMLRPC-Brute-Force-Exploit/blob/master/wordpress-xmlrpc-brute-v2.py

Интернационализация i18n / локализация WordPress

Обзор возможностей как для интернационализации, так и для локализации i18n при разработке с Гутенбергом WordPress.

Локализации PHP WordPress

__( 'Hello World', 'my-text-domain' ): Перевести определенную строку
_x( 'Block', 'noun', 'my-text-domain' ): Перевести определенную строку с некоторым дополнительным контекстом.
_e( 'Hello World', 'my-text-domain' ): Перевести и напечатать определенную строку.
esc_html__( 'Hello World', 'my-text-domain' ): Перевести определенную строку и избежать ее для безопасного использования в выводе HTML.
esc_html_e( 'Hello World', 'my-text-domain' )Перевести определенную строку, избежать ее для безопасного использования в выводе HTML и распечатать.
_n( '%s Comment', '%s Comments', $number, 'my-text-domain' ): Переведите и получите форму единственного или множественного числа на основе предоставленного номера. 
Обычно используется в сочетании с sprintf()и number_format_i18n().

Локализации JavaScript WordPress

Исторически wp_localize_script()он использовался для помещения данных PHP на стороне сервера в правильно экранированный нативный объект JavaScript.

Новый редактор вводит новый подход к переводу строк для редактора через новый пакет под названием @wordpress/i18n.

Новый пакет скриптов зарегистрирован в WordPress как wp-i18nи должен быть объявлен как зависимость во время wp_register_script()и импортирован как глобальный объект Window как wp.i18n.

В зависимости от вашего рабочего процесса разработчика, вы можете использовать wp i18n make-potкоманду WP-CLI или инструмент сборки для вызова Babel @wordpress/babel-plugin-makepotдля создания необходимого файла перевода. Последний подход интегрируется с Babel для извлечения методов i18n.

Общие методы в wp.i18n:

setLocaleData( data: Object, domain: string ): Создает новый экземпляр I18N, предоставляющий данные перевода для домена.
__( 'Hello World', 'my-text-domain' ): Перевести определенную строку
_n( '%s Comment', '%s Comments', numberOfComments, 'my-text-domain' ): Переведите и получите форму единственного или множественного числа на основе предоставленного номера.
_x( 'Default', 'block style', 'my-text-domain' ): Перевести определенную строку с некоторым дополнительным контекстом.
sprintf(): Порт JavaScript функции PHP с тем же именем.

Dorks for finding potential targets

I would like to add that any illegal action is your own, and I can not be held responsible for your actions against a vulnerable target. Test only where you are allowed to do so. Go for the public, known bug bounties and earn your respect within the community.

That’s being said, during bug bounties or penetration testing assessments I had to identify all vulnerable WordPress targets on all subdomains following the rule . In this specific case I relied on Google dorks in order to fast discovery all potential targets:

• + scoping restrictions
• + scoping restrictions = general wordpress detection
• + scoping restrictions = general wordpress detection

XML-RPC pingback-атаки

В этом случае злоумышленник может использовать стандартный XML-RPC API для выполнения обратных вызовов для следующих целей:

1. Распределенное отклонение -of-service (DDoS) атаки — злоумышленник выполняет метод pingback.ping из нескольких затронутых установок WordPress против одной незащищенной цели (уровень ботнета).
2. Обход защиты Cloudflare — злоумышленник выполняет метод pingback.ping из единственной уязвимой установки WordPress, защищенной CloudFlare, до злоумышленника. -контролируемый общедоступный хост (например, VPS) для раскрытия общедоступного IP-адреса цели, таким образом обходя любую защиту уровня DNS.
3. XSPA (Атака межсайтового порта) — злоумышленник может выполнить метод pingback.ping из одной затронутой установки WordPress на тот же хост (или другой внутренний/частный хост ) на разных портах. Открытый порт или внутренний хост можно определить, наблюдая за разницей во времени ответа и/или просмотрев ответ на запрос.

Ниже представлен простой пример запроса. используя предоставленный PostBin URL в качестве обратного вызова:

Пример ответа:

Вывод PostBin:

Блокируем XML RPC.

Самое простое, что вы можете сделать в данной ситуации — удалить из корневой папки сайта файл /xmlrpc.php. Сервер не найдя скрипа, не будет запускать PHP, тратить ресурсы памяти и время процессора. Решение простое, но не красивое. Во-первых, кто то может пользоваться возможностями RPC. К примеру, публиковать записи на сайт через один из многих Weblog клиентов. А во-вторых, файл будет восстановлен после очередного обновления WP.

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

# XML-RPC DDoS PROTECTION
<FilesMatch «^(xmlrpc\.php)»>
Order Deny,Allow
Deny from all
</FilesMatch>

1 2 3 4 5

# XML-RPC DDoS PROTECTION <FilesMatch»^(xmlrpc\.php)»> Order Deny,Allow Deny from all </FilesMatch>

В моем случае можно было заблокировать только IP-адрес источника запросов, т.к. использовался один и тот же адрес. Для блокировки только IP адреса «школодосера»:

<FilesMatch «^(xmlrpc\.php)»>
Order Allow,Deny
Deny from 85.93.93.157
Allow from All
</FilesMatch>

1 2 3 4 5

<FilesMatch»^(xmlrpc\.php)»> Order Allow,Deny Deny from85.93.93.157 Allow from All </FilesMatch>

Но если вы пользуетесь RPC, то можно составить белый список адресов, которые имеют доступ к скрипту xmlrpc.php. 

<FilesMatch «^(xmlrpc\.php)»>
Order Deny,Allow
#add your IP adresses
Allow from 127.0.0.1
Allow from XX.XX.XX.XX
…
Deny from all
</FilesMatch>

1 2 3 4 5 6 7 8

<FilesMatch»^(xmlrpc\.php)»> Order Deny,Allow #add your IP adresses Allow from127.0.0.1 Allow from XX.XX.XX.XX … Deny from all </FilesMatch>

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

Защищаемся от спамеров и ботов

Если Вам надоел какой-то спамер, то решение – запретить ему доступ к сайту по IP. Это конечно не защитит от спам-скриптов, меняющих прокси, но иногда может пригодится. Вставьте этот код в файл .htaccess. Просто поменяйте адрес 123.456.789 на IP нехорошего человека, который вас достаёт и всё — он забанен:

<Limit GET POST PUT>
order allow,deny
allow from all
deny from 123.456.789
</LIMIT>

Так мы запрещаем доступ к сайту пользователям с конкретным IP. Нужно забанить ещё кого-то? Просто добавим ещё одну строку, к примеру —

deny from 93.121.78.8

Можно защититься от спамеров и ботов более хитрым способом: они часто не используют заголовки HTTP_REFERER и HTTP_USER_AGENT, в отличии от обычных браузеров, а значит можно запретить все POST запросы где в HTTP_REFERER не указан ваш сайт или же нет HTTP_USER_AGENT, пишем код в файл htaccess:

# Stop spam attack logins and comments
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
	RewriteCond %{HTTP_REFERER} !.*example.com.* 
	RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule (.*) - 
</ifModule>

Также в защите от вредоносных запросов, спама, плогих агентов поможет так называемый htaccess-фаервол — набор правил для htaccess 6G Firewall 2016

Как происходит взлом

Чаще других взламывают сайты на популярных CMS (WordPress, Joomla!, OpenCart, Drupal). Наиболее подвержены заражению сайты, использующие:

• Старые версии CMS;
• Необновленные или загруженные из неизвестных источников плагины, темы (шаблоны) и расширения;
• Слабые пароли к административной панели.

Для примера, в феврале 2020 года в плагине ThemeGrill Demo Importer для WordPress была обнаружена уязвимость, позволяющая полностью удалить все статьи и записи с сайта простым GET-запросом к одному из его файлов. Разработчик быстро исправил уязвимость, но она доставила неудобства многим пользователям, которые не успели вовремя обновить плагин.

В этой статье рассмотрим, как можно обезопасить сайт на CMS WordPress.

Для чего взламывают обычные сайты?

Ради забавы

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

Все остальные причины взломов сайтов более практичны.

Встраивание вредоносного кода для построения сети ботов и рассылки спама

Сайты взламывают с целью включения их в собственную сеть ботов, которая используется для различных хакерских атак или просто рассылки спама, а также других подобных не очень хороших действий. Это делается путем встраивания вредоносного кода на сайт, Вы можете и не сразу узнать о том, что Ваш сайт взломали. Хорошо, что сейчас и поисковые системы, например, Яндекс Вебмастер, и хостинг провайдер (имеется в виду, хороший хостинг провайдер), который периодически сканирует Ваш сайт на наличие угроз, в случае обнаружения угроз отправляют Вам соответствующее сообщение на электронную почту, чтобы Вы предприняли необходимые меры.

Встраивание вредоносного кода для заражения компьютеров пользователей

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

Черное SEO. Встраивание ссылок, размещение дополнительных страниц

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

Получить доступ к серверу на хостинге

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

Атаки грубой силы

Иногда единственный способ обойти ограничение или блокировку запросов с помощью грубой силы Атака на сайт WordPress заключается в использовании слишком забытого XML-RPC API .

Следующий запрос представляет собой наиболее распространенную атаку методом грубой силы:

Вышеупомянутый запрос может быть отправлен в Burp Intruder (например) с разными наборами учетных данных

Обратите внимание, что даже если вы угадаете пароль или нет, код ответа всегда будет 200. Я настоятельно рекомендую искать ошибки/сообщения в теле ответа

Обеспокоены отправкой большого количества запросов против цели? — Не беспокойтесь. WordPress XML-RPC по умолчанию позволяет злоумышленнику выполнить один запрос и перебрать сотни паролей.

Для следующего запроса требуются разрешения для обеих систем . методы multicall и wp.getUsersBlogs :

Ответ будет выглядеть так:

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

Вот и все, прокомментируйте, если я что-то пропустил, и удачной охоты!

Другие ссылки:

• https://www.wordfence.com/ блог/2015/10/should-you-disable-xml-rpc-on-wordpress/
• https://medium.com/@the.bilal.rizwan/wordpress-xmlrpc-php- общие-уязвимости-как-их-использовать-d8d3c8600b32
• https://github.com/1N3/Wordpress-XMLRPC-Brute-Force-Exploit/blob/master/wordpress-xmlrpc- brute-v2.py

Why Was Xmlrpc.php Created and How Was it Used?

The implementation of XML-RPC goes back to the early days of WordPress before it even became WordPress.

Back in the early days of the internet, when the connections were incredibly slow, the process of writing and publishing to the web was much more difficult and time-consuming. Instead of writing within the browser itself, most people would write offline, then copied and pasted their content onto the web. Still, this process was far from ideal.

The solution (at the time), was to create an offline blogging client, where you could compose your content, then connect to your blog to publish it. This connection was done through XML-RPC. With the basic framework of XML-RPC in place, early apps used this same connection to allow people to log in to their WordPress sites from other devices.

XML-RPC Nowadays

In 2008, with version 2.6 of WordPress, there was an option to enable or disable XML-RPC. However, with the release of the WordPress iPhone app, XML-RPC support was enabled by default, and there was no option to turn off the setting. This has remained true to the present day.

However, the functionality of this file has greatly decreased over time, and the overall size of the file has decreased from 83kb to 3kb, so it doesn’t play as large of a role as it used to.

The Future of XML-RPC

With the new WordPress API, we can expect XML-RPC to be eliminated entirely. Today, this new API is still in the trial phase and can only be enabled through the use of a plugin.

However, you can expect the API to be coded directly into the WordPress core in the future, which will mostly eliminate the need for the xmlrpc.php file altogether.

The new API isn’t perfect, but it provides a more robust and secure solution to the problem that xmlrpc.php addressed.

Опасности и преимущества XML-RPC

В сообществе безопасности WordPress было много вопросов о XML-RPC. В основном есть две проблемы:

1. XML-RPC можно использовать для DDoS-атаки
2. Его можно использовать для повторного использования комбинаций имени пользователя и пароля

По крайней мере, это было возможно. С тех пор WordPress подключил лазейки (https://core.trac.wordpress.org/ticket/34336) , которые позволили людям одновременно попробовать сотни имен пользователей и паролей. Начиная с версии 4.4, она была улучшена. Теперь WordPress будет молча выполнять все последующие попытки входа в систему, как только один вызов XML-RPC завершился неудачно. Большой!

Тем не менее, есть те, кто по-прежнему обеспокоен легкостью, в то время как удаленные вызовы процедур, подобные этому, могут быть сделаны. Итак, вот несколько способов защитить ваш сайт от XML-RPC – начиная с самого легкого способа, до самого тяжелого.

Что такое XML-RPC?

XML-RPC – это протокол вызова удалённых процедур.

WordPress использует XML-RPC для удалённого выполнения функций. Наиболее яркими примерами реализации этого протокола является популярный плагин JetPack и мобильное приложение WordPress. Однако этот протокол также можно использовать для отправки на WordPress огромного количества запросов за короткий промежуток времени (что, в сущности, является brute force атакой).

Как определить атаку XML-RPC?

Существует два основных способа распознать атаку XML-RPC:

• Получение ранее упомянутого сообщения Error connecting to database.
• Обнаружение в логах веб-сервера большого количества подобных записей:

Расположение лог-файлов веб-сервера зависит от дистрибутива Linux.

Для выявления атак XML-RPC на Apache в Ubuntu 14.04 используйте:

На сервере Nginx используйте команду:

Сайт WordPress был подвержен атаке XML-RPC, если эти команды вернули очень объёмный вывод, содержащий множество подобных строк:

Далее можно найти инструкции по предотвращению подобных атак.

What Is Xmlrpc.php?

XML-RPC is a feature of WordPress that enables data to be transmitted, with HTTP acting as the transport mechanism and XML as the encoding mechanism. Since WordPress isn’t a self-enclosed system and occasionally needs to communicate with other systems, this was sought to handle that job.

For example, let’s say you wanted to post to your site from your mobile device since your computer was nowhere nearby. You could use the remote access feature enabled by xmlrpc.php to do just that.

The core features that xmlrpc.php enabled were allowing you to connect to your site via smartphone, implementing trackbacks and pingbacks from other sites, and some functions associated with the Jetpack plugin.

Ограничиваем доступ к файлам

Защищаем wp-config и xmlrpc через .htaccess

wp-config.php содержит все данные, необходимые для подключения к серверу MySQL и базе данных. Защита этого файла – важная задача.

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

Работает ли он можно проверить вот тут: http://xmlrpc.eritreo.it/

• Работает и нужно отключать: Congratulation! Your site passed the first check.
• Не работает, отключать не нужно: Failed to check your site at because of the following error: 405 XML-RPC services are disabled on this site.

Ставим плагин Disable XML-RPC или в файле .htaccess прописываем :

Options -Indexes
<files ~ "(wp-config|xmlrpc).php$">
order allow,deny
deny from all
</files>

Защищаем папку wp-includes

В папке /wp-includes/ создаем .htaccess вот с таким содержимым:

order deny,allow
deny from all
<files ~ "(.(xml|css|jp?g|png|gif|js)|wp-tinymce.php)$">
 allow from all
</files>

Тем самым закрывая извне доступ ко всему, кроме перечисленных выше типов файлов .

Защита директорий на сервере от просмотра

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

Вы можете либо добавить пустые файлы  в папки, просмотр которых хотели бы запретить. Либо дополнить наш .htaccess ещё одной строкой:

Options All -Indexes

Пустой index.html будет выдаваться каждый раз, когда последует запрос к директории. Ну а директива в .htaccess просто запрещает апачу выдавать список содержимого директории.

Атака №2. Запросы со всего мира

Как лечить?

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

Чтобы отфильтровать их мы активировали бесплатную лицензию сервиса CloudFlare. Сервис пропускает через свое оборудование любой трафик и выделяет запросы, похожие на атаки. Услугами безопасности от CloudFlare пользуются известные компании такие как: «Uber» и «Авито».

Изначально сайт пинговали из одной страны, затем по цепочке подключались другие. Фронтендщик вручную блокировал все сомнительные источники с большим количеством запросов из-за рубежа. В их числе Индия, Индонезия, Бразилия, Албания, Румыния и др.

Помогла функция CloudFlare, которая определяет, кто хочет посетить сайт: пользователь или машина. Во время проверки, а именно сложных математических вычислений, сайт на 5 сек зависает. А на его странице появляется такая заглушка:

Если IP-адрес успешно прошел JavaScript Challenge и считается безопасным, то спустя 5 сек сервис редиректит запрос на сайт. Там же в настройках программист вводит подозрительные страны, если запросы поступившие оттуда — нелегитимные.

Когда бесплатный лимит был исчерпан, сотрудники компании приобрели премиумный тариф за 20 USD.

Плюсы работы с CloudFlare

До того как разработчики воспользовались инструментарием CloudFlare они пытались тушить пожар, возникший из-за включенного XML-RPC в WordPress.

Однако Кузнец отправлял и отправлял запросы. Сервер банально «ложился» из-за этого. Конечно можно было разделить нагрузку по разным серверам, но защиты бы от этого не прибавилось. Выход разработчики нашли только в сервисе, который умеет фильтровать трафик — CloudFlare.

Минусы работы с CloudFlare

Одновременно с победой над Кузнецом IT-компания столкнулась с новыми трудностями из-за CloudFlare:

1. Если в браузере пользователя включен VРN, то зайти на корпоративный сайт или в его админку будет невозможно. Одна из точек входа для большей части ВПН — Румыния, через которую Кузнец вел атаку на сайт ранее.
2. Конверсия сайта понесла значительный ущерб. Редкий посетитель будет ждать 5 сек, чтобы войти на сайт.
3. Часть IP-адресов CloudFlare находится в реестре запрещенных Роскомнадзором и не работают в России.

Изменение адреса админ-панели

Возможно, это не самый простой и удобный способ защиты, но точно один из максимально эффективных. Изменить адрес (URL) для входа в админ панель можно вручную, если вы опытный администратор, или же при помощи специальных плагинов.

Вручную процесс состоит из нескольких этапов:

1. Переименуйте файл wp-login.php. Используйте случайную последовательность строчных латинских букв, цифры и тире. Например: some-new-page456.php
2. В получившемся файле найдите все упоминания wp-login.php и замените их на новое название.
3. Для корректной работы сайта замену необходимо проделать также в файлах: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general-template.php, link-template.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, my-sites.php, schema.php, ru_RU.po

После этого адрес админ панели будет располагаться по вашей новой ссылке https://site.com/some-new-page456.php. Доступ к новому файлу было бы полезно тоже ограничить и защитить паролем так, как указано выше.

Более простой способ — использование плагина, например, WPS Hide Login. После установки плагина в меню “Настройки” появится новый пункт WPS Hide Login.

Скрытие имени пользователя

WordPress может где-либо выводить username пользователя который опубликовал запись. Например в шаблоне могут выводиться ссылки на архивы автора: elims.org.ua/author/admin/ Благодаря этому злоумышленники будут знать к какому login’у учетки можно подбирать пароль. Позаботьтесь о том, чтобы этого не было.

Мало того, в базе данных в таблице wp_users в поле user_nicename можно установить имя, которое будет отличаться от логина user_login. Значение поля user_nicename как раз и используется для генерации ссылки на архив автора. Таким образом даже если злоумышленникам и получиться найти ссылку на архив автора, то она не выдаст ваш login.

Closing Thoughts

Overall, XML-RPC was a solid solution to some of the problems that occurred due to remote publishing to your WordPress site. However, with this feature came some security holes that ended up being pretty damaging for some WordPress site owners.

To ensure your site remains secure it’s a good idea to disable xmlrpc.php entirely. Unless you require some of the functions needed for remote publishing and the Jetpack plugin. Then, you should use the workaround plugins that allow for these features, while still patching the security holes.

In time, we can expect the features of XML-RPC to become integrated into the new WordPress API, which will keep remote access and the like, without sacrificing security. But, in the meantime, it’s a good idea to protect yourself from the potential XML-RPC security holes.

Have you blocked XML-RPC access via a plugin or manually? Or experienced any security issues from having it active in the first place? Please share your experience in the comments below. 

Отключение xmlrpc.php

Атаки путем запросов к файлу xmlrpc.php очень популярны, поскольку таким образом за один запрос возможно перебрать десятки тысяч комбинаций различных логинов и паролей. Поэтому очень важная часть защиты админ-панели — это отключение или ограничение доступа к данному файлу. В WordPress протокол XML-RPC используется для взаимодействия движка с различными внешними приложениями, например, Jetpack. Как показывает практика, в 99% сайтов файл xmlrpc.php не используется вообще. Если вы сомневаетесь, используется он у вас или нет, то создайте резервную копию файлов, которые вы будете изменять перед выполнением дальнейших инструкций.

Отключение xmlrpc.php при помощи плагинов

Для отключения xmlrpc.php можно использовать различные плагины, которых на данный момент уже достаточно много. Просто напишите в поиске в маркетплейсе плагинов «xmlrpc»:

После установки не забудьте активировать плагин и включить саму защиту в настройках выбранного плагина.

Запрет доступа к  xmlrpc.php при помощи .htaccess

Первый вариант:

<IfModule mod_alias.c>
RedirectMatch 403 (?i)/xmlrpc.php
</IfModule>

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

Второй вариант:

<Files xmlrpc.php>
Require all denied
Require ip 127.0.0.1 #разрешить локальные подключения
Require ip 23.45.67.89 #один адрес
Require ip 10.20.30.40 #еще один адре
</Files>

Этот способ удобен тем, что можно закрыть доступ для всех или оставить доступ с некоторых доверенных адресов, если требуется.

Запрет доступа к  xmlrpc.php при помощи Nginx

Если на вашем сервере не используется Apache, то запрет доступа через Nginx будет выглядеть так:

location /xmlrpc.php
{
allow 23.45.67.89; #один адрес
allow 123.123.123.0/24; #блок адресов
deny all; #запрет всем остальным
}

Отключение xmlrpc.php при помощи пользовательской функции

Еще один вариант защиты связан с добавлением пользовательской функции в файл вашей темы сайта. В конце functions.php вашей темы добавьте код:

function shapeSpace_disable_xmlrpc_multicall($methods) {
unset($methods);
return $methods;
}
add_filter('xmlrpc_methods', 'shapeSpace_disable_xmlrpc_multicall');

Данный метод позволяет не затрагивать настройки Apache или Nginx и будет полезен, если у вас ограниченный доступ к серверу, где расположен сайт. Но недостаток в том, что защита привязана к конкретной теме и при ее изменении или обновлении настройку нужно добавлять повторно.

Метод 1: Установка плагина Jetpack

В идеале следует защищать сервер от атак XML-RPC до того, как они произойдут. Функция Protect плагина Jetpack блокирует запросы multicall протокола XML-RPC. Записи XML-RPC по-прежнему будут поступать в логи сервера. Jetpack снизит нагрузку на БД, создаваемую вредоносными попытками входа, до 90%.

Примечание: Для активации плагина Jetpack необходима учётная запись WordPress.com.

Чтобы установить Jetpack, откройте панель управления WordPress и выберите Plugins->Add New.

Программа предложит список доступных плагинов, который должен содержать Jetpack. Если у вас не получается найти в списке нужный плагин, воспользуйтесь поисковой строкой.

Функция Protect будет включена, даже если вы пропустите Jump Start. На экране появится панель инструментов Jetpack, которая также покажет, что функция Protect активирована.

Чтобы создать белый список IP-адресов, которые функция не должна блокировать, нажмите на изображение шестерёнки рядом с Protect.

На экране появится окно, в котором нужно указать все заведомо безопасные адреса IPv4 или IPv6. После этого нажмите Save, чтобы сохранить белый список.

Настраиваем nginx

Считаем что в качестве фронтенда у нас работает nginx, и несколько пересмотрев его конфиг из прошлой записи решил довести его до вида, который описан ниже.

Запрещаем вывод листинга файлов, если nginx собран с модулем :

Закрываем доступ к ридмишкам, некоторым типам логов и системных файлов:

Запрещаем запросы, которые содержат следующие вхождения:

Запрещаем запросы, в параметрах которых есть следующие подстроки:

Запрещаем вывод информации об авторах (и получение списка логинов через перебор ) через запросы вида :

Запрещаем запуск скриптов из директорий загрузок и :

Запрещаем ссылки вида и , которые часто встречаются в инструментах перебора:

Для аудита сайтов на WordPress очень распространен такой инструмент как WPScan и на противодействии ему остановимся чуть подробнее. Даже после того, как мы приняли необходимые меры по скрытию версии WP — данный инструмент безошибочно определяет её путем получения некоторых публичных файлов и сравнения их контрольных сумм.

Крайняя версия WPScan (на момент написания данной записи от ) ориентирована на два файла — и . Он формирует с виду очень “правильный” запрос, с рефералом и необходимыми плюшками, всё как полагается. Если просто закрыть доступ к этим файлам то пострадает функционал WP, так как они необходимы в ряде случаев для корректной работы панели администратора. Как же решить эту задачку?

WPScan отправляет реферер, всегда равный . Но файлы то нам нужны только для панели администрирования, и соответственно в при их “легальном” запросе в реферере должна присутствовать подстрока . Если её нет — значит запрос можно детектировать как пришедший “извне”. Этой то особенностью мы и воспользуемся

Более того, для понижения информативности вывода данного инструмента мы запретим ему читать файл . Как запретить доступ для WPScan? Дело всё в том же реферале. Поисковые роботы не отправляют никакого реферера для его чтения, а WPScan шлёт всё тот же

Хардкорно имитируем ошибки 404 при запросе директорий, характерных для WP:

И ещё один интересный момент — запрещаем прямой доступ к директориям плагинов. Делается это в первую очередь для предотвращения их раскрытия путем простого перебора имен директорий:

Закрываем доступ к файлам переводов (которые зачастую так же содержат версию используемой CMS):

Запрещаем доступ следующим -ам:

И блокируем всех, у кого пустой (или почти пустой):

Отключение вывода ошибок php

Если проверять свой wordpress сайт при помощи таких сканеров безопасности как wpsec.ru, то можно увидеть такое не критическое предупреждение

Оно говорит о том, что если перейти по адресу site.org.ua/wp-includes/rss-functions.php то можно увидеть ошибку php в которой раскрывается полный путь к этому файлу на хостинге.  Благодаря этой информации можно попытаться использовать некоторые уязвимости, подробней можно прочесть на сайте owasp.org или hakipedia.com.

Чтобы отключить вывод ошибок php нужно сделать одно из двух действий, в зависимости от конфигурации вашего хостинга:

Прописать в файле .htaccess строку

php_flag display_errors off

если же это вызвало ошибку «internal server error», то удалить эту строку и отключить вывод ошибок в файле «php.ini» при помощи строки:

display_errors = 'off'

Я использую Хостинг Украина и у меня это отключается через настройки php для сайта: просто убирается галочка возле надписи «display_errors».

Также можно прописать вот этот код в файл wp-config:

error_reporting(0); @ini_set('display_errors', 0);