Защита wordpress от xml-rpc атаки

Защита WordPress от брутфорс атаки через XML-RPC

• Безопасность XML-RPC
• Как выявить атаку?
• Как защититься

В CMS WordPress есть возможность удаленной публикации, редактирования и удаления постов и комментариев. Функциональность реализована через протокол XML-RPC.

До версии 3.5 в настройках WordPress была возможность отключить XML-RPC.

Теперь такой возможности нет, протокол подключается по умолчанию с момента установки/обновления CMS.

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

Как выявить атаку?

Для выявления атаки у вас должна быть установлена панель управления ISPmanager со стандартными настройками.
Подключитесь к серверу по SSH и выполните команду:

grep -h $(date “+%d/%b/%Y”) /var/www/httpd-logs/*.access.log | awk '{print $1″ “$7}' | sort | uniq -c | sort -rnk1 | head -10 | grep -i xmlprc

В ответе на команду отобразятся столбцы: количество_запросов, адрес_запроса и url_запроса.

Пример:

2213 66.249.91.145 /bitrix/tools/conversion/ajax_counter.php 33 22.111.21.123 /bitrix/tools/conversion/ajax_counter.php 2 5.10.12.13 /bitrix/components/bitrix/sale.gift.product/ajax.php

Если среди этих запросов вы видите много обращений к xmlrpc.php,  скорее всего ваш сервер атакуют xmlrpc-bruteforce.

Как защититься?

Рассмотрим три способа защиты.
Если вы выявили проблему, но не уверены, что самостоятельно можете настроить защиту — напишите в службу поддержки.

Первый способ: редактируем wp-config.php

Подключитесь к серверу по FTP. Откройте каталог вашего сайта.Обычно это /var/www/www-root/data/www/ваш домен
В нем расположен файл wp-config.php. Откройте его для редактирования.

Найдите строку:

require_once(ABSPATH . 'wp-settings.php');

После нее допишите: 

add_filter('xmlrpc_enabled', '__return_false');

Второй способ: редактируем .htaccess

Как и в первом способе подключитесь к каталогу вашего сайта. Найдите файл .htaccess и откройте его для редактирования.

Добавьте в файл:

     Order Deny,Allow    Deny from all

Если на вашем сервере  Apache 2.4 нужно добавить другие строки:

   Satisfy any  Order allow,deny  Deny from all

Третий способ: сторонний плагин

Вы можете установить модуль Disable XML-RPC Pingback.
Дополнение можно загрузить с официального сайта WordPress или админ-панели вашего сайта.

Источник: https://FirstVDS.ru/technology/xmlrpc

Защита WordPress от атак Brute Force приложений

Похоже, что файл WordPress xmlrpc.php теперь стал объектом для нового типа атак. Раньше это были XML-RPC Pingback Vulnerability. Теперь это расширенные атаки Brute Force. В этой статье я расскажу о том, что вы должны знать об этой угрозе и что должны предпринять, чтобы защитить свой сайт от этого нового вредоносного воздействия.

Что XML-RPC?

Прежде чем перейти к описанию защиты файла xmlrpc.php, важно понять, что он делает. Как поясняется здесь:

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

XML-RPC позволяет удаленным платформам взаимодействовать между собой через Интернет. Если более конкретно, то файл WordPress xmlrpc.php позволяет внешним приложениям подключаться, передавать и обрабатывать данные.

Нужен ли мне XML-RPC?

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

Защита с помощью плагина

Если вы предпочитаете решать задачи с помощью плагинов, зайдите в WordPress Plugin Directory и задайте на поиск “xmlrpc plugin” . Уверен, что вы найдете хотя бы один плагин, который подходит для отключения xmlrpc.php.

Защита с помощью .htaccess

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

Блокировка xmlrpc.php помощью RedirectMatch

# protect xmlrpc RedirectMatch 403 (?i)/xmlrpc.php

Преимуществом этого способа является то, что не имеет значения, где вы установили WordPress. Файлы xmlrpc.

php будут защищены независимо от того, где они располагаются в структуре папок (например, /wp/xmlrpc.php, /wordpress/xmlrpc.php, /whatever/xmlrpc.php, и т.д.).

Этот способ также не зависит от регистра, так что вы защищены от любых вариаций атак типа «все прописные«.

Блокировка xmlrpc.php помощью Order/Deny

# protect xmlrpc Order Deny,Allow Deny from all

Лично я предпочитаю именно этот способ защиты от атак XML-RPC. Он простой, продуманный, надежный и не требующий поддержки. Можно настроить эти .htaccess-методы защиты xmlrpc.php, чтобы, например, разрешить доступ с конкретных IP-адресов и перенаправлять блокируемые запросы на определенную страницу.

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

Защита с помощью пользовательской функции

Если вы не хотите использовать сторонний плагин и возиться с .htaccess, существует еще один способ защиты от расширенных атак Brute Force — отключить выполнение метода system.multicall в файле xmlrpc.php. Ниже приведена функция, которую нужно добавить в файл functions.php вашей темы:

function shapeSpace_disable_xmlrpc_multicall($methods) { unset($methods['system.multicall']); return $methods; } add_filter('xmlrpc_methods', 'shapeSpace_disable_xmlrpc_multicall');

Несколько за и против этого метода:

• За — не нужно использовать другой плагин;
• За — не нужно использовать .htaccess;
• Против — связан с конкретной темой;
• Против — связан с конкретными угрозами.

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

А под «связан с конкретными угрозами» имеется в виду, что эта функция отключает только system.multicall для файла xmlrpc.php. Она защищает только против расширенных атак Brute Force, нацеленных на файл xmlrpc.php. Это еще одна причина того, почему метод с использованием .htaccess является идеальным выбором для защиты сайта: он защищает от всех типов атак на XML-RPC.

Подводя итог

Файл WordPress xmlrpc.php является целью для большого количества различных атак. Если вы используете последнюю версию WordPress, формально у вас нет причин волноваться. Но даже в этом случае файл остается вечной мишенью для злоумышленников. Плохие парни постоянно сканируют уязвимости, связанные с Pingback, расширенными атаками, brute-force атаками и всякими другими «пакостями».

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

Перевод статьи «Protect Against WordPress Brute Force Amplification Attack» был подготовлен дружной командой проекта Сайтостроение от А до Я.

Источник: http://www.internet-technologies.ru/articles/zaschita-wordpress-ot-atak-brute-force-prilozheniy.html

Как избавиться от XML-RPC-атаки на WordPress-сайты?

Несколько дней назад я заметил, что нагрузка моих сайтов на хостинг выросла в разы. Если обычно она составляла в районе 100-120 “попугаев” (CP), то за последние несколько дней она возросла до 400-500 CP. Ничего хорошего в этом нет, ведь хостер может перевести на более дорогой тариф, а то и вовсе прикрыть доступ к сайтам, поэтому я начал разбираться.

После письма хостеру (Beget) с объяснением ситуации, я получил подробную статистику с рекомендациями по исправлению проблемы. Итак, что мы видим:

Львиная часть запросов идет на WordPress-сайты, а именно – на обращение к файлу xmlrpc.php:

Топ IP-адресов выглядит подобным образом:

Используя соответствующие инструменты (к примеру, тот же http://2ip.ru/whois/), выясняем, что первые два IP (5.196.5.116 и 37.59.120.214) – это и есть наш атакующий. Оба IP из Франции (позже к ним присоединился еще один “француз” – 92.222.35.159). Третий по популярности IP-адрес (178.154.202.251) принадлежит поисковому боту Яндекса, его блокировать не стоит.

Возникает острое желание заблокировать доступ к сайтам с этих двух IP-адресов, это же советует и хостер:

Однако я решил разобраться в характере проблемы подробнее, дабы подобного не возникало впоследствии (к примеру, при смене атакующим IP).

Что это за XML-RPC-атаки?

XML-RPC – это стандартный механизм WordPress, который применяется в частности для механизма пингбэков. А в последних версиях WordPress, начиная с 3.5, пингбэки включены по умолчанию без возможности отключения их стандартными средствами.

Попросту говоря, механизм XML-RPC помогает сообщать другому сайту о том, что на него появилась ссылка в новом материале. Это стандартная возможность WordPress, и она не является уязвимостью.

Плохо становится, когда злоумышленники используют ее для спама/флуда. Используя множество сайтов, при помощи запросов с них xmlrpc.php можно устроить DDoS другому сайту (на который ссылаются).

Подробнее об этом механизме можно прочитать в этой статье: там рассказывается о случае 2014 года, когда атака со 162 тысячи Wordpress-сайтов (причем ничем не зараженных) практически “положила” DDoS-ом крупный портал.

Что делать, чтобы избавиться от запросов xmlrpc.php?

Ну что ж, тут, как говорится, все просто. Можно, конечно, попросту отрубить механизм XML-RPC, но это может аукнуться некорректной работой сторонних модулей, использующих его. Это можно сделать как вручную через настройку файлов .htaccess или wp-config.php, так и через установку плагинов (подробнее о всех возможных способах в этой статье).

Но я выбрал метод, который позволит сохранить функциональность XML-RPC: установку плагина Disable XML-RPC Pingback. Он удаляет лишь “опасные” методы pingback.ping и pingback.extensions.getPingbacks, оставляя функционал XML-RPC. После установки плагин нужно всего лишь активировать – дальнейшая настройка не требуется.

Попутно я забил все IP атакующих в файл .htaccess своих сайтов, чтобы заблокировать им доступ. Просто дописал в конец файла:

Order Allow,Deny Allow from all Deny from 5.196.5.116 37.59.120.214 92.222.35.159

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

Источник: http://ram32.ru/2015/01/12/kak-izbavitsya-ot-xml-rpc-ataki-na-wordpress-saytyi/

Как защитить WordPress от XML-RPC атаки в Ubuntu? | Статьи о хостинге, настройке Linux и Windows хостинга

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

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

В данном руководстве мы рассмотрим процесс защиты от такой атаки.

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

В WordPress XML-RPC –  протокол, который вызывает удалённо некоторые действия на вашем сайте. Так, плагин JetPack используется XML-RPC для своей работы. Грешит этим и мобильное приложение WordPress.

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

Как определить атаку XML-RPC (в частности в WordPress)?

Если в логах веб-сервера вы обнаружите большое количество записей типа “POST /xmlrpc.php HTTP/1.0”, то, скорее всего, вы подверглись XML-RPC атаке.

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

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

grep xmlrpc /var/log/apache2/access.log

Если у вас работает Nginx, то используйте следующую команду:

grep xmlrpc /var/log/nginx/access.log

Если в результате работы этих команд вы получите большой список вида:

111.222.333.444:80 555.666.777.888 – – [24/Jan/2017:00:03:50 -0500] “POST /xmlrpc.php HTTP/1.0” 200 674 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”

то вероятнее всего ваш проект был подвержен атаке XML-RPC.

Решение проблемы

Вариант 1: Установка плагина Jetpack.

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

Вариант 2: Блокировка трафика XML-RPC вручную.

Трафик можно заблокировать в настройках сервера Apache или Nginx. Хотим заметить, что при блокировке XML-RPC может не работать мобильное приложение и некоторые модули на сайте.

Внесите изменения в файл конфигурации Apache:

sudo nano /etc/apache2/sites-available/000-default.conf

Добавьте строки в блок :

……… order allow,deny deny from all ………

Сохраните и закройте файл.

Необходимо перезапустить веб-сервер, чтобы применились настройки:

sudo service apache2 restart

Для редактирования Nginx-файла конфигурации, введите:

sudo vim  /etc/nginx/sites-available/example.com

**examle.com — нужно заменить на название файла конфигурации вашего сайта

Необходимо добавить в блок server следующие строки:

server { ……… location /xmlrpc.php { deny all; } ……… }

Сохраните и закройте файл, а также перезапустите Nginx:

sudo service nginx restart

Проверка защиты

Если вы выбрали метод блокировки трафика XML-RPC через файлы конфигураций apache и nginx, в логи по-прежнему будут записываться подключения, но код ответа с 200 изменится на 500.

Запись будет выглядеть так:

111.222.333.444:80 555.666.777.888 – – [24/Jan/2017:02:04:21  -0500] “POST /xmlrpc.php HTTP/1.0” 500 674 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)” 111.222.333.444:80 555.666.777.888 – – [24/Jan/2017:02:04:21  -0500] “POST /xmlrpc.php HTTP/1.0” 500 674 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)” 111.222.333.444:80 555.666.777.888 – – [24/Jan/2017:02:04:22  -0500] “POST /xmlrpc.php HTTP/1.0” 500 674 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”

Источник: https://hoster.ru/blog/kak-zawitit-wordpress-ot-xml-rpc-ataki-v-ubuntu

Что такое XML-RPC и как остановить атаку на WordPress

XML-RPC – это протокол удаленных процедур, который позволяет удаленно взаимодействовать с вашим сайтом WordPress. Другими словами, это способ управлять сайтом без необходимости входа в систему вручную через стандартную страницу «wp-login.php».

 Он широко используется плагинами, наиболее известным из собственного плагина Jetpack от Automattic. Однако в эти дни слово «XML-RPC» получило плохое имя.

 В этой статьи мы объясним, что такое XML-RPC в WordPress и как остановить атаку XML-RPC на вашем веб-сайте WordPress. 

Включен ли XML-RPC на вашем веб-сайте на WordPress?

Быстрый способ проверить, является ли ваш сайт уязвимым, – это посетить следующий URL-адрес из браузера:

yoursite.ru/xmlrpc.php

Если он включен, вы должны получить ответ, в котором говорится, что «сервер XML-RPC принимает только запросы POST».

Опасности и преимущества 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 – начиная с самого легкого способа, до самого тяжелого.

Метод 1: Отключение Pingbacks

Это процесс, который использует ваш сервер в качестве невольного участника в атаке на другой сервер. В основном, кто-то говорит вашему сайту «Эй, этот URL-адрес, связанный с вашим блогом!», А затем ваш сайт отвечает «pingback» на этот URL.

 Кроме того,  нет никакой проверки, что URL на самом деле сделал ссылку на вас.

 Сделайте это с сотнями уязвимых сайтов WordPress, и у вас есть DDoS-атака на ваших руках! Самый простой способ запретить использование вашего сайта таким образом – добавить следующий код в функции functions.php вашей темы:

function stop_pings ($vectors) {
unset( $vectors['pingback.ping'] );
return $vectors;
}
add_filter( 'xmlrpc_methods', 'stop_pings');

Способ 2. Предотвращение всех запросов на аутентификацию через XML-RPC

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

Многим людям неудобно, когда XML-RPC может просто принимать случайные вызовы, подобные этому. Это привело к попыткам сотен или тысяч попыток аутентификации. Несмотря на то, что WordPress с тех пор обращался к этой конкретной форме взлома, есть те, кто рекомендует просто отключить ее.

Для этого введите этот код в functions.php:

add_filter('xmlrpc_enabled','__return_false');

Важно отметить, что это не то же самое, что и первый метод. Этот код только отключает методы проверки подлинности и оставляет все остальные нетронутыми – например, pingbacks.

Способ 3: Отключить доступ к xmlrpc.php

Это самый экстремальный метод, который полностью отключает все функции XML-RPC. Он требует, чтобы вы редактировали файл .htaccess в корневом каталоге вашего WordPress. Добавьте следующий код вверху:

Order allow,deny
Deny from all

Примечание

Если вы обнаружите, что ваша версия WordPress не имеет файла .htaccess в корневой папке, просто создайте файл со следующим кодом по умолчанию.

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Теперь, когда действуют выше правила отказа, попытка доступа к xmlrpc.php будет выполняться со следующей страницей:

И это все, что нужно. Вы успешно отключили XML-RPC на своем сайте WordPress.

Источник: https://andreyex.ru/blog-platforma-wordpress/chto-takoe-xml-rpc-i-kak-ostanovit-ataku-na-wordpress/

Что такое xmlrpc.php в WordPress и зачем его отключать

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

Ниже мы подробнее разберём xmlrpc.php и почему он был создан. Мы также рассмотрим общие проблемы безопасности, которые он может вызвать и как их исправить для вашего сайта на WordPress.

Что такое Xmlrpc.php?

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

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

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

Зачем был создан Xmlrpc.php и как он использовался?

Реализация XML-RPC уходит далеко в ранние дни WordPress и даже до того, как WordPress стал WordPress-ом.

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

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

XML-RPC сегодня

В 2008 году с версией 2.6 WordPress, появилась опция включения и выключения XML-RPC. Однако с релизом WordPress приложения для iPhone, поддержка XML-RPC была включена по умолчанию и не было возможности для отключения. Так осталось и поныне.

Конечно функциональность, предоставляемая этим файлом значительно уменьшилась со временем, и размер файла уменьшился с 83kb до 3kb, он уже не играет такой роли, как прежде.

Свойства XML-RPC

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

Хотя вы можете ожидать, что API будет включён непосредственно в ядро WordPress в будущем, что полностью исключит необходимость использования xmlrpc.php.

Новый API не идеален, но он обеспечивает хорошую надёжную защиту, в отличие от xmlrpc.php.

Зачем отключать Xmlrpc.php

Самой большой проблемой, связанной с XML-RPC, является безопасность. Проблема не напрямую связана с XML-RPC, но его можно использовать для включения атаки на ваш сайт.

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

Есть два основных слабых места XML-RPC, которые использовали в прошлом.

Первое – использует атаку путём прямого подбора пароля (brute force attacks) для получения доступа к вашему сайту. Атакующий попытается получить доступ к вашему сайту, используя xmlrpc.

php подбирая различные комбинации имён пользователей и паролей. Они могут эффективно использовать одну команду для тестирования сотен различных паролей.

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

Второе – перевод сайта в офлайн путём DDoS атаки. Хакеры будут использовать обратное уведомление в WordPress для отправки его тысячам сайтов одновременно. Этот функционал xmlrpc.php даёт хакерам почти бесконечное количество IP-адресов для распространения атаки DDoS.

Чтобы проверить, работает ли XML-RPC на вашем сайте, вы можете запустить его с помощью инструмента под названием XML-RPC Validator. Запустите свой сайт с помощью инструмента, и если вы получите сообщение об ошибке, значит, у вас нет поддержки XML-RPC.

Если вы получите сообщение об успешном завершении, вы можете остановить xmlrpc.php одним из двух подходов ниже.

Метод 1: отключение Xmlrpc.php при помощи плагина

Отключить XML-RPC на вашем сайте WordPress невероятно просто.

Перейдите в раздел Плагины › Добавить новый в вашей админ консоли WordPress. Найдите плагин Disable XML-RPC и установите его, он выглядит как на картинке ниже:

Активируйте плагин и всё готово. Этот плагин автоматически вставит необходимый код для отключения XML-RPC.

Однако помните, что установленные плагины могут использовать части XML-RPC, и тогда его отключение может вызвать конфликт плагинов или отдельных их частей и вывод их из рабочего режима.

Если вы хотите только отключить отдельные элементы XML-RPC, но позволить другим плагинам и функциям работать, тогда обратитесь к таким плагинам:

• Stop XML-RPC Attack. Этот плагин остановить все XML-RPC атаки, но он позволить продолжить работу таких плагинов как Jetpack и другие автоматические инструменты и плагины, предоставляя им доступ к файлам xmlrpc.php.
• Control XML-RPC Publishing. Это позволяет вам сохранить контроль и использовать удалённо публикации.

Метод 2: отключение Xmlrpc.php вручную

Если вы не хотите использовать плагин и предпочитаете делать это вручную, следуйте этому подходу. Он остановит все входящие запросы xmlrpc.php до того, как он будет передан в WordPress.

Откройте файл .htaccess. Возможно, вам придется включить ‘показать скрытые файлы’ в файловом менеджере или FTP-клиенте, чтобы найти этот файл.

Вставьте этот код в файл .htaccess:

# Block WordPress xmlrpc.php requests

order deny,allow
deny from all
allow from 123.123.123.123

Заключительные мысли

В целом, XML-RPC был добротным решением некоторых проблем, которые возникали из-за удаленной публикации на вашем сайте WordPress. Однако вместе с тем появились некоторые дыры в безопасности, которые оказались довольно опасными для некоторых владельцев сайтов на WordPress.

Чтобы ваш сайт оставался в безопасности, рекомендуется полностью отключить xmlrpc.php, если вам не нужны некоторые функции, необходимые для удаленной публикации и плагина Jetpack. Затем вы можете использовать обходные плагины, которые позволяют использовать эти функции, при этом исправляя дыры в безопасности.

Со временем мы можем ожидать, что функции XML-RPC станут интегрированными в новый WordPress API, который будет поддерживать удаленный доступ, не жертвуя безопасностью.

Вы заблокировали доступ к XML-RPC через плагин или вручную? Или возникли какие-либо проблемы с безопасностью из-за того, что он был прежде активным? Поделитесь своим опытом в комментариях ниже.

Источник: https://www.hostinger.ru/rukovodstva/chto-takoe-xmlrpcphp-v-wordpress/

Брутфорс-атаки на WordPress через XML-RPC и способ борьбы с ними

Разработчики WordPress в последних версиях упорно оставляют по-умолчанию активным протокол XML-RPC, причем, начиная с версии 3.5, такое поведение невозможно отключить.

Я понимаю, для чего это им надо — таким образом они ангажируют использование мобильных приложений, активно использующих возможности этого протокола для постинга записей и комментариев с мобильных платформ.

Конечно, это удобно, однако у XML-RPC есть и обратная — любые боты могут через файл xmlrpc.php проводить брутфорс-атаки, что и было незамедлительно применено ими.

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

Видно лавинообразное увеличение обращений к этому файлу, которое на большинстве сайтов ничем не компенсируется. Обычно от брутфорс-атак защищают файл wp-login.

php, например, с помощью популярного плагина Limit Login Attempts, пресекающего бесконечный перебор логинов и паролей. А вот про файл xmlrpc.

php мало кто вспоминает, что в сочетании активным по-умолчанию протоколом XML-RPC дает взломщикам легкий способ получения доступа к сайту с помощью брутфорс-атаки.

Я давно уже запретил в своих блогах использование XML-RPC, причем запретил полностью, вплоть до запрета обращения к файлу xmlrpc.php, о чем еще ни разу не пожалел.

Какие существуют способы защиты от брутфорс-атак на файл файл xmlrpc.php? Можно, а в большинстве случаев и нужно отключить протокол XML-RPC. Это можно сделать с помощью плагинов или вручную, внедрив коды в конфигурационные файлы.

Плагины

Полностью отключить использование этого протокола могут несколько плагинов:

Коды

Если вы не хотите использовать плагины, то запретить протокол XML-RPC можно вручную.

В файле .htaccess запретить прямой доступ к файлу xmlrpc.php:

Satisfy any  Order allow,deny  Deny from all

Отключить протокол может настройка файла wp-config.php. После строчки

require_once(ABSPATH . 'wp-settings.php');

нужно вставить

add_filter('xmlrpc_enabled', '__return_false');

Отключить систему уведомлений, передаваемый через XML-RPC можно, если добавить в файл functions.php используемой вами темы следующий код:

function remove_x_pingback($headers) {    unset($headers['X-Pingback']);    return $headers;}add_filter('wp_headers', 'remove_x_pingback');

Надеюсь, что приведенные способы защиты от брутфорс-атак через XML-RPC сделают ваш сайт более защищенным.

Источник: https://n-wp.ru/23987

Лучшая защита WordPress – плагин All In One WP Security (настройка)

Меня взломали. Знаете как страницу во ВКонтакте. Но они не клянчили денег, а насоздавали множество «левых» страниц с ссылками на разные сайты. Тогда я задумался над защитой своего блога. И я нашел идеальное решение.

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

Потом я установил множество плагинов для защиты ВордПресса от взлома. Но блог стал жутко тормозить. Страницы грузились по пять десять секунд. Это очень долго.

Я начал искать плагины которые не так сильно нагружают систему. Читал отзывы по этим плагинами и все чаще стал натыкаться на All In One WP Security. По описанию он мне очень понравился и я решил поставить его себе на блог. И он защищает меня до сих пор, так как ничего лучше я не встречал.

Что умеет All In One WP Security (защита wordpress всё в одном):

• Делает резервные копии базы данных, файла конфигурации wp-config. и файла .htaccess
• Смена адреса страницы авторизации
• Скрывает информацию о версии WordPress
• Защита админки — блокировка при неправильной авторизации
• Защита от роботов
• И ещё много чего полезного

Я смело могу сказать, что плагин безопасности All In One WP Security — это лучшая защита wordpress сайта.

Настройка All In One WP Security

Зайдя в отдел Настройки, первым делом нужно сделать резервные копии:

• база данных;
• файл wp-config;
• файл htaccess

Делается это на первой странице настройки плагина All In One WP Security.

сделайте бэкап (резервную копию) перед началом работы

Пройдусь только по самым важным пунктам.

пункты настройки плагина all in one wp security

Панель управления

Тут нас встречает счетчик «Измеритель безопасности». Он показывает уровень защиты сайта. Ваш сайт должен быть как минимум в зеленой зоне. Не надо гнаться за максимальной планкой — лишние настройки могут нарушить функционал сайта. Добейтесь золотой середины.

Счетчик защиты сайта на wordpress

Когда вы будете изменять настройки защиты плагина, то увидете в каждом пункте зелёный щит с цифрами — это и есть те цифры которые прибавляются к общему счету безопасности.

цифра прибавляется к общему счету безопасности

Настройки

Вкладка WP Version Info

Чекаем галочку Удаление метаданных WP Generator.

Удаление метаданных WP Generator

Делается это для того, чтобы в коде не отображалась установленная у вас версия движка WordPress. Злоумышленники знают в какой версии есть уязвимости, и зная установленную у вас версию ВордПресса смогут быстрее взломать ваш сайт.

Администраторы

Пользовательское имя WP

Если у вас логин для входа в админку admin, то обязательно меняем его. Admin это самый популярный логин. Многие ЦМСки предлагают его по умолчанию, а людям просто лень его менять. Злоумышленники используют различные программы для взлома сайтов. Эти программы подбирают логины и пароли пока не найдут подходящую комбинацию.

Поэтому не используйте логин admin.

Отображаемое имя

Если ваш ник совпадает с логином, то обязательно меняем логин или ник.

Пароль

Если ввести тут свой пароль, то плагин покажет за какое время можно взломать ваш сайт.
Рекомендации по усилению надёжности пароля:

• Пароль должен состоять из букв и цифр
• Используйте строчные и прописанные буквы
• Не используйте короткие пароли (минимум 6 символов)
• Желательно наличие в пароле спецсимволов (% # _  * @ $ и подробных)

Сложность пароля

Авторизация

вкладка Блокировка авторизаций

Обязательно включаем. Если в течении 5 минут кто-то неправильно введёт пароль 3 раза, то IP заблокируется на 60 минут. Можно поставить и больше, но лучше этого не делать.

Может случится так, что вы сами неправильно введёте пароль и будете потом ждать месяцы или даже годы 🙂 Отмечаем галочку «Сразу заблокировать неверные пользовательские имена».

Допустим ваш логин hozyainsayta, и если кто-то введёт другой логин (например login), то его IP адрес автоматически заблокируется.

опции блокировки авторизации

Автоматическое разлогинивание пользователей

Ставим галочку. Если вы зайдёте в админку сайта с другого компьютера и забудете выйти из админки, то через указанный промежуток времени система сама вас разлогинит.
Я ставлю 1440 минут (это 24 часа).

Опции автоматического разлогинивания пользователей

Регистрация пользователей

Подтверждение вручную

Чекаем «Активировать ручное одобрение новых регистраций»

Ручное одобрение новых регистраций

CAPTCHA при регистрации

Тоже ставим галочку. Это отсекает попытки зарегистрироваться боту-роботу, так как роботы не справляются с капчей.

Registration Honeypot (бочка мёда)

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

Защита базы данных

Префикс таблиц БД

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

обязательно сделайте резервную копию БД

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

Префикс таблиц Базы данных

Резервное копирование базы данных

Включаем автоматическое создание бэкапов. Выбираем частоту создание резервных копий. И количество файлов с этими резервными копиями, которые будут храниться. Потом они начнут перезаписывается.

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

Настройки резервного копирования Базы данных

Защита файловой системы

Доступ к файлам

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

Доступ к файлам

Редактирование файлов php

Ставим в том случае, если вы не редактируете файлы через админку. Вообще вносить какие либо изменения в файлы нужно через программы ftp-менеджеры (типо файлзилла). Так в случае какого либо «косяка» всегда можно отменить предыдущее действие.

Доступ к файлам wp

Запрещаем доступ. Этим действием мы сможем скрыть важную для хакеров информацию.

Черный список

Если у вас уже есть IP адреса которым вы хотите запретить доступ к сайту, то включайте эту опцию.

Блокировка пользователей по IP

Файрволл

Базовые правила файрволла

Файрволл и брандмауэр это программный комплекс представляющий собой фильтр несанкционированного трафика.

Эти правила вносятся в файл .htaccess, поэтому сначала делаем его резервную копию.

Теперь можно проставить нужные галочки:

Активировать основные функции брандмауэра

Защита от уязвимости XMLRPC и Pingback WordPress

Блокировать доступ к debug.log

Дополнительные правила файрволла

На этой вкладке отмечаем следующие галочки:

• Отключить возможность просмотра директорий
• Отключить HTTP-трассировку
• Запретить комментарии через прокси
• Запретить вредоносные строки в запросах (Может нарушить функциональность других плагинов)
• Активировать дополнительную фильтрацию символов (Тоже действуем с осторожностью, надо смотреть как влияет на работоспособность сайта)
  У каждого пункта есть кнопка «+ Подробнее» там вы можете почитать подробно про каждую опцию.

6G Blacklist Firewall Rules

Отмечаем оба пункта. Это проверенный список правил который дает плагин для безопасности wordpress сайта.

Настройки файрволла (брандмауэра)

Интернет-боты

Могут появиться проблемы с индексацией сайта. Я данную опцию не включаю.

Предотвратить хотлинки

Ставим галочку. Что-бы изображения с вашего сайта не показывались на других сайтах по прямой ссылке. Эта функция снижает нагрузку с сервера.

Детектирование 404

Ошибка 404 (такой страницы нет) появляется при ошибочном вводе адреса страницы. Хакеры перебором пытаются найти страницы с уязвимостями и поэтому вводят много несуществующих урлов в короткий промежуток времени.
Такие попытки взлома будут заноситься в таблицу на этой странице и чекнув галочку — вы сможете блокировать их IP адреса на указанное время.

Настройки отслеживания ошибок 404

Защита от брутфорс-атак

Переименовать страницу логина

По умолчанию у всех сайтов на Вордпрессе одинаковый адрес страницы авторизации. И поэтому злоумышленники точно знают где начать взламывать сайт.
Эта опция позволяет изменить адрес этой страницы. Это очень хорошая защита wordpress сайта. Обязательно меняем адрес. Я эту галочку не отметил, потому-что мой хостинг автоматически изменил мне эту страницу во время установки системы.

Переименовать страницу логина

Защита от брутфорс-атак с помощью куки

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

CAPTCHA на логин

Если на вашем сайте много пользователей или у вас интернет-магазин, то можете включать Капчу при авторизации во всех пунктах.

Защита капчей при авторизации

Белый список для логина

Заходите в админку только с домашнего компа и вы единственный пользователь своего сайта? Тогда впишите свой АйПи адрес и всем остальным доступ к странице авторизации будет закрыт.

Только указанные в списке IP имеют доступ к сайту

Бочка с медом (Honeypot)

Таже знакомая нам Бочка с мёдом — скрытое поле для роботов, но теперь для страницы авторизации.

Защита от роботов при попытке авторизации

Защита от SPAM

Вкладка Спам в комментариях

Капчу в формах для комментариев я не активирую, так как не хочу усложнять комментирование. Терпеть не могу когда приходится выполнять целый квест, что-бы написать пару строчек. А вот блокировку спам-ботов от комментирования включаем обязательно.

Защита комментариев

Сканнер

Отслеживание изменений в файлах

Конечно ставим галочку. Если защита wordpress плагина All In One WP Security все же пропустит хакера, то вы сможете узнать какие именно файлы изменил взломщик. Тогда вы сможете восстановить эти файлы из резервной копии.

Отслеживание изменений в файлах

Режим обслуживания

Защиты сайту не прибавит, но позволит создать заглушку на время пока вы «ремонтируете» сайт, тогда посетители поймут, что сайт не сломан, а идут профилактические работы.

Разное

Здесь может быть полезным только одна вкладка — Защита от копирования. Включив эту опцию — на сайте нельзя будет выделить и скопировать текст.

Защита от копирования текста

Настройка плагина безопасности WordPress All In One WP Security завершена.
Теперь самое время вернуться к пункту Панель управления и посмотреть, сколько балов показывает счетчик защиты.

Мой сайт защищен на 290 балов

Это был один из серии уроков про лучшие бесплатные плагины wordpress, так что подписывайся на новые статьи и читай только полезные уроки.
Шутка дня:

Если Вы проснулись на улице, значит Вы там заснули

Источник: http://1akm.ru/sozdanie-sayta-na-wordpress/urok-9-samaya-luchshaya-zashhita-wordpress-sayta-plagin-all-in-one-wp-security/

Базовая защита WordPress от вирусов и взлома

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

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

Основные меры по защите WordPress

Защитить WordPress от базовых угроз не сложно, для этого достаточно предпринять некоторые меры. Для того, чтобы упростить  поставленный задачи, я рекомендую воспользоваться плагином “Better WP Security”.

После установки и активации плагина на WordPress, пройдите в админку сайта на страницу настроек “Better WP Security”, и создайте резервную копию базы данных, на всякий случай.

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

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

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

Устранение уязвимостей WordPress

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

Для примера, я взял стандартный незащищенный блог на WordPress. Давайте вместе устраним все известные нам уязвимости в WordPress.

1. Проверка сложности пароля для всех пользователей

Для того чтобы обеспечить сложными паролями всех пользователей, нужно исправить первую уязвимость. Пройдите по ссылке “Нажмите, чтобы исправить” и на открывшейся странице выберите пункт как на рисунке снизу “Strong Password Role – Subscriber”. Тем самым, пароли всех ваших пользователей будут проходить проверку сложности.

2. Убираем дополнительную информацию из заголовка WordPress

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

Для удаления подобной информации поставьте галочку в соответствующем поле.

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

3. Скрываем обновления от не администраторов

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

4. Поменять логин администратора

Аккаунт администратора WordPress по умолчанию имеет логин admin, и об этом все знают. Поэтому ваш сайт взломать проще. Для того чтобы усложнить взлом сайта, рекомендую переименовать ваш администраторский аккаунт. Для этого перейдите по ссылке “Кликните здесь, чтобы переименовать администратора” и введите новое имя администратора в соответствующее поле.

5. Поменяйте ID администратора

Аккаунту администратора по умолчанию присваивается и ID=1, что также заведомо известно злоумышленникам, поэтому этот параметр нужно поменять. Плагин better wp security поменяет ID администратора за один клик.

6. Поменять префикс таблиц базы данных WordPress

По умочанию таблицы базы данных WordPress имеют префикс wp_. Рекомендуется поменять префикс на любой другой. Даже если ваша база данных уже наполнена информацией, то плагин better wp security поменяет префикс таблиц вашей базы без потери данных. Рекомендовано перед этим действием сделать резервную копию базы данных, что мы и сделали в самом начале.

7. Спланируйте создание резервных копий

Для регулярного создания резервной копии вашей базы данных, задайте некоторые условия и введите ваш e-mail, куда будут отправляться копии базы данных. Тем самым вы в любое время сможете восстановить базу данных из копии, при необходимости.

8. Запретить доступ к админке в определенное время

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

9. Заблокируйте подозрительные хосты

Если вы знаете IP адреса подозрительных хостов, с которых может быть произведена атака на ваш сайт, то занесите эти IP адреса в бан лист, и доступ к сайту с этих IP будет закрыт.

10. Защитить логин от перебора

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

11. Скрыть админку WordPress

Этот пункт не является критическим, но все же будет полезно скрыть админку WordPress. Скрытие WordPress админки происходит путем переименования директории с админ панелью. Физически админ панель будет лежать в той же папке, но по адресу http://ваш_сайт.ru/wp-admin она будет недоступна.

Скройте админ панель WordPress, для этого введите новые имена для директорий в соответствующие поля и поставьте галочку для включения данной опции.

12. Защитить файл .htaccess и скрыть каталоги от просмотра

Рекомендую вам скрыть каталоги сайта от свободного просмотра, а также защитить файл .htaccess. Также вы можете запретить выполнять различные запросы к сайту через адресную строку. Напоминаю, что данные действия могут вызвать конфликт с некоторыми плагинами и темами.

18. Запрещаем запись файлов wp-config.php и .htaccess

Некоторые пункты были по умолчанию выполнены, поэтому предлагаю вам выполнить наиболее важный 18 пункт защиты, который поможет запретить перезапись файлов wp-config.php и .htacces. Этот пункт очень важен, потому что от сохранности файлов wp-config.php и .htacces может зависеть работоспособность вашего сайта.

20. Переименовать папку с содержимым wp-content

Также вы можете переименовать папку с основным содержимым сайта wp-content. Нестандартное размещение файлов усложнит злоумышленникам доступ к ним.

21. Установка безопасного соединения с WordPress

Для работы с WordPress вы можете использовать безопасное соединение SSL, но для начала удостоверьтесь, что данный протокол поддерживается сервером, на котором размещается ваш сайт.

Вот таким образом, с помощью плагина “better wp security” вы можете защитить WordPress от базовых угроз, вирусов и атак.

Источник: http://www.onwordpress.ru/protection-wordpress.html

WordPress XML-RPC-атака

XML-RPC используется для Brute Force паролей

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

Это не ошибка в программном обеспечении. Реализация XML-RPC WP включает в себя процедуры аутентификации. Атакующие переключились на эту технику, поскольку она часто не блокируется различными плагинами грубой силы, и она быстрее.

Если вы не используете службы, требующие XML-RPC, вы можете просто отключить их. Я рекомендую установить права доступа к файлам 000.

Таким образом, вы можете легко вернуть изменение, если оно вызывает проблемы. Обратите внимание, что pingbacks используют xml-rpc, поэтому это приведет к поломке pingbacks, если вы включили их.

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

Мы видели, что это действительно влияет на серверы, когда несколько сайтов попадают в одно и то же время, и/или хостинг-провайдеры используют CloudLinux для управления ресурсами для каждой учетной записи.

Update:

XML-RPC DOS вопрос или Brute Force?

Кстати, у нас только что было предупреждение сервера о загрузке. В ходе расследования мы обнаружили, что сайт WP подвергся атаке. Я сделал немного дополнительного анализа и придумал эту проверку, чтобы определить, страдаете ли вы от проблемы с XML-RPC DOS или парольной атакой.

Есть две четкие признаки XML-RPC DoS Exploit:

• нескольких исходящих подключений к удаленным веб-сайтов.
• Высокая скорость трафика xmlrpc.php

С перебором, вы не увидите эти исходящие запросы на удаленный веб-сервер.

Глядя на странице состояния Apache мы видим:

7-0 17954 0/11/11 _ 0.96 2 16149 0.0 0.01 0.01 attacker.com localhost POST /xmlrpc.php HTTP/1.0 8-0 17962 0/10/10 _ 1.14 0 0 0.0 0.00 0.00 attacker.com localhost POST /xmlrpc.php HTTP/1.0 9-0 17968 0/10/10 _ 0.77 3 0 0.0 0.00 0.00 attacker.com localhost POST /xmlrpc.php HTTP/1.0

localhost является хозяином под атакой.

attacker.com – удаленная система наводнения в запросах до xmlrpc.php.

Глядя на NetStat (IP-адрес протертый по причинам конфиденциальности):

tcp 0 0 localhost:39254 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39248 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39251 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39250 remotehost:80 TIME_WAIT – tcp 0 1 localhost:39260 remotehost:80 FIN_WAIT1 – tcp 0 0 localhost:39257 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39258 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39237 remotehost:80 TIME_WAIT –

remotehost является жертвой атаки DoS.

Как правило, ваш localhost не должен звонить на удаленный веб-сервер, если вы не используете какой-либо удаленный API. Даже тогда, когда сотни таких соединений очень подозрительны. Обратите внимание, что мы видели оба порта 80 и 443 под атакой.

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

POST /xmlrpc.php HTTP/1.0 Host: localhost Content-type: text/xml Content-length: 268 User-agent: Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0) Connection: close pingback.pinghttp://victim.comhttp://localhost/blog/just-another-post/

В этом случае localhost был на самом деле IP-адрес, а не имя домена. Я не уверен, нужен ли IP для этой атаки, я бы так не подумал, но это будет означать, что вы устраните необходимость поиска DNS как для атаки, так и для сканирования.

Sucuri имеет хорошую запись WP XMLRPC DoS attack также Incapsula.

Источник: https://webmasters.stackovernet.com/ru/q/16555