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

Като разбрах се оказа, че има търсене на пароли + много заявки към XMLRPC.

В резултат на това беше възможно да се отреже всичко, макар и не веднага. От котка три прост приемкак да го избегнем.

Тези техники най-вероятно са известни на всички, но стъпих на няколко гребла, които не намерих в описанията - изведнъж това ще спести на някого време.

1. Спираме изброяването, приставката за ограничаване на опитите за влизане - поставяме го точно, тъй като други защити силно задържат сървъра, например при използване Плъгин ВходСървърът на Security Solution умря за половин час, плъгинът натоварва силно базата данни.

В настройките не забравяйте да поставите отметка в квадратчето "За прокси" - в противен случай ще определи ip на вашия сървър за всички и автоматично ще блокира всички.
АКТУАЛИЗАЦИЯ, благодаря, подробностите са по-долу в коментарите - поставяме отметка в квадратчето „За прокси“ само ако дефиницията не работи, когато е активирана „Директна връзка“

2. Деактивирайте XML-RPC - плъгин Деактивирайте XML-RPC (просто го активирайте и това е).

3. Затворете wp-login.php - ако влезете в сайта през ip, плъгинът не работи и пикерите продължават да чукат сайта. За да избегнете това, добавете към .htaccess:

Отказ на поръчка, Разрешаване на отказ от всички

Копираме файла wp-login, преименуваме го на всяко странно име, например poletnormalny.php и вътре във файла променяме всички надписи wp-login.php на poletnormalny.php чрез автокорекция.
Всичко, сега можете да получите достъп до админ панела само чрез вашия файл.

След тези 3 лесни стъпки, сайтовете започнаха да летят отново и настъпи мир.

Е, изведнъж стана интересно

Един от вариантите е как да видите, че сте атакуван. Това може да се види в регистрационните файлове на nginx (например, тук е пътя за файла /var/log/nginx access.log на Debian).

Въведение в 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
Потребителски агент: eshop-test/1.1.1 (FreeBSD)
Хост: server.localnet.com
Тип съдържание: текст/xml
дължина на съдържанието: 172

Метод на тестване
Здравей XML-RPC!

Първите редове формират стандартната HTTP POST заглавка на заявката. Задължителните параметри включват хост, тип данни (тип MIME), който трябва да е текст/xml, и дължината на съобщението. Стандартът също така посочва, че полето User-Agent трябва да бъде попълнено, но може да съдържа произволна стойност.

Следва нормалната заглавка на XML документа. Основен елемент на заявката - , може да има само един и не може да съдържа такива възли като деца. Това означава, че само един метод на сървъра може да бъде извикан на заявка.

Линия Метод на тестванепоказва, че извикваме метод с име TestMetod. Ако е необходимо, тук можете да посочите името на програмата или модула, съдържащи метода, както и пътя до него. Въпреки че спецификацията на XML-RPC налага някои ограничения върху набора от знаци, които могат да се използват за обозначаване на метод, начинът за тяхното интерпретиране зависи изцяло от изпълнението на сървъра.

След това се задават предадените параметри. За това секцията Което може да съдържа произволен брой поделементи Които съдържат параметъра, описан от тага . Ще разгледаме параметрите и типовете данни малко по-нататък. В нашата версия на метода се предава един низов параметър, затворен в тага .

След описанието на всички параметри следват затварящи тагове. Заявка и отговор в XML-RPC са нормални XML документи, така че всички тагове трябва да бъдат затворени. Но в XML-RPC няма единични тагове, въпреки че те присъстват в XML стандарта.

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

Тялото на отговора е следното:

вярно

Сега вместо основния маркер етикет е посочен , който веднага съдържа резултатите от обработката на заявката. За съжаление, името на метода не се предава в отговора, така че трябва да го съхраните от страна на клиента, за да избегнете объркване, ако различни методи се извикат едновременно.

Ако е възникнала грешка при обработката на вашата заявка, вместо Отговорът ще има елемент , в който ще бъде вложена структурата, описваща грешката. Описанието на грешката съдържа цифров код на грешката и текстово описание на грешката.

Сега нека да разгледаме набързо типовете данни в XML-RPC. Има общо 9 типа данни - седем прости типа и 2 сложни. Всеки тип се описва със собствен етикет или набор от тагове (за сложни типове).

Прости видове:

Цели числа- етикет или ;

булев тип- етикет , може да приема както стойности 0/1, така и true/false;

ASCII низ- описано от етикет и може да съдържа произволен низ от знаци;

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

дата и час- описано от етикет и трябва да отговаря на формата iso8601. За по-нататъшна обработка в скриптове този формат е малко неудобен, така че винаги се конвертира при изпращане / получаване на заявка. Това може да стане чрез специална функция в библиотеката или ако няма такава, разработчикът трябва да конвертира датата ръчно.

Последният прост тип е base64 кодиран низ, което е описано от тага . Този тип е универсален, може да се използва за прехвърляне на всякакви данни между клиента и сървъра, въпреки че количеството прехвърлени данни поради това кодиране се увеличава. Но това е следствие от текстовия характер на протокола и XML форматпо-специално.

Сложните типове са представени от структури и масиви. Структура, дефинирана от коренния елемент , който може да съдържа произволен брой елементи , дефиниращ всеки член на структурата. Членът на структурата се описва с два тагова: първият, , описва името на члена, второ, , съдържа стойността на члена (заедно с таг, който описва типа данни).

Масивите нямат имена и се описват с таг , който съдържа един елемент и един или повече дъщерни елементи , където са посочени конкретни данни. Един масив може да съдържа всякакви други типове в произволен ред, както и други масиви, което ви позволява да описвате многомерни масиви. Можете също така да опишете масив от структури. Но фактът, че масивът няма име, усложнява използването му в някои случаи; за да прехвърлите сложни данни, те трябва многократно да бъдат опаковани в други типове (например, за да прехвърлите няколко масива, можете отделно да опаковате всеки масив в структура и след това създайте един масив от тези структури).

Разбира се, някой ще каже, че такъв списък от типове данни е много лош и „не ви позволява да се разширявате“. Да, ако трябва да прехвърлите сложни обекти или големи количества данни, тогава е по-добре да използвате SOAP. И за малки, неизискващи приложения XML-RPC е доста подходящ, освен това много често дори неговите възможности се оказват твърде много! Като се има предвид лекотата на внедряване, много голям брой библиотеки за почти всеки език и платформа и широка поддръжка в PHP, тогава XML-RPC често просто няма конкуренти. Въпреки че е невъзможно веднага да се препоръча като универсално решение - във всеки случай е необходимо да се реши според обстоятелствата.

Технологията XML-RPC се използва в системата WordPress за различни приятни функции като pingbacks, trackbacks, отдалечено управление на сайт без влизане в административната зона и т.н. За съжаление, нападателите могат да го използват за 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 на темата се добавя ред:

Отказ на поръчка, Разрешаване на отказ от всички

Аз лично не използвах последните два метода, т.к. Свързах плъгина Disable XML-RPC Pingback - мисля, че ще е достатъчно. Само за тези, които не харесват допълнителни настройки, предложих алтернативни опции.