Соревнования по программированию. Соревнования по программированию Отключение XML-RPC в шаблоне

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

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

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

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

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

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

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 несложных шагов сайты опять начали летать и пришло спокойствие.

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

Введение в XML-RPC

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

Реальный пример: страница банковского сайта, на которой показываются котировки валют. Если вы заходите на страницу как обычный пользователь, через браузер, вы видите все оформление страницы, баннеры, меню и другую информацию, которая "обрамляет" истинную цель поиска - котировки валют. Если вам надо вносить эти котировки в свой интернет-магазин, то ничего другого не останется, как только вручную выделить нужные данные и через буфер обмена перенести на свой сайт. И так придется делать каждый день. Неужели нет выхода?

Если решать проблему "в лоб", то сразу напрашивается решение: программа (скрипт на сайте), которой надо данные, получает страницу от сервера как "обычный пользователь", разбирает (парсит) полученный html-код и выделяет из него нужную информацию. Это можно сделать или обычным регулярным выражением, или при помощи любого html-парсера. Сложность подхода - в его неэфективности. Во-первых, для получения небольшой порции данных (данные о валютах - это буквально десяток-другой символов) надо получать всю страницу, а это не менее нескольких десятков килобайт. Во-вторых, при любом изменении кода страницы, к примеру, дизайн поменялся или что-то еще, наш алгоритм разбора придется переделывать. Да и ресурсов это будет отбирать порядочно.

Поэтому разработчики пришли к решению - надо разработать какой-то универсальный механизм, который бы позволил прозрачно (на уровне протокола и среды передачи) и легко обмениваться данными между программами, которые могут находиться где угодно, быть написанными на любом языке и работать под управлением любой операционной системы и на любой аппаратной платформе. Такой механизм называют сейчас громкими терминами "Веб-сервисы" (web-service), "SOAP", "архитектура, ориентированная на сервисы" (service-oriented architecture). Для обмена данными используются открытые и проверенные временем стандарты - для передачи сообщений протокол HTTP (хотя можно использовать и другие протоколы - SMTP к примеру). Сами данные (в нашем примере - курсы валют) передаются упакованными в кросс-платформенный формат - в виде XML-документов. Для этого придуман специальный стандарт - SOAP.

Да, сейчас веб-сервисы, SOAP и XML у всех на слуху, их начинают активно внедрять и крупные корпорации вроде IBM и Microsoft выпускают новые продукты, призванные помочь тотальному внедрению веб-сервисов.

Но! Для нашего примера с курсами валют, которые должны передаваться с сайта банка в движок интернет-магазина такое решение будет очень сложным. Ведь только описание стандарта SOAP занимает неприличные полторы тысячи страниц, и это еще не все. Для практического использования придется изучить еще работу со сторонними библиотеками и расширениями (только начиная с PHP 5.0 в него входит библиотека для работы с SOAP), написать сотни и тысячи строк своего кода. И все это для получения нескольких букв и цифр - явно очень тяжеловесно и нерационально.

Потому существует еще один, с натяжкой можно сказать альтернативный стандарт на обмен информацией - XML-RPC. Он был разработан при участии Microsoft компанией UserLand Software Inc и предназначен для унифицированной передачи данных между приложениями через Интернет. Он может заменить SOAP при построении простых сервисов, где не надо все "корпоративные" возможности настоящих веб-сервисов.

Что же означает аббревиатура XML-RPC? RPC расшифровывается как Remote Procedure Call - удаленный вызов процедур. Это значит, что приложение (неважно, скрипт на сервере или обычное приложение на клиентском компьютере) может прозрачно использовать метод, который физически реализован и исполняется на другом компьютере. XML тут применяется для обеспечения универсального формата описания передаваемых данных. Как транспорт, для передачи сообщений применяется протокол HTTP, что позволяет беспрепятственно обмениваться данными через любые сетевые устройства - маршрутизаторы, фаерволы, прокси-сервера.

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

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

Процедура работы с XML-RPC начинается с формирования запроса. Типичный запрос выглядит так:

POST /RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172

TestMetod
Привет, XML-RPC!

В первых строках формируется стандартный заголовок HTTP запроса POST. К обязательным параметрам относятся host, тип данных (MIME-тип), который должен быть text/xml, а также длина сообщения. Также в стандарте указывается, что поле User-Agent должно быть заполнено, но может содержать произвольное значение.

