Od sobotniego popołudnia na moim serwerze, na którym znajduje się około 25 stron na Wordpress, zaczęły się dzikie przerwy. Ponieważ udało mi się przetrwać poprzednie ataki ( , ) bez zauważenia, nie od razu zrozumiałem, co jest nie tak.

Kiedy się domyśliłem, okazało się, że jest poszukiwanie haseł + dużo próśb do XMLRPC.

W efekcie udało się to wszystko odciąć, choć nie od razu. Przez kota trzy prosty odbiór jak tego uniknąć.

Te techniki są najprawdopodobniej znane wszystkim, ale nadepnąłem na kilka grabi, których nie znalazłem w opisach - nagle zaoszczędzi to komuś czas.

1. Zatrzymujemy enumerację, wtyczkę Limit Login Attempts - ujmujemy dokładnie, ponieważ inne zabezpieczenia mocno zawieszają serwer np. podczas używania Logowanie do wtyczki Serwer Security Solution zgasł w pół godziny, wtyczka mocno ładuje bazę danych.

W ustawieniach upewnij się, że zaznaczyłeś pole wyboru "Dla proxy" - w przeciwnym razie określi IP twojego serwera dla wszystkich i automatycznie zablokuje wszystkich.
AKTUALIZACJA, dzięki, szczegóły poniżej w komentarzach - włączamy checkbox „Dla proxy” tylko wtedy, gdy definicja nie działa, gdy włączone jest „Połączenie bezpośrednie”

2. Wyłącz XML-RPC - wtyczka Wyłącz XML-RPC (po prostu aktywuj i to wszystko).

3. Zamknij wp-login.php - jeśli uzyskujesz dostęp do witryny przez ip, wtyczka nie działa, a zbieracze nadal wbijają się w witrynę. Aby tego uniknąć, dodaj do .htaccess:

Zamów odmowę, zezwól na odmowę ze wszystkich

Kopiujemy plik wp-login, zmieniamy jego nazwę na dowolną dziwną nazwę, na przykład poletnormalny.php i wewnątrz pliku zmieniamy wszystkie napisy wp-login.php na poletnormalny.php przez autokorektę.
Wszystko, teraz masz dostęp do panelu administracyjnego tylko przez swój plik.

Po tych 3 prostych krokach strony znów zaczęły latać i nastał pokój.

No, nagle jest ciekawie

Jedną z opcji jest to, jak zobaczyć, że jesteś atakowany. Można to zobaczyć w logach nginx (na przykład tutaj jest ścieżka do pliku Debian /var/log/nginx access.log).

Wprowadzenie do XML-RPC

Istnieje wiele różnych zasobów w sieci Web, które dostarczają użytkownikom pewnych informacji. Nie chodzi tu o zwykłe strony statyczne, ale np. o dane pobrane z bazy danych lub archiwów. Może to być archiwum danych finansowych (kursy walut, dane o notowaniach papierów wartościowych), dane pogodowe lub bardziej obszerne informacje - newsy, artykuły, wiadomości z forów. Takie informacje mogą być prezentowane odwiedzającemu stronę np. poprzez formularz, jako odpowiedź na zapytanie, lub mogą być każdorazowo dynamicznie generowane. Ale trudność polega na tym, że często takie informacje są potrzebne nie tyle użytkownikowi końcowemu - osobie, ale innym systemom, programom, które będą wykorzystywać te dane do swoich obliczeń lub innych potrzeb.

Przykład z życia: strona w witrynie bankowej, która wyświetla notowania walut. Jeśli wchodzisz na stronę jako zwykły użytkownik, za pośrednictwem przeglądarki widzisz cały projekt strony, banery, menu i inne informacje, które „oprawiają” prawdziwy cel wyszukiwania - notowania walut. Jeśli musisz wprowadzić te cytaty do swojego sklepu internetowego, nie pozostaje nic innego, jak ręcznie wybrać potrzebne dane i przenieść je na swoją stronę internetową za pomocą schowka. I musisz to robić codziennie. Czy naprawdę nie ma wyjścia?

Jeśli rozwiążemy problem czołowo, to rozwiązanie natychmiast sugeruje samo: program (skrypt na stronie), który potrzebuje danych, otrzymuje stronę z serwera jako „zwykły użytkownik”, parsuje (parsuje) otrzymany kod html i wyodrębnia niezbędne informacje z niego. Można to zrobić lub normalnie Wyrażenie regularne lub za pomocą dowolnego parsera html. Złożoność podejścia polega na jego nieefektywności. Po pierwsze, aby uzyskać niewielką porcję danych (dane o walutach to dosłownie kilkanaście lub dwa znaki), trzeba pobrać całą stronę, czyli co najmniej kilkadziesiąt kilobajtów. Po drugie, przy każdej zmianie w kodzie strony, na przykład zmianie wyglądu lub czegoś innego, nasz algorytm parsowania będzie musiał zostać przerobiony. Tak, i przyzwoicie dobierze zasoby.

