Od sobotního odpoledne na mém serveru, který hostí asi 25 stránek na Wordpressu, začaly divoké brzdy. Vzhledem k tomu, že se mi podařilo přežít předchozí útoky ( , ) bez povšimnutí, hned jsem nepochopil, co je špatně.

Když jsem na to přišel, ukázalo se, že tam bylo hledání hesel + spousta požadavků na XMLRPC.

Díky tomu bylo možné to všechno utnout, i když ne hned. Od kočky tři jednoduchý příjem jak se tomu vyhnout.

Tyto techniky nejspíš zná každý, ale já jsem šlápl na pár hrábí, které jsem v popisech nenašel – najednou to někomu ušetří čas.

1. Zastavíme výčet, plugin Limit Login Attempts - vyjádříme to přesně, protože jiné ochrany značně visí na serveru, například při použití Přihlášení do pluginu Server Security Solution za půl hodiny zemřel, plugin silně zatěžuje databázi.

V nastavení nezapomeňte zaškrtnout políčko "Pro proxy" - jinak určí IP vašeho serveru pro všechny a automaticky všechny zablokuje.
AKTUALIZACE, díky, podrobnosti jsou níže v komentářích - zaškrtávací políčko „Pro proxy“ aktivujeme pouze v případě, že definice nefunguje, když je povoleno „Přímé připojení“

2. Zakázat XML-RPC - plugin Zakázat XML-RPC (stačí aktivovat a je to).

3. Zavřete wp-login.php – pokud na stránky přistupujete přes ip, plugin nefunguje a výběrčí pokračuje v zatloukání webu. Chcete-li se tomu vyhnout, přidejte do .htaccess:

Objednejte Deny, povolte Deny od všech

Soubor wp-login zkopírujeme, přejmenujeme na libovolný divný název, například poletnormalny.php a uvnitř souboru změníme pomocí autokorekce všechny nápisy wp-login.php na poletnormalny.php.
Vše, nyní máte přístup k panelu administrátora pouze pomocí svého souboru.

Po těchto 3 jednoduchých krocích začaly lokality opět létat a nastal klid.

No, najednou je to zajímavé

Jednou z možností je, jak vidět, že jste napadeni. To lze vidět v protokolech nginx (například zde je cesta k souboru Debian /var/log/nginx access.log).

Úvod do XML-RPC

Na webu existuje mnoho různých zdrojů, které uživatelům poskytují určité informace. Nemyslí se tím běžné statické stránky, ale například data získaná z databáze nebo archivů. Může se jednat o archiv finančních dat (kurzy měn, údaje o kurzech akcií), údaje o počasí nebo objemnější informace – novinky, články, zprávy z fór. Takové informace mohou být poskytnuty návštěvníkovi stránky například prostřednictvím formuláře, jako odpověď na požadavek, nebo mohou být pokaždé dynamicky generovány. Potíž je ale v tom, že často takové informace nepotřebuje ani tak koncový uživatel – člověk, ale jiné systémy, programy, které tato data využijí pro své výpočty nebo jiné potřeby.

Příklad ze skutečného života: stránka na bankovním webu, která zobrazuje kotace měn. Pokud na stránku vstoupíte jako běžný uživatel, prostřednictvím prohlížeče vidíte veškerý design stránky, bannery, menu a další informace, které „rámují“ skutečný účel vyhledávání – kotace měn. Pokud potřebujete tyto citace zadat do svého internetového obchodu, nezbývá nic jiného, ​​než potřebné údaje ručně vybrat a přes schránku přenést na váš web. A musíte to dělat každý den. Opravdu neexistuje žádná cesta ven?

