И опять атака на сайты Wordpress — перебор + XMLRPC. Xmlrpc php wordpress


Блокировка запросов к xmlrpc.php в wordpress

Некоторое время назад мониторинг показал повышенную нагрузку на веб-сервера. Традиционно сразу же пошел проверять лог веб сервера nginx на предмет подозрительной активности. Активность эта сразу же была замечена в виде запросов к файлу xmlrpc.php. Почитал в интернете, что это за файл и принял решение запретить к нему доступ, так как мне он не нужен.

Признаком повышенного интереса к вашему веб сайту на wordpress будут следующие строки в лог файле:

178.159.37.114 - - [26/Oct/2017:13:01:22 +0300] "POST //xmlrpc.php HTTP/1.1" 200 16014 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" "-"

Для примера, будем считать, что веб сервер настроен по статье — настройка web сервера nginx, php-fpm, php7 на CentOS 7. Там есть такое правило в конце перечисления locations в nginx:

location ~ /\.ht { deny all; }

Изменяем его, добавив блокировку файла xmlrpc.php и ставим его в списке самым первым location.

location ~* ^/(\.ht|xmlrpc\.php)$ { return 404; }

Перечитываем конфиг nginx:

# nginx -s reload

Проверяем, работает ли реально блокировка файла xmlrpc.php. Для этого сначала просто пройдите по ссылке, в моем случае такой — https://serveradmin.ru/xmlrpc.php Это мы проверили GET запрос. Чтобы проверить POST запрос, введите в адресной строке браузера следующую конструкцию:

data:text/html,<form action=https://serveradmin.ru/xmlrpc.php method=post><input name=a></form>

В появившейся форме введите любое значение и нажмите Enter на клавиатуре.

Проверяем лог файл.

# cat ssl-access.log | grep 77.27.225.139 77.27.225.139 - - [18/Dec/2017:15:35:07 +0300] "GET /xmlrpc.php HTTP/2.0" 404 201 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "1.30" 77.27.225.139 - - [18/Dec/2017:15:41:44 +0300] "POST /xmlrpc.php HTTP/2.0" 404 201 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "1.30"

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

Для повышения безопасности и защиты сайта на wordpress, читайте материалы на сайте по данной теме:

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Помогла статья? Есть возможность отблагодарить автора

serveradmin.ru

И опять атака на сайты Wordpress — перебор + XMLRPC / Хабр

С полудня субботы на моем сервере, где хостится около 25 сайтов на Wordpress, начались дикие тормоза. Так как мне удалось пережить предыдущие атаки (атака 1 — ровно год назад, атака 2 — в марте) не замеченными, то я не сразу понял, в чем дело.

Когда разобрался, то выяснилось, что идет перебор паролей + множество запросов к XMLRPC.

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

1. Останавливаем перебор, плагин Limit Login Attempts — ставим именно его, так как другие защиты сильно подвешивают сервер, например, при использовании плагина Login Security Solution сервер умер через полчаса, плагин сильно грузит базу.

В настройке обязательно включите галочку «За прокси» — иначе он будет для всех определять ip вашего сервера и автоматически блокировать всех. UPDATE, спасибо DarkByte, подробности ниже в комментах — галочку «За прокси» включаем только если не работает определение при включенном «Прямое подключение»

2. Отключаем XML-RPC — плагин Disable XML-RPC (его просто активировать и всё).

3. Закрываем wp-login.php — если обращаться к сайту через ip, то плагин не срабатывает и подборщики продолжают долбить сайт. Чтобы этого избежать, в .htaccess добавляем:

<Files wp-login.php> Order Deny,Allow Deny from all </Files>

Файл wp-login копируем, переименовываем в любое странное имя, например poletnormalny.php и внутри файла автозаменой меняем все надписи wp-login.php на poletnormalny.php. Все, теперь к админке можно обратиться только по вашему файлу.

После этих 3 несложных шагов сайты опять начали летать и пришло спокойствие.

Ну и вдруг интересно
Один из вариантов как посмотреть, что вас атакуют. Это можно увидеть в логах nginx (например, вот путь для Debian /var/log/nginx файл access.log).

Если идет перебор, то вы увидите множество строк вида: 87.230.87.xx — - [04/Aug/2014:06:35:53 +0400] «POST /wp-login.php HTTP/1.0» 200 5791 "-" "-"

Запросы XMLRPC: 95.0.83.xx — - [04/Aug/2014:06:48:03 +0400] «POST /xmlrpc.php HTTP/1.0» 499 0 "-" «Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)»

habr.com

Получение контроля над WordPress с помощью использования XML-RPC | Codeby.net

Вход Регистрация Что нового Codeby.net - Информационная Безопасность Codeby.net - Информационная Безопасность Меню Codeby.net - Информационная Безопасность Codeby.net - Информационная Безопасность

Форум

codeby.net

Как защитить свой Wordpress-сайт от постоянных обращений к XML-RPC

уязвимость Wordpress

Предыстория

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

нагрузка на хостинг

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

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

топ запросов

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

топ 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-ом крупный портал.

механизм DDoS с использованием XML-RPC

Что делать, чтобы избавиться от запросов 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 сторонние сайты.

ram32.ru

Wordpress XMLRPC DOS атака

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

На днях сайты моего хостинга, мягко говоря, — «прилегли». Было видно, что DOS-ят какой то из сайтов.

А видно это прежде всего из статистики использования ресурсов сервера:

worpress-xml-rpc-ddos-attack

Я удивился по той причине, что каких либо коммерческих ресурсов на хостинге не лежит. Чего, спрашивается, DOS-ить то? С какой целью?

Что видно на диаграмме?

На первой картинке мы наблюдаем загрузку процессора. Она измеряется в 100% на одно ядро. Где то 15.00 по гринвичу атака началась, а в районе 21.00 я попросил провайдера что то с этим сделать. Тех поддрежка начала перенос хостинга на другой мастер-сервер. Видимо, чтобы дать мне возможность использовать больше системных ресурсов. Часов в 22:00 начался переезд, проверка целостности файлов и другие процедуры.

Не хотелось на самом деле даже возиться —  и я просто лег спать, ибо, «утро вечера мудренее».

Что видно в логах сервера?

Статистика на утро уже не показывала каких либо аномалий. Сайты все равно открывались через раз и далеко не сразу, т.е. атака продолжалась. То ли статистика писалась все ещё со старого сервера, то ли это уже были данные мастер-сервера…

Поэтому я перешел к изучению логов, чтобы выяснить куда «стучат».

log-entomofagia.ru

Когда я погдял в логи, стало ясно, что можно не беспокоиться — стучит какая то школота с одного и того же ip адреса в /xmlrpc.php одного из моих сайтов на WordPress. Скорее всего занимается брут-форсом админского пароля.

Приятного конечно же мало, так как «лежат» и все остальные сайты виртуального сервера. И самое досадное, что я не использую эти XML сервисы ни на одном из своих WP сайтов.

Блокируем 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>

# 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>

<FilesMatch "^(xmlrpc\.php)">

Order Allow,Deny

Deny from 85.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>

<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>

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

После запрета доступа, в логах вы увидите как HTTP код 200 сменится на 403. Сервер уже не задействует PHP для обработки запроса, тот в свою очередь не обращается к MySQL… Для сервера обработка таких запросов не стоит больших усилий.

Данная запись опубликована в 23.04.2016 16:51 и размещена в wordpress. Вы можете перейти в конец страницы и оставить ваш комментарий.

shra.ru

Множественные запросы к xmlrpc.php в WordPress — Rusadmin

Сегодня заглянул в access-лог одного сайта на вордпресс и обнаружил множество запросов подобного рода:

1.234.83.77 - - [05/Sep/2014:12:07:01 +0600] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)" 1.234.83.77 - - [05/Sep/2014:12:07:01 +0600] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)" 1.234.83.77 - - [05/Sep/2014:12:07:02 +0600] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)" 1.234.83.77 - - [05/Sep/2014:12:07:02 +0600] "POST /xmlrpc.php HTTP/1.1" 200 441 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"

Судя по результатам гугления, есть какой-то эксплоит, связанный с этим файлом — xmlrpc.php. В одной статье на английском говорилось, как я понял, опираясь на свои плохие знания данного языка :), о возможности организовать подбор паролей. Правда, пока что я не заметил последствий, но лучше заранее принять меры. :)

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

Единственный момент: нужно подкорректировать правила в соответствии с запросом. В статье приводился пример:

[Definition] failregex = <HOST>.*/wp-login.php HTTP/1.1" 200 <HOST>.*/wp-login.php/ HTTP/1.1" 302 <HOST>.*/wp-login.php HTTP/1.0" 200 ignoreregex =

Данный список правил следует модифицировать так:

[Definition] failregex = <HOST>.*/xmlrpc.php HTTP/1. ignoreregex =

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

При этом, будет производится поиск любых запросов http 1.0 и http 1.1, с любым статус-кодом, полученным от сервера.

Вконтакте

Facebook

Twitter

Google+

Одноклассники

 

Как вы оцените статью? Загрузка...

rusadmin.biz

Брутфорс-атаки на Wordpress блоги и способы защиты от них

Уважаемые владельцы блогов на WordPress. На данный момент определенная часть блогов в Рунете на платформе WordPress подверглась массированной атаке. Из-за этой атаки сегодня с 7 утра данный блог не был доступен, так как хостер заблокировал его за нагрузку. Судя по логам, брутфорсят пароли к админке через wp-login.php, а также идет огромное количество запросов к файлу xmlrpc.php. В WordPress протокол XML-RPC по умолчанию активен. Через него то и идут брутфорс-атаки на сайт, которые грузят сервер и вынуждают хостера блочить аккаунт.

3Причем, как видно из логов, это уже вторая волна атаки. Первая атака на данный блог была 8-10 августа. Тогда сайт жутко тормозил, но продолжал работать. Вторая волна атаки началась сегодня утром. Если ваш блог все еще работает, то радуйтесь и готовьтесь защищаться.1Первое, что надо сделать — это заглянуть в свои логи. Если там есть следующие строки, то пора приступать к определенным действиям:204.93.211.113 — — [10/Aug/2014:07:03:59 +0400] «POST /wp-login.php HTTP/1.0» 200 4052178.150.204.92 — — [10/Aug/2014:07:04:04 +0400] «POST /wp-login.php HTTP/1.0» 200 4052178.150.204.92 — — [10/Aug/2014:07:04:04 +0400] «POST /wp-login.php HTTP/1.0» 200 4052204.93.211.113 — — [10/Aug/2014:07:04:03 +0400] «POST /wp-login.php HTTP/1.0» 200 4052

200.30.197.8 — — [15/Aug/2014:09:13:24 +0400] «POST /xmlrpc.php HTTP/1.0» 200 403212.200.74.161 — — [15/Aug/2014:09:13:44 +0400] «POST /xmlrpc.php HTTP/1.0» 200 40378.167.0.185 — — [15/Aug/2014:09:13:48 +0400] «POST /xmlrpc.php HTTP/1.0» 200 40399.45.171.11 — — [15/Aug/2014:09:13:54 +0400] «POST /xmlrpc.php HTTP/1.0» 200 403

2

Итак, 3 простых действия, которые защитят ваш блог от брутфорс-атак на wp-login.php и xmlrpc.php.ШАГ 1. Отключаем XML-RPC протокол ручным способом: вставляем в .htaccess следующий код:

<Files xmlrpc.php> Satisfy any Order allow,deny Deny from all </Files>

<Files xmlrpc.php> Satisfy any Order allow,deny Deny from all </Files>

Тем самым мы запрещаем обращение к файлу xmlrpc.php. Впрочем, если вам лень лезть в .htaccess, то можете установить плагин Disable XML-RPC, единственная функция которого отключение одноименного протокола.ШАГ 2. Закрываем доступ к wp-login.php кодом в .htaccess:

<Files wp-login.php> Order Deny,Allow Deny from all </Files>

<Files wp-login.php> Order Deny,Allow Deny from all </Files>

ШАГ 3. Переименовываем файл wp-login.php на хостинге на любое название с расширением .php. К примеру, kjhssfs.php. Не используйте в названии цифры, так как WP не воспримет данный файл и выдаст 404 ошибку. Затем открываем данный файл в блокноте и меняем во всех строках wp-login.php на название, которое вы дали файлу. Теперь в админку сможете войти только ВЫ, набрав в адресной строке http://ваш-сайт.ru/jhssfs.php.

Это самые простые шаги для решения данной проблемы. Не требуется никаких плагинов и дополнительных расширений. Обычная правка кода в определенных файлах. Возникнут вопросы — готов помочь в комментариях к данной статье. Удачи!

UPD^ Никто не знает, подобрали ли пароль к вашему блогу или нет. Рекомендую сменить пароль к блогу и сбросить кукисы, сменив «ключи» в wp-config.php. Получить новые «ключи» вы можете по адресу https://api.wordpress.org/secret-key/1.1/salt/

rxnblog.ru


Смотрите также

Prostoy-Site | Все права защищены © 2018 | Карта сайта