Далее идет обычный заголовок XML-документа. Корневой элемент запроса - , может быть только один, и не может содержать таких узлов в качестве дочерних. Это означает, что одним запросом можно вызвать только один метод на сервере.

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

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

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

Tеперь разберем ответ сервера. Заголовок HTTP ответа обычный, если запрос успешно обработан, то сервер возвращает ответ HTTP/1.1 200 OK. Также как в запросе, следует корректно указать MIME-тип, длину сообщения и дату формирования ответа.

Само тело ответа следующее:

true

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

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

А теперь рассмотрим кратко типы данных в XML-RPC. Всего типов данных есть 9 - семь простых типов и 2 сложных. Каждый тип описывается своим тегом или набором тегов (для сложных типов).

Простые типы:

Целые числа - тег или ;

Логический тип - тег , может принимать как значения 0/1, так и true/false;

ASCII-строка - описывается тегом и может содержать произвольную строку символов;

Числа с плавающей точкой - тег , могут также содержать знак числа, дробная часть отделяется точкой;

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

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

Сложные типы представлены структурами и массивами. Структура определяется корневым элементом , который может содержать произвольное количество элементов , определяющих каждый член структуры. Член структуры описывается двумя тегами: первый, , описывает имя члена, второй, , содержит значение члена (вместе с тегом, описывающим тип данных).

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

Конечно, кто-то скажет, что такой перечень типов данных очень беден и "не позволяет развернуться". Да, если надо передавать сложные объекты, или большие объемы данных, то лучше использовать SOAP. А для небольших, нетребовательных приложений вполне подходит и XML-RPC, более того, очень часто даже его возможностей оказывается слишком много! Если учесть легкость развертывания, очень большое количество библиотек для почти любых языков и платформ, широкую поддержку в PHP, то XML-RPC часто просто не имеет конкурентов. Хотя сразу советовать его в качестве универсального решения нельзя - в каждом конкретном случае надо решать по обстоятельствах.

Каждый у кого есть свой веб-сайт хочет повысить его безопасность, если нет, то хочет чтобы он был всегда в безопасности... Собственно в этой статье мы и разберем принципы и основы защиты движка 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 применяется в системе WordPress для разных приятных фишек по типу пингбэков, трекбеков, удаленного управления сайтом без входа в админку и т.п. К сожалению, злоумышленники могут использовать ее для DDoS атаки на сайты. То есть вы создаете красивые интересные WP проекты для себя или на заказ и при этом, ничего не подозревая, можете быть частью ботнета для DDoS`а. Соединяя воедино десятки и сотни тысяч площадок, нехорошие люди создают мощнейшую атаку на свою жертву. Хотя при этом ваш сайт также страдает, т.к. нагрузка идет на хостинг, где он размещен.

Свидетельством такой нехорошей активности могут быть логи сервера (access.log в nginx), содержащие следующие строки:

103.238.80.27 - - «POST /wp-login.php HTTP/1.0» 200 5791 "-" "-"

Но вернемся к уязвимости XML-RPC. Визуально она проявляется в медленном открытии сайтов на вашем сервере или же невозможностью их загрузки вообще (502 ошибка Bad Gateway). В тех.поддержке моего хостера FASTVPS подтвердили догадки и посоветовали:

1. Обновить WordPress до последней версии вместе с плагинами. Вообще, если вы следите за , то могли читать о необходимости установки последней 4.2.3. из-за критических замечаний в безопасности (точно также как предыдущих версий). Короче говоря, обновляться полезно.

1. Установить плагин Disable XML-RPC Pingback.

Отключение XML-RPC в WordPress

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

Найти и скачать Disable XML-RPC Pingback либо установив его непосредственно из админки системы. Вам не нужно ничего дополнительно настраивать, модуль сразу же начинает работать. Он удаляет методы pingback.ping и pingback.extensions.getPingbacks из XML-RPC интерфейса. Кроме того, удаляет X-Pingback из HTTP заголовков.

В одном из блогов нашел еще парочку вариантов удаления отключения XML-RPC.

1. Отключение XML-RPC в шаблоне.

Для этого в файл функций темы functions.php добавляется строка:

Order Deny,Allow Deny from all

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

Несколько дней назад я заметил, что нагрузка моих сайтов на хостинг выросла в разы. Если обычно она составляла в районе 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 сторонние сайты.