Pokud problém vyřešíme přímo, pak se řešení okamžitě navrhne: program (skript na webu), který potřebuje data, přijme stránku ze serveru jako „běžný uživatel“, analyzuje (analyzuje) přijatý html kód a extrahuje potřebné informace z něj. Dá se to udělat nebo normálně regulární výraz nebo pomocí libovolného html analyzátoru. Složitost přístupu spočívá v jeho neefektivnosti. Nejprve, abyste získali malou část dat (údaje o měnách jsou doslova tucet nebo dva znaky), musíte získat celou stránku, která má alespoň několik desítek kilobajtů. Za druhé, s jakoukoli změnou v kódu stránky, například se změnil design nebo něco jiného, ​​bude muset být přepracován náš algoritmus analýzy. Ano a bude to slušně vybírat zdroje.

Proto vývojáři dospěli k rozhodnutí - je nutné vyvinout nějaký univerzální mechanismus, který by umožnil transparentní (na úrovni protokolu i přenosového média) a snadnou výměnu dat mezi programy, které mohou být umístěny kdekoli, být napsány v jakémkoli jazyce a spustit pod jakýmkoli operační systém a na jakékoli hardwarové platformě. Takový mechanismus se nyní nazývá vysoce profilovanými pojmy „webové služby“ (webová služba), „SOAP“, „architektura orientovaná na služby“ (architektura orientovaná na služby). Pro výměnu dat se používají otevřené a časem prověřené standardy - pro přenos zpráv protokol HTTP (lze však použít i jiné protokoly - např. SMTP). Samotná data (v našem příkladu - směnné kurzy) jsou přenášena zabalená v multiplatformním formátu - ve formě XML dokumentů. K tomu byl vynalezen speciální standard – SOAP.

Ano, nyní jsou webové služby, SOAP a XML na rtech, začínají se aktivně implementovat a velké korporace jako IBM a Microsoft uvolňují nové produkty, které mají pomoci celkové implementaci webových služeb.

Ale! Pro náš příklad se směnnými kurzy, které je nutné přenést z webu banky do motoru internetového obchodu, bude takové řešení velmi obtížné. Vždyť jen popis standardu SOAP zabere neslušných jeden a půl tisíce stran a to není vše. Pro praktické použití se také budete muset naučit pracovat s knihovnami a rozšířeními třetích stran (až od PHP 5.0 obsahuje knihovnu pro práci se SOAP), psát stovky a tisíce řádků svého kódu. A to vše získat pár písmen a číslic je samozřejmě velmi těžké a iracionální.

Proto existuje ještě jeden, s úsekem, můžeme říci alternativní standard pro výměnu informací - XML-RPC. Byl vyvinut za účasti společnosti Microsoft společností UserLand Software Inc a je určen pro jednotný přenos dat mezi aplikacemi přes internet. Může nahradit SOAP při budování jednoduchých služeb, kde nejsou potřeba všechny „podnikové“ funkce skutečných webových služeb.

Co znamená zkratka XML-RPC? RPC je zkratka pro Remote Procedure Call - vzdálené volání procedur. To znamená, že aplikace (ať už skript na serveru nebo běžná aplikace na klientský počítač) může transparentně používat metodu, která je fyzicky implementována a spuštěna na jiném počítači. XML je zde použito k poskytnutí univerzálního formátu pro popis přenášených dat. Jako transport se k přenosu zpráv používá protokol HTTP, který vám umožňuje libovolně vyměňovat data prostřednictvím libovolných síťových zařízení - routerů, firewallů, proxy serverů.

Abyste jej mohli používat, potřebujete: server XML-RPC, který poskytuje jednu nebo více metod, klienta XML-RPC, který dokáže vytvořit správný požadavek a zpracovat odpověď serveru, a také znát parametry serveru nezbytné pro úspěšné operace - adresa, název metody a předané parametry.

Veškerá práce s XML-RPC probíhá v režimu „request-response“, což je jeden z rozdílů mezi technologií a standardem SOAP, kde jsou jak koncepty transakcí, tak možnost provádět odložené hovory (když server uloží požadavek a odpoví na něj v určitou dobu v budoucnu). Tyto další funkce užitečnější pro výkonné podnikové služby, značně komplikují vývoj a podporu serverů a kladou další požadavky na vývojáře klientských řešení.

Postup pro práci s XML-RPC začíná vytvořením požadavku. Typický požadavek vypadá takto:

POST/RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Hostitel: server.localnet.com
Content-Type: text/xml
Délka obsahu: 172

Testovací metoda
Ahoj XML-RPC!

První řádky tvoří standardní hlavičku HTTP POST požadavku. Mezi požadované parametry patří hostitel, datový typ (typ MIME), který musí být text/xml, a délka zprávy. Norma také uvádí, že pole User-Agent musí být vyplněno, ale může obsahovat libovolnou hodnotu.

Následuje normální záhlaví dokumentu XML. Kořenový prvek požadavku - , může být pouze jeden a nemůže obsahovat takové uzly jako děti. To znamená, že na jeden požadavek lze volat pouze jednu metodu na serveru.

Čára Testovací metoda označuje, že voláme metodu s názvem TestMetod. V případě potřeby zde můžete zadat název programu nebo modulu obsahujícího metodu a také cestu k ní. Ačkoli specifikace XML-RPC ukládá určitá omezení na sadu znaků, které lze použít k označení metody, způsob jejich interpretace zcela závisí na implementaci serveru.

Dále se nastaví předané parametry. K tomu oddíl Který může obsahovat libovolný počet dílčích prvků Které obsahují parametr popsaný tagem . Na parametry a datové typy se podíváme trochu dále. V naší verzi je metodě předán jeden parametr řetězce, uzavřený ve značce .

Po popisu všech parametrů následují uzavírací značky. Požadavek a odpověď v XML-RPC jsou normální dokumenty XML, takže všechny značky musí být uzavřeny. V XML-RPC však neexistují žádné jednotlivé značky, ačkoli jsou přítomny ve standardu XML.

Nyní pojďme analyzovat odezvu serveru. Hlavička odpovědi HTTP je normální, pokud je požadavek úspěšně zpracován, server vrátí odpověď HTTP/1.1 200 OK. Stejně jako v požadavku byste měli správně zadat typ MIME, délku zprávy a datum vygenerování odpovědi.

Tělo odpovědi je následující:

skutečný

Nyní místo kořenové značky je označena značka , která ihned obsahuje výsledky vyřízení žádosti. Bohužel název metody není v odpovědi předán, takže byste jej měli uložit na straně klienta, abyste předešli zmatkům, pokud jsou současně volány různé metody.

Pokud při zpracování vašeho požadavku došlo k chybě, místo toho Odpověď bude mít prvek , ve kterém bude vnořena struktura popisující chybu. Popis chyby obsahuje číselný kód chyby a textový popis chyby.

Nyní se pojďme rychle podívat na datové typy v XML-RPC. Datových typů je celkem 9 – sedm jednoduchých typů a 2 komplexní. Každý typ je popsán vlastní značkou nebo sadou značek (u komplexních typů).

Jednoduché typy:

Celá čísla- tag nebo ;

booleovský typ- tag , může nabývat hodnot 0/1 i true/false;

ASCII řetězec- popsané tagem a může obsahovat libovolný řetězec znaků;

Čísla s pohyblivou řádovou čárkou- tag , může také obsahovat znaménko čísla, zlomek oddělené tečkou;

datum a čas- popsané tagem a musí odpovídat formátu iso8601. Pro další zpracování ve skriptech je tento formát trochu nepohodlný, proto se vždy při odesílání / přijímání požadavku převádí. To lze provést speciální funkcí v knihovně, nebo pokud žádná není, musí vývojář datum převést ručně.

Posledním jednoduchým typem je base64 kódovaný řetězec, který je popsán tagem . Tento typ je univerzální, lze jej použít pro přenos libovolných dat mezi klientem a serverem, i když objem přenesených dat díky tomuto kódování narůstá. Ale to je důsledek textové povahy protokolu a XML formát zejména.

Komplexní typy jsou reprezentovány strukturami a poli. Struktura definovaná kořenovým prvkem , který může obsahovat libovolný počet prvků , definující každý člen struktury. Člen struktury je popsán dvěma značkami: první, , popisuje jméno člena, za druhé, , obsahuje hodnotu člena (spolu s tagem, který popisuje datový typ).

