И опять атака на сайты 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; }Перечитываем конфиг 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
Вход Регистрация Что нового
Меню - Главная
- Форум Новые сообщения
- Ресурсы Последние отзывы
- Мы в сети Наша группа в Вконтакте Наш канал в телеграм Наш чат в телеграм Наш Twitter Онлайн школа ИБ codeby Офлайн школа ИБ в Твери Codeby OS
- Премиум
- Гарант
- Школа ИБ
- Магазин
- Фриланс
- Биржа труда
- Codeby OS
Форум
- Новые сообщения
codeby.net
Как защитить свой Wordpress-сайт от постоянных обращений к XML-RPC
Предыстория
Несколько дней назад я заметил, что нагрузка моих сайтов на хостинг выросла в разы. Если обычно она составляла в районе 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 сторонние сайты.
ram32.ru
Wordpress XMLRPC DOS атака
Хакеры ищут разные пути взлома ваших сайтов. В большистве случаев, если только сайт не представляет какой то коммерческой ценности, это резвятся детишки, пытаясь сомоутвердиться.
На днях сайты моего хостинга, мягко говоря, — «прилегли». Было видно, что DOS-ят какой то из сайтов.
А видно это прежде всего из статистики использования ресурсов сервера:
Я удивился по той причине, что каких либо коммерческих ресурсов на хостинге не лежит. Чего, спрашивается, DOS-ить то? С какой целью?
Что видно на диаграмме?
На первой картинке мы наблюдаем загрузку процессора. Она измеряется в 100% на одно ядро. Где то 15.00 по гринвичу атака началась, а в районе 21.00 я попросил провайдера что то с этим сделать. Тех поддрежка начала перенос хостинга на другой мастер-сервер. Видимо, чтобы дать мне возможность использовать больше системных ресурсов. Часов в 22:00 начался переезд, проверка целостности файлов и другие процедуры.
Не хотелось на самом деле даже возиться — и я просто лег спать, ибо, «утро вечера мудренее».
Что видно в логах сервера?
Статистика на утро уже не показывала каких либо аномалий. Сайты все равно открывались через раз и далеко не сразу, т.е. атака продолжалась. То ли статистика писалась все ещё со старого сервера, то ли это уже были данные мастер-сервера…
Поэтому я перешел к изучению логов, чтобы выяснить куда «стучат».
Когда я погдял в логи, стало ясно, что можно не беспокоиться — стучит какая то школота с одного и того же 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, с любым статус-кодом, полученным от сервера.
Вконтакте
Google+
Одноклассники
Как вы оцените статью?
Загрузка... rusadmin.biz
Брутфорс-атаки на Wordpress блоги и способы защиты от них
Уважаемые владельцы блогов на WordPress. На данный момент определенная часть блогов в Рунете на платформе WordPress подверглась массированной атаке. Из-за этой атаки сегодня с 7 утра данный блог не был доступен, так как хостер заблокировал его за нагрузку. Судя по логам, брутфорсят пароли к админке через wp-login.php, а также идет огромное количество запросов к файлу xmlrpc.php. В WordPress протокол XML-RPC по умолчанию активен. Через него то и идут брутфорс-атаки на сайт, которые грузят сервер и вынуждают хостера блочить аккаунт.
Причем, как видно из логов, это уже вторая волна атаки. Первая атака на данный блог была 8-10 августа. Тогда сайт жутко тормозил, но продолжал работать. Вторая волна атаки началась сегодня утром. Если ваш блог все еще работает, то радуйтесь и готовьтесь защищаться.
Первое, что надо сделать — это заглянуть в свои логи. Если там есть следующие строки, то пора приступать к определенным действиям: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
Итак, 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
