Chronicles of DDOS: Radzenie sobie z atakiem XMLRPC na boty WordPress

Opublikowany: 2019-04-08

Dwa dni temu napotkaliśmy trudności ze stroną internetową jednego z naszych klientów jako Nettsted Limited. Zwykle nie zapewniamy wsparcia technicznego naszym klientom, ale niestety usługa hostingowa naszego klienta nie zapewnia jej żadnego wsparcia. Ponieważ czuliśmy się odpowiedzialni, aby jej pomóc, postanowiliśmy podjąć działania przeciwko atakom botnetów . Podczas ataku mieliśmy do czynienia z dziwnymi zachowaniami botów. Opowiem o tym, co działo się godzina po godzinie na tej stronie i jakie działania podjęliśmy w celu ochrony strony internetowej naszego klienta.

Spis treści

Początek ataku DDOS: napastnik identyfikuje się

Ponieważ jestem właścicielem Nettsted Limited, pracuję 16-18 godzin dziennie, aby zapewnić wsparcie naszym klientom. Mamy różnych klientów z całego świata, więc muszę być czujny w różnych strefach czasowych. Miesiące później najpierw chciałem obejrzeć film i bawić się z rodziną. Niestety to był jeden z najgorszych dni w mojej karierze. Po filmie postanowiliśmy odpocząć. Jednak tylko niewidoczna rzecz dźgnęła mnie i powiedziała „hej! trzeba spojrzeć na swoje prace, a potem spać”. I tak… Oto co wydarzyło się podczas mojej 5 godzinnej nieobecności w pracy:

  1. Jeden z moich klientów usunął wtyczkę SEO, usunął wszystkie opisy i tytuły strony. Złamał również strukturę linków na stronie.
  2. Drugi klient usunął kilka zainstalowanych przez nas wtyczek związanych z SEO. Zmieniono ustawienia pamięci podręcznych i jakoś wszystkie pliki .js i .css są zepsute.
  3. Jedna z moich klientek dostała ataku DDOS i po prostu obserwowała, jak jej strona internetowa się rozpada.

Kiedy dołączyłem do WhatsApp i Skype, widziałem wiele skarg przez te 5 godzin. 30% zdań było po prostu „Gdzie jesteś?!”.

Mój klient powiedział mi, że otrzymał wiadomość przez WhatsApp. Atakujący przedstawił się z numerem telefonu i powiedział mojemu klientowi, że zamierza ją zaatakować. Brzmi to naprawdę głupio, ale naprawdę to zrobił… Kiedy wróciłem do pracy, atak już się rozpoczął.

Dzień 1-) Podjęcie pierwszej akcji przeciwko atakom

Oto kilka logów z ataku, który dostaliśmy:

103.9.156.249 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.1; ; verifying pingback from 93.174.93.163"
199.223.214.148 - - [07/Apr/2019:01:19:03 +0100] "GET / HTTP/1.0" 200 13194 "-" "WordPress/3.3.1; http://www.mentalic.gr"
216.240.176.141 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.0;
104.236.33.158 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.1; http://pmsearchpartners.com; verifying pingback from 93.174.93.163"
149.210.236.96 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/3.9.27; http://imageconsultant.mu/; verifying pingback from 149.210.236.96"
185.87.249.33 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1;
158.69.26.84 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/3.9.2; http://teensystudios.com; verifying pingback from 93.174.93.163"
103.233.76.243 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.26; http://help.worldmart.in; verifying pingback from 93.174.93.163"
203.175.180.254 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.1; http://www.cybertechriskcenter.com; verifying pingback from 93.174.93.163"
199.223.214.148 - - [07/Apr/2019:01:19:03 +0100] "GET / HTTP/1.0" 200 13194 "-" "WordPress/3.3.1; http://www.mentalic.gr"
68.71.60.249 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.26; http://www.itunesalternative.org; verifying pingback from 93.174.93.163"
66.55.132.6 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/3.8.16;
163.172.103.45 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-"

W logach widać, że atak pochodził z programów klienckich WordPress. Jednak niektóre z tych ataków odbywały się również bez agentów. Sprawdziłem wszystkie te polecane strony i wszystkie były przestarzałe i porzucone. Jest jeden adres IP, który był prawie taki sam we wszystkich dziennikach, i były 2 inne. 93.174.93.163 był holenderskim adresem IP, ale sądzę, że to serwer/hosting przygotowywał dla nas atak botnetowy. Pozostałe 2 IP były również holenderskimi IP.

Ponieważ było zbyt wiele powiadomień „weryfikujących pingback z” ataków, pomyślałem, że do atakowania używa pingbacków i xmlrpc.php.

Moją pierwszą reakcją na ataki była zmiana nazwy xmlrpc.php, a następnie usunięcie go w ogóle i usunięcie pingbacków z ustawień WordPressa .

Rezultat : Nie spowolnił nawet ataków.

Ponieważ nie uzyskałem żadnych dobrych wyników z pierwszych ruchów, postanowiłem usunąć z plików plik xmlrpc.php WordPressa. Jednak to nadal nie pomogło.

Udowodniono jednak, że pomaga w niektórych rodzajach ataków DDOS. Jeśli również masz z tym do czynienia, możesz również spróbować.

Dzień 1) Pierwsza odpowiedź: skorzystaj z bycia lokalnym

Teraz masz zamiar powiedzieć mi dlaczego nie użyłem cloudflare. Konfiguracja CF zabierała trochę czasu, a zmiany serwerów nazw mogą czasami być naprawdę bolesne. Chciałem więc spowolnić ataki, ale ustawiłem też cloudflare na stronie. Zmieniono serwery nazw. Atak był poważny i poważnie uszkodził użycie I/O, pasma i tak dalej. Wydaje mi się, że były to 2-3 osoby, które atakowały z różnych serwerów. Strona mojego klienta zarabiała 1000$ dziennie i był to dla niego poważny problem. Witryna nie działała przez około 6 godzin.