Pole nemají žádná jména a jsou popsána tagem , který obsahuje jeden prvek a jeden nebo více podřízených prvků , kde jsou uvedeny konkrétní údaje. Pole může obsahovat jakékoli další typy v libovolném pořadí, stejně jako další pole, což umožňuje popisovat vícerozměrná pole. Můžete také popsat řadu struktur. Ale fakt, že pole nemá jméno, v některých případech komplikuje jeho použití, pro přenos složitých dat je třeba je opakovaně balit do jiných typů (např. pro přenos více polí můžete každé pole samostatně zabalit do struktury a poté z těchto struktur vytvořte jedno pole).

Někdo samozřejmě řekne, že takový seznam datových typů je velmi chudý a „neumožňuje rozšiřovat“. Ano, pokud potřebujete přenášet složité objekty nebo velké množství dat, pak je lepší použít SOAP. A pro malé nenáročné aplikace se XML-RPC docela hodí, navíc se velmi často i jeho schopnosti ukáží jako příliš! Vzhledem k snadnému nasazení, velkému počtu knihoven pro téměř jakýkoli jazyk a platformu a rozsáhlé podpoře v PHP pak XML-RPC často jednoduše nemá konkurenci. I když to nelze hned radit jako univerzální řešení - v každém případě je třeba se rozhodnout podle okolností.

Technologie XML-RPC se v systému WordPress používá pro různé pěkné funkce, jako jsou pingbacky, trackbacky, vzdálená správa stránek bez přihlášení do administrační oblasti atd. Útočníci jej bohužel mohou využít k DDoS útokům na webové stránky. To znamená, že vytváříte krásné zajímavé WP projekty pro sebe nebo na zakázku a zároveň, aniž byste cokoli tušili, můžete být součástí DDoS botnetu. Spojením desítek a stovek tisíc stránek vytvářejí špatní lidé silný útok na svou oběť. I když vaše stránky také trpí, protože. zátěž jde na hosting, kde je hostována.

Důkazem takové špatné činnosti mohou být protokoly serveru (access.log v nginx) obsahující následující řádky:

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

Ale zpět k zranitelnosti XML-RPC. Vizuálně se to projevuje pomalým otevíráním stránek na vašem serveru nebo nemožností je vůbec načíst (chyba 502 Bad Gateway). Technická podpora mého hostitele FASTVPS potvrdila mé odhady a doporučila:

1. Aktualizujte WordPress na Nejnovější verze spolu s pluginy. Obecně, pokud se budete řídit, možná jste četli o nutnosti nainstalovat nejnovější verzi 4.2.3. kvůli bezpečnostní kritice (stejně jako předchozí verze). Zkrátka aktualizace je dobrá.

1. Nainstalujte plugin Zakázat XML-RPC Pingback.

Zakázání XML-RPC ve WordPressu

Dříve se mi zdá, že možnost povolit / zakázat XML-RPC byla někde v nastavení systému, ale teď ji tam nemůžu najít. Nejjednodušší způsob, jak se toho zbavit, je proto použít příslušný plugin.

Najděte a stáhněte si Disable XML-RPC Pingback nebo jej nainstalujte přímo z panelu správce systému. Nemusíte nic dodatečně konfigurovat, modul začne fungovat okamžitě. Odstraňuje metody pingback.ping a pingback.extensions.getPingbacks z rozhraní XML-RPC. Také odstraňuje X-Pingback z HTTP hlaviček.

V jednom z blogů jsem našel několik dalších možností, jak odstranit zakázání XML-RPC.

1. Zakažte XML-RPC v šabloně.

Za tímto účelem je do souboru functions.php motivu přidán řádek:

Objednejte Deny, povolte Deny od všech

Poslední dvě metody jsem osobně nepoužil, protože. Připojil jsem plugin Disable XML-RPC Pingback - myslím, že to bude stačit. Právě pro ty, kteří nemají rádi extra nastavení, jsem nabídl alternativní možnosti.