Сильный xmlrpc php. Соревнования по программированию

С полудня субботы на моем сервере, где хостится около 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 добавляем:

Order Deny,Allow Deny from all

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

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

Ну и вдруг интересно

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

Каждый у кого есть свой веб-сайт хочет повысить его безопасность, если нет, то хочет чтобы он был всегда в безопасности... Собственно в этой статье мы и разберем принципы и основы защиты движка WordPress, а конкретно мы посмотрим более детально на файл xmlrpc.php . Не забывайте делать бекапы при изменении или внесении тех или иных правок в файлы. Давайте начнем.

Уязвимость WordPress через файл xmlrpc.php, решение проблемы:

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

Для начала отключим файл xmlrpc.php , через него проходит достаточно много атак на сайт, а это не есть хорошо. Как и обычно есть 2 варианта сделать это, первый внесением правок в файлы.htaccess и functions.php, а также header.php (наиболее правильный на мой взгляд способ). И методом установки плагина, но об этом чуть позже. Перейдем к правкам файлов.

В файл functions.php вставляем:

// отключаем xmlrpc.php add_filter("xmlrpc_enabled", "__return_false"); remove_action("wp_head", "rsd_link");

В файле header.php удаляем:

order deny,allow deny from all

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

Использование XML-RPC в PHP для публикации материалов в LiveJournal.com (ЖЖ)

Для начала вам потребуется скачать библиотеку XML-RPC. Наиболее удачной версией мне кажется свободно распространяемая через sourceforge " ": Все примеры ниже будут приведены для этой библиотеки версии 2.2.

Что же такое XML-RPC? RPC расшифровывается как Remote Procedure Call, соответственно на русский это можно перевести как удаленный вызов процедур с помощью XML. Сама методика удаленного вызова процедуры известна давно и используется в таких технологиях, как DCOM, SOAP, CORBA. RPC предназначен для построения распределенных клиент-серверных приложений. Это дает возможность строить приложения, которые работают в гетерогенных сетях, например, на компьютерах различных систем, производить удаленную обработку данных и управление удаленными приложениями. В частности этим протоколом пользуется хорошо известный в России сайт livejournal.com.

Рассмотрим пример, как можно разместить кириллическую запись (а именно с этим часто возникают проблемы) в ЖЖ. Ниже приведен работающий код с комментариями:

new xmlrpcval($name, "string"), "password" => new xmlrpcval($password, "string"), "event" => new xmlrpcval($text, "string"), "subject" => new xmlrpcval($subj, "string"), "lineendings" => new xmlrpcval("unix", "string"), "year" => new xmlrpcval($year, "int"), "mon" => new xmlrpcval($mon, "int"), "day" => new xmlrpcval($day, "int"), "hour" => new xmlrpcval($hour, "int"), "min" => new xmlrpcval($min, "int"), "ver" => new xmlrpcval(2, "int")); /* на основе массива создаем структуру */ $post2 = array(new xmlrpcval($post, "struct")); /* создаем XML сообщение для сервера */ $f = new xmlrpcmsg("LJ.XMLRPC.postevent", $post2); /* описываем сервер */ $c = new xmlrpc_client("/interface/xmlrpc", "www.livejournal.com", 80); $c->request_charset_encoding = "UTF-8"; /* по желанию смотрим на XML-код того что отправится на сервер */ echo nl2br(htmlentities($f->serialize())); /* отправляем XML сообщение на сервер */ $r = $c->send($f); /* анализируем результат */ if(!$r->faultCode()) { /* сообщение принято успешно и вернулся XML-результат */ $v = php_xmlrpc_decode($r->value()); print_r($v); } else { /* сервер вернул ошибку */ print "An error occurred: "; print "Code: ".htmlspecialchars($r->faultCode()); print "Reason: "".htmlspecialchars($r->faultString()).""\n"; } ?>

В данном примере рассмотрен только один метод LJ.XMLRPC.postevent - полный список возможных команд и их синтаксис (на английском языке) доступен по адресу:

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

На днях сайты моего хостинга, мягко говоря, — «прилегли». Было видно, что 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 Order Deny,Allow Deny from all

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

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

Order Allow,Deny Deny from 85.93.93.157 Allow from All

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

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

Order Deny,Allow #add your IP adresses Allow from 127.0.0.1 Allow from XX.XX.XX.XX ... Deny from all