Dlatego twórcy podjęli decyzję – konieczne jest opracowanie pewnego rodzaju uniwersalnego mechanizmu, który pozwoli na przejrzystą (na poziomie protokołu i medium transmisyjnego) i łatwą wymianę danych między programami, które mogą znajdować się w dowolnym miejscu, być napisane w dowolnym języku i biegnij pod jakimkolwiek system operacyjny i na dowolnej platformie sprzętowej. Taki mechanizm jest obecnie nazywany głośnymi terminami „usługi sieciowe” (usługa internetowa), „SOAP”, „architektura zorientowana na usługi” (architektura zorientowana na usługi). Do wymiany danych wykorzystywane są otwarte i sprawdzone w czasie standardy – do przesyłania wiadomości używany jest protokół HTTP (choć można stosować inne protokoły – np. SMTP). Same dane (w naszym przykładzie kursy walut) są przesyłane w formacie wieloplatformowym – w postaci dokumentów XML. W tym celu wymyślono specjalny standard - MYDŁO.

Tak, teraz usługi sieciowe, SOAP i XML są na ustach wszystkich, zaczynają być aktywnie wdrażane, a duże korporacje, takie jak IBM i Microsoft, wypuszczają nowe produkty zaprojektowane, aby pomóc w całkowitym przyjęciu usług internetowych.

Ale! Dla naszego przykładu z kursami walut, które trzeba przenieść ze strony banku do silnika sklepu internetowego, takie rozwiązanie będzie bardzo trudne. Przecież sam opis standardu SOAP zajmuje nieprzyzwoite półtora tysiąca stron, a to nie wszystko. Dla praktycznego zastosowania będziesz musiał nauczyć się pracować z zewnętrznymi bibliotekami i rozszerzeniami (tylko od PHP 5.0 zawiera bibliotekę do pracy z SOAP), napisać setki i tysiące linii kodu. A wszystko to po to, aby uzyskać kilka liter i cyfr, jest oczywiście bardzo ciężkie i irracjonalne.

Jest więc jeszcze jeden, z naciągiem można powiedzieć, alternatywny standard wymiany informacji – XML-RPC. Został opracowany przy udziale Microsoft przez UserLand Software Inc i jest przeznaczony do ujednoliconego przesyłania danych między aplikacjami przez Internet. Może zastąpić SOAP podczas budowania prostych usług, w których nie są potrzebne wszystkie „korporacyjne” funkcje prawdziwych usług internetowych.

Co oznacza skrót XML-RPC? RPC to skrót od Remote Procedure Call - zdalne wywołanie procedury. Oznacza to, że aplikacja (czy to skrypt na serwerze, czy zwykła aplikacja na komputer kliencki) może w sposób przezroczysty używać metody, która jest fizycznie zaimplementowana i wykonywana na innym komputerze. XML jest tu używany, aby zapewnić uniwersalny format opisu przesyłanych danych. Jako transport do przesyłania wiadomości wykorzystywany jest protokół HTTP, który pozwala na swobodną wymianę danych za pośrednictwem dowolnych urządzeń sieciowych – routerów, firewalli, serwerów proxy.

Aby z niego skorzystać, trzeba mieć: serwer XML-RPC, który udostępnia jedną lub więcej metod, klienta XML-RPC, który potrafi sformować poprawne żądanie i przetworzyć odpowiedź serwera, a także znać parametry serwera niezbędne do powodzenia operacja - adres, nazwa metody i przekazane parametry.

Cała praca z XML-RPC odbywa się w trybie „request-response”, jest to jedna z różnic między technologią a standardem SOAP, gdzie istnieją zarówno koncepcje transakcji, jak i możliwość wykonywania odroczonych połączeń (gdy serwer zapisuje żądanie i odpowiada na nie w określonym czasie w przyszłości). Te dodatkowe funkcje bardziej przydatne w przypadku wydajnych usług korporacyjnych, znacznie komplikują rozwój i obsługę serwerów oraz nakładają dodatkowe wymagania na deweloperów rozwiązań klienckich.

Procedura pracy z XML-RPC rozpoczyna się od utworzenia żądania. Typowe żądanie wygląda tak:

POST/RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Host: serwer.localnet.com
Typ treści: tekst/xml
długość treści: 172

Metoda badania
Witaj XML-RPC!

Pierwsze wiersze tworzą standardowy nagłówek żądania HTTP POST. Wymagane parametry obejmują host, typ danych (typ MIME), którym musi być tekst/xml, oraz długość wiadomości. Norma określa również, że pole User-Agent musi być wypełnione, ale może zawierać dowolną wartość.

Następnie pojawia się normalny nagłówek dokumentu XML. Główny element żądania - , może być tylko jeden i nie może zawierać takich węzłów jak dzieci. Oznacza to, że na jedno żądanie można wywołać tylko jedną metodę na serwerze.

Linia Metoda badania wskazuje, że wywołujemy metodę o nazwie TestMetod. W razie potrzeby możesz tutaj podać nazwę programu lub modułu zawierającego metodę, a także ścieżkę do niej. Chociaż specyfikacja XML-RPC nakłada pewne ograniczenia na zestaw znaków, których można użyć do oznaczenia metody, sposób ich interpretacji zależy wyłącznie od implementacji serwera.

Następnie ustawiane są przekazane parametry. W tym celu sekcja Który może zawierać dowolną liczbę podelementów Które zawierają parametr opisany przez tag . Nieco dalej przyjrzymy się parametrom i typom danych. W naszej wersji do metody przekazywany jest jeden parametr ciągu, zawarty w tagu .

Po opisaniu wszystkich parametrów następują znaczniki zamykające. Żądanie i odpowiedź w XML-RPC to normalne dokumenty XML, więc wszystkie znaczniki muszą być zamknięte. Ale w XML-RPC nie ma pojedynczych znaczników, chociaż są one obecne w standardzie XML.

Teraz przeanalizujmy odpowiedź serwera. Nagłówek odpowiedzi HTTP jest normalny, jeśli żądanie zostanie pomyślnie przetworzone, serwer zwróci odpowiedź HTTP/1.1 200 OK. Podobnie jak w żądaniu, należy poprawnie określić typ MIME, długość wiadomości oraz datę wygenerowania odpowiedzi.

Treść odpowiedzi jest następująca:

PRAWDA

Teraz zamiast tagu głównego znacznik jest wskazany , który natychmiast zawiera wyniki przetworzenia żądania. Niestety nazwa metody nie jest przekazywana w odpowiedzi, dlatego należy przechowywać ją po stronie klienta, aby uniknąć pomyłek w przypadku jednoczesnego wywołania różnych metod.

Jeśli wystąpił błąd podczas przetwarzania Twojego żądania, zamiast Odpowiedź będzie miała element , w którym zostanie zagnieżdżona struktura opisująca błąd. Opis błędu zawiera numeryczny kod błędu oraz tekstowy opis błędu.

Przyjrzyjmy się teraz szybko typom danych w XML-RPC. W sumie istnieje 9 typów danych - siedem prostych i 2 złożone. Każdy typ jest opisany własnym znacznikiem lub zestawem znaczników (w przypadku typów złożonych).

Proste typy:

Wszystkie liczby- tag lub ;

typ logiczny- tag , może przyjmować zarówno wartości 0/1 jak i prawda/fałsz;

Ciąg znaków ASCII- opisane przez tag i może zawierać dowolny ciąg znaków;

Liczb zmiennoprzecinkowych- tag , może również zawierać znak liczby, część ułamkowa oddzielone kropką;

Data i godzina- opisane przez tag i musi być zgodny z formatem iso8601. Do dalszego przetwarzania w skryptach ten format jest trochę niewygodny, więc zawsze jest konwertowany podczas wysyłania / odbierania żądania. Można to zrobić za pomocą specjalnej funkcji w bibliotece, a jeśli jej nie ma, programista musi ręcznie przekonwertować datę.

Ostatni prosty typ to ciąg zakodowany w base64, który jest opisany przez tag . Ten typ jest uniwersalny, można go wykorzystać do przesyłania dowolnych danych między klientem a serwerem, chociaż ilość danych przesyłanych dzięki temu kodowaniu wzrasta. Ale jest to konsekwencją tekstowego charakteru protokołu i Format XML w szczególności.

Typy złożone są reprezentowane przez struktury i tablice. Struktura zdefiniowana przez element główny , który może zawierać dowolną liczbę elementów , definiując każdego członka struktury. Element konstrukcji jest opisany dwoma znacznikami: pierwszym, , opisuje nazwę członka, po drugie, , zawiera wartość elementu (wraz ze znacznikiem opisującym typ danych).

Tablice nie mają nazw i są opisane tagiem , który zawiera jeden element i co najmniej jeden element podrzędny , gdzie określone są dane szczegółowe. Tablica może zawierać dowolne inne typy w dowolnej kolejności, a także inne tablice, co pozwala opisywać tablice wielowymiarowe. Możesz także opisać tablicę struktur. Jednak fakt, że tablica nie ma nazwy, komplikuje jej użycie w niektórych przypadkach, aby przesłać złożone dane, trzeba je wielokrotnie pakować do innych typów (na przykład, aby przenieść kilka tablic, można osobno spakować każdą tablicę w strukturę , a następnie utwórz jedną tablicę z tych struktur).

Oczywiście ktoś powie, że taka lista typów danych jest bardzo uboga i „nie pozwala na rozbudowę”. Tak, jeśli potrzebujesz przenieść złożone obiekty lub duże ilości danych, lepiej użyć SOAP. A dla małych, niewymagających aplikacji XML-RPC jest całkiem odpowiedni, co więcej, bardzo często nawet jego możliwości okazują się zbyt duże! Biorąc pod uwagę łatwość wdrożenia, bardzo dużą liczbę bibliotek dla prawie każdego języka i platformy oraz szerokie wsparcie w PHP, XML-RPC często po prostu nie ma konkurentów. Choć nie da się od razu doradzić, jako uniwersalnego rozwiązania – w każdym przypadku trzeba decydować w zależności od okoliczności.

Technologia XML-RPC jest wykorzystywana w systemie WordPress do różnych fajnych funkcji, takich jak pingbacki, trackbacki, zdalne zarządzanie witryną bez logowania do panelu administracyjnego itp. Niestety, osoby atakujące mogą wykorzystać go do ataków DDoS na strony internetowe. Oznacza to, że tworzysz piękne, ciekawe projekty WP dla siebie lub na zamówienie, a jednocześnie, niczego nie podejrzewając, możesz stać się częścią botnetu DDoS. Łącząc ze sobą dziesiątki i setki tysięcy witryn, źli ludzie tworzą potężny atak na swoją ofiarę. Chociaż Twoja strona również cierpi, ponieważ. ładunek trafia do hostingu, na którym jest hostowany.

Dowodem takiej złej aktywności mogą być logi serwera (access.log in nginx) zawierające następujące wiersze:

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

Wróćmy jednak do luki XML-RPC. Wizualnie objawia się to powolnym otwieraniem witryn na twoim serwerze lub niemożnością ich załadowania w ogóle (błąd 502 Bad Gateway). Wsparcie techniczne mojego hostera FASTVPS potwierdziło moje przypuszczenia i poradziło:

1. Zaktualizuj WordPress do Ostatnia wersja wraz z wtyczkami. Ogólnie rzecz biorąc, jeśli śledzisz, być może przeczytałeś o konieczności zainstalowania najnowszej wersji 4.2.3. ze względu na krytykę bezpieczeństwa (podobnie jak poprzednie wersje). Krótko mówiąc, aktualizacja jest dobra.

1. Zainstaluj wtyczkę Wyłącz XML-RPC Pingback.

Wyłączanie XML-RPC w WordPress

Wcześniej wydaje mi się, że opcja włączenia/wyłączenia XML-RPC była gdzieś w ustawieniach systemowych, ale teraz nie mogę jej tam znaleźć. Dlatego najprostszym sposobem na pozbycie się go jest użycie odpowiedniej wtyczki.

Znajdź i pobierz Disable XML-RPC Pingback lub zainstaluj go bezpośrednio z panelu administracyjnego systemu. Nie musisz niczego dodatkowo konfigurować, moduł od razu zaczyna działać. Usuwa metody pingback.ping i pingback.extensions.getPingbacks z interfejsu XML-RPC. Usuwa również X-Pingback z nagłówków HTTP.

W jednym z blogów znalazłem kilka dodatkowych opcji usunięcia wyłączenia XML-RPC.

1. Wyłącz XML-RPC w szablonie.

W tym celu do pliku functions.php motywu dodawana jest linia:

Zamów odmowę, zezwól na odmowę ze wszystkich

Osobiście nie korzystałem z dwóch ostatnich metod, ponieważ. Podłączyłem wtyczkę Disable XML-RPC Pingback - myślę, że to wystarczy. Właśnie dla tych, którzy nie lubią dodatkowych ustawień, zaproponowałem alternatywne opcje.