Для начала вам потребуется скачать библиотеку XML-RPC. Наиболее удачной версией мне кажется свободно распространяемая через sourceforge " ": Все примеры ниже будут приведены для этой библиотеки версии 2.2.
Что же такое XML-RPC? RPC расшифровывается как Remote Procedure Call, соответственно на русский это можно перевести как удаленный вызов процедур с помощью XML. Сама методика удаленного вызова процедуры известна давно и используется в таких технологиях, как DCOM, SOAP, CORBA. RPC предназначен для построения распределенных клиент-серверных приложений. Это дает возможность строить приложения, которые работают в гетерогенных сетях, например, на компьютерах различных систем, производить удаленную обработку данных и управление удаленными приложениями. В частности этим протоколом пользуется хорошо известный в России сайт livejournal.com.
Рассмотрим пример, как можно разместить кириллическую запись (а именно с этим часто возникают
проблемы) в ЖЖ. Ниже приведен работающий код с комментариями:
/* ваш ник в ЖЖ */ $name = "xxxx"; /* ваш пароль в ЖЖ */ $password = "xxxx"; /* текст который вы хотите опубликовать */ $text = "Некоторый текст"; /* заголовок для текста */ $subj = "Некоторый заголовок"; /* включаем библиотеку XML-RPC */ include("lib/xmlrpc.inc"); /* (!!!) Все денные в ЖЖ хранятся в кодировке Unicode, используем и в нашем случае такую же кодировку */ $xmlrpc_internalencoding = "UTF-8"; /* Получаем текущее время */ $date = time(); $year = date("Y", $date); $mon = date("m", $date); $day = date("d", $date); $hour = date("G", $date); $min = date("i", $date); /* (!!!) Конвертируем текст из одной кодировки в UTF-8 в данном случае файл хранится в кодировке CP1251 */ $text = iconv("CP1251", "UTF-8", html_entity_decode($text)); $subj = iconv("CP1251", "UTF-8", html_entity_decode($subj)); /* заполняем массив с необходимыми переменными */ $post = array("username" => 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 сайтов.
Самое простое, что вы можете сделать в данной ситуации — удалить из корневой папки сайта файл /xmlrpc.php . Сервер не найдя скрипа, не будет запускать PHP, тратить ресурсы памяти и время процессора. Решение простое, но не красивое. Во-первых, кто то может пользоваться возможностями RPC. К примеру, публиковать записи на сайт через один из многих Weblog клиентов. А во-вторых, файл будет восстановлен после очередного обновления WP.
Если ваш сервер работает на Apache, то можно блокировать доступ к xmlrpc.php , не удаляя самого файла. Нужно добавить следующие инструкции в начало вашего .htaccess файла в корневой директории сайта на WordPress. Это заблокирует доступ к файлу с любых адресов.
# XML-RPC DDoS PROTECTION
# 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 > |
Но если вы пользуетесь RPC, то можно составить белый список адресов, которые имеют доступ к скрипту xmlrpc.php.
A demo xmlrpc debugger application, built on top of this library, is active at the address http://gggeek.altervista.org/sw/xmlrpc/debugger/ . You can use the debugger to e.g. query the SF demo server, or debug your own personal xmlrpc server, if it is accessible on the net.
Description | Status - updated 2009/07/26 |
---|---|
Update documentation for all features added since version 2 | Slowly progressing... |
Add the possibility to choose formatting of the xml messages | Similar to what the php native xmlrpc extension does |
Fix warnings emitted when running with PHP 5 in STRICT mode | Might have already been done in version 3.0, abandoning php 4 compat... |
Expand automatic php function to xmlrpc method wrapper to take advantage of exception handling and return xmlrpc error responses | |
Expand automatic stub generator for automatically converting php functions to xmlrpc methods for PHP <= 5.0.2 | look at AMFPHP code on how to do it. Many enhancements in version 2.1 Now that the server can automatically register php functions there is less need for it... |
Better support for mbstring when it"s enabled | Should make e.g. charset encoding guessing faster |
Improve support for "version 1" cookies | |
Add a possibility to use instead of the native error codes | |
PEAR compatibility: add synonyms for functions existing with different names in the PEAR version of the lib | |
Add support for the xmlrpc extension | |
Add to the debugger the capability to launch a complete set of validator1 tests | |
Examine usability of WSDL for describing exposed services and translation to/from system.methodSignature and system.describeMethods | Some problems exist in using an XSD to strictly define xmlrpc. Relax NG is a definitely better alternative, but there is little support in other toolkits for using it in conjunction with a WSDL file... |
Support http redirects (302) | |
Add to sf.net a small database, so that we can implement a validator page that logs incoming users, such as is present on the xmlrpc.com site | |
Add to benchmark suite the capability to upload results to sf.net | |
Write a php extension that will accelerate the most heavily used functions of the lib | See how adodb did it for an example |
Test speed/memory gains using simplexml and relaxng instead of hand parsing of xml |
This was a further and proactive response to the second security breach below. All use of eval() has been removed since it was still a potential exploit.
When the library was originally written, the versions of php available at the time did not include call_user_func(), et al. So it was written within those constraints to use eval() in two of the functions called by the xml parser. Due to this usage, the server class also used eval() since it had to parse xml using the same functions.
These handler functions, and the array used to maintain the content of the original message, have been rewritten to construct php values instead of building php code for evaluation. This should remove any potential for code execution.
The security vulnerability discovered by James Bercegay of GulfTech Security Research on the the 27th of June, 2005, has caused quite a stir. It has made it to the front page of Salshdot, has been mentioned on Netcraft, LWN and many other sites.
Detailed instructions on building exploit code have been released on the internet, and many web hosting administrators are left wondering what is the best defense plan, and what are the real risks. Here are some answers.
This makes it unfortunately a lot harder for sysadmins to find an easy cure for the problem: there is a great chance that on public hosting servers the aforementioned files will be found in many different directories and in many different versions.
Несколько дней назад я заметил, что нагрузка моих сайтов на хостинг выросла в разы. Если обычно она составляла в районе 100-120 "попугаев" (CP), то за последние несколько дней она возросла до 400-500 CP. Ничего хорошего в этом нет, ведь хостер может перевести на более дорогой тариф, а то и вовсе прикрыть доступ к сайтам, поэтому я начал разбираться.
Но я выбрал метод, который позволит сохранить функциональность 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 сторонние сайты.