Ponieważ strona była lokalna, postanowiłem skonfigurować htaccess. Potrzebowałem wszystkich adresów IP w Danii. za pomocą strony internetowej udaje mi się znaleźć wszystkie adresy IP w Danii. Czasowo zamknąłbym stronę dla całego ruchu zagranicznego. Utworzyłem plik htaccess i zablokowałem cały ruch zagraniczny na stronie .

Wynik : To jest dobry tymczasowy wynik. Wszystkie złośliwe boty trafiały teraz do 403 stron. Jednak złe wieści. Boty Google również trafiały na 403. Ponieważ ruch botów pochodził głównie z USA, nie wykonałem żadnej konfiguracji dla adresów IP bota z USA lub Google. Ponieważ było to tymczasowe do czasu zmiany serwera nazw, nie stanowiło to problemu.

Przez cały czas rozmawiałem z klientką przez telefon i uspokajałem ją. Była bardzo zła i zdenerwowana tą sytuacją. Powiedziała mi, że dostała wiadomości od napastnika. Miała jego numer telefonu!

Dzień 1-) Zmieniono serwery nazw i problemy z ustawieniami Cloudflare

Około 2 godziny później skonfigurowałem htaccess, zmieniły się serwery nazw i aktywowałem cloudflare. Usunięto reguły odmów/zezwól z pliku .htaccess. Wystąpił jednak problem z ustawieniami WAF Cloudflare. Poprosiłem mojego klienta o zmianę adresu IP serwera i zrobiła to. Jakiś czas później zmieniłbym rekordy DNS Cloudflare, ponieważ wciąż tam były stare informacje IP. Jednak gdybym zrobił to wkrótce po zakupie IP, strona znów by nie działa. „Tryb ataku” był już aktywny na stronie.

Wynik : Po aktywacji Cloudflare wszystkie ataki zostały zatrzymane.

Po 6-7 godzinach podniecenia wstałem z krzesła i poszedłem spać. Myśleliśmy, że wygraliśmy, ale to jeszcze nie koniec.

Dzień 2) Wrócił! Ominięte w Cloudflare za pomocą botnetu!

Rano zmieniliśmy adres IP i odkąd pomyślałem, że strona jest bezpieczna, zmieniłem tryb ataku na średni. Wprowadziłem kilka innych zmian w .htaccess. Kupiłem Cloudflare PRO dla mojego klienta. Skonfigurowałem niektóre ustawienia WAF, aby strona była bezpieczniejsza. Jednak jakiś czas później zdołał wrócić z poważniejszymi atakami i poważna liczba ataków trafiała do początku. Omijał Cloudflare.

Niektóre ustawienia WAF Cloudflare obiecywały powstrzymanie ataków botów WordPress, XMLRPC Attack, ale tak nie było . Postanowiłem ustawić wszystkie ustawienia WAF jako domyślne w Cloudflare.

Wynik : Wszystkie ataki botów, które nie mają klienta użytkownika, zaczynają osiągać 403.

Wynik na jakiś czas przyniósł stronie ulgę i serwer znów działał. Jednak dostawaliśmy za dużo ataków i było nam blisko.

Dzień 2-) Blokowanie kraju w Cloudflare

Wreszcie pomyślałem, że powinniśmy zainwestować więcej w Cloudflare, aby pozbyć się tych ataków. Ostatnimi zmianami prawie usunęliśmy 50% zagrożenia. Jednak było jeszcze inne 50%. W przypadku lokalnej witryny blokowanie kraju nie stanowiłoby problemu. Ponadto, ponieważ naprawiliśmy 50% ruchu botów, ataki z USA nie byłyby dla nas poważnym problemem. Kupiliśmy przedsiębiorstwo Cloudflare i zablokowaliśmy cały ruch zagraniczny z wyjątkiem USA i Danii .

Wynik : naprawiło to 90% ruchu botnetowego.

Dzień 3-) Zemsta to danie, które najlepiej smakuje na zimno

Nasz serwer poradziłby sobie z 90% ruchu botnetowego. Nie zaprzestali jednak swoich ataków. Potem znalazłem ciekawą wtyczkę do WordPressa. Jednak najpierw musiałem to przetestować. W przeciwnym razie strona internetowa może się zawiesić, a to zrujnuje wszystko. Poprosiłem znajomego programistę o zaatakowanie jednej z moich stron internetowych. Działało idealnie. Następnie badam napastnika. Rozumiem kim on jest i dlaczego nas atakuje.

Najpierw skontaktowałem się z atakującym. Poprosiłem go, żeby przestał atakować. Jednak odpowiedział mi wieloma obelgami i przekleństwami. Właśnie zablokowałem mu dostęp do WhatsApp i nawet mu nie odpowiedziałem. Mój klient poprosił mnie, abym zapłacił więcej za tę usługę, ale odmówiłem. Traktowałem to jako powód do dumy. Poprosiłem mojego klienta o zgodę i usunąłem tryb ataku. Konfiguruję wtyczkę.

Zacząłem odsyłać jego paskudne, cholerne, podłe boty z powrotem na jego stronę internetową. Jego strona internetowa rozpadła się na moich oczach. To, co czułem, było takie samo z Cersei, który obserwował niszczenie septu Baelora. Potem wysłałem im jego inną stronę internetową, a potem inną i jeszcze inną… Kiedy zatrzymali atak, system się zatrzymał. Jednak kiedy zaczęli atakować botami, przekierowywał ich na wszystkie ich strony internetowe.