Envato Elements - pobieraj co chcesz, ile chcesz

W drugiej połowie lipca, w piękny piątkowy poranek, po porannym spacerze z psami usiadłem do komputera, bo na mojej administracyjnej skrzynce e-mail pojawiły się powiadomienia m.in. ze skryptu SysWatch, oraz z aplikacji Monit, czyli narzędzi, które wykorzystuje do monitorowania zasobów serwera. A z racji tego, że z kufelkiem tego dnia siedział obok kolega, który coś tam kupa (rozróżnia hosting od domeny ;-)), to pomyślałem, że od razu pokaże mu, jak można w relatywnie prosty sposób zdiagnozować źródło i wyeliminować problem.

Analiza ataku na stronę działającą na WordPressie (WooCommerce)

Dlatego w tym artykule nie będzie (za dużo) teorii, a opis kolejnych kroków, jakie podejmowałem, by uporać się z problemem, czyli nienaturalnym obciążeniem procesora serwera, o czym poinformowały mnie wiadomości e-mail ze wspomnianych systemów (SysWatch i Monit). Celowo też starałem się podczas tej operacji korzystać z jak najprostszych narzędzi i rozwiązań. Jednakże głównym celem była szybka diagnoza i leczenie, bo całość działa się na serwerze VPS jednego z moich klientów…

Po otrzymaniu powiadomień o nienaturalnym obciążeniu procesora serwera zacząłem od zalogowania się do konsoli (po SSH) i sprawdzenia za pomocą polecenia htop co tak obciąża wirtualny procesor serwera VPS:

Od razu widać, że jest to proces odpowiedzialny za obsługę plików PHP, a dzięki wdrożonemu mechanizmowi PHP Pools od razu widać było, której strony to dotyczy.

Zważywszy na to, że strona jest dość dobrze keszowana (m.in. wtyczka Cache Enabler do WordPressa), to miałem już nawet nie tyle podejrzenia co się najpewniej dzieje, co wręcz pewność – intensywny ruch na niekeszowane zasobny/strony WordPressa… Hmm… ;-)

Dla pewności zerknąłem do logów webserwera Nginx:

W tym momencie tylko potwierdziły się moje przypuszczenia – najprawdopodobniej jakiś automatyczny atak na stronę logowania do WordPressa. Czyli jeden z niewielu adresów, który nie jest keszowany.

By pokazać to od trochę innej strony, zerknijmy do statystyk CloudFlare, gdzie widać duży wzrost zainteresowania domeną/stroną:

I jeszcze do Google Analytics, gdzie cisza i spokój:

Choćby po tym widać, że zainteresowanie nie dotyczy normalnych stron, gdzie działają statystyki, a stron specjalnych, gdzie tego typu usługi nie są potrzebne (np. strona logowania do WordPressa).

Gdy już diagnoza wydawała się więcej niż oczywista (i została udokumentowana) przyszła pora na wyeliminowanie problemu. W przypadku zwykłej strony (np. firmowa strona internetowa) można np. założyć prostą blokadę na hasło do elementów związanych ze stroną logowania, jak i samym panelem zarządzania WordPressem. W tym przypadku miałem jednak do czynienia ze sklepem internetowym (WooCommerce), więc tego typu działania wydawały mi się zbyt radykalne, nawet jakbym w komunikacie blokady podał login i hasło…

A z racji tego, że miało to być coś nie tylko skutecznego, ale i relatywnie prostego do wdrożenia, postanowiłem skorzystać z reguł stron (page rules) w CloudFlare:

Wystarczyło dla adresu logowania ustawić najwyższy stopień ochrony (I’m Under Attack):

https://[DOMENA]/wp-login.php

Ew w wersji bardziej rozbudowanej, można od razu podobny mechanizm wdrożyć dla pliku „xmlrpc.php”, który również jest częstym celem ataku:

Po wdrożeniu tego zabezpieczenia (tylko na plik wp-login.php) na serwerze zapanował spokój:

Z doświadczenia też wiem, że nawet tak podwyższony stopień ochrony dla tego zasobu nie jest specjalnie kłopotliwy dla zwykłych (prawdziwych) użytkowników, których rozpoznaje całkiem skutecznie (czytaj: większość prawdziwych użytkowników strony nawet nie zauważy, że wdrożyliśmy najwyższy stopień ochrony, nawet podczas korzystania z tego elementu). Zresztą można wdrożyć też własną wersję strony z komunikatem z potencjalnym testem dla odwiedzającego, który akurat został do niego zakwalifikowany…

I w sumie to tyle. Mam nadzieję, że udało mi się pokazać, że odpowiednia konfiguracja serwera (monitoring) i strony (ukrycie jej np. za CloudFlare) pozwala w relatywnie krótkim czasie, w relatywnie prosty sposób zdiagnozować i – co najwazniejsze – wyeliminowac tego typu problemy (ataki). A w razie czego, jesteśmy do usług… :-)

(!) Zgłoś błąd na stronie
Potrzebujesz profesjonalnej pomocy? Skontaktuj się z nami!
Spodobał Ci się artykuł? Zapisz się do naszego Newslettera - ZERO SPAMu, same konkrety, oraz dostęp do dodatkowych materiałów przeznaczonych dla subskrybentów!
Na podany adres e-mail otrzymasz od nas wiadomość e-mail, w której znajdziesz link do potwierdzenia subskrypcji naszego Newslettera. Dzięki temu mamy pewność, że nikt nie dodał Twojego adresu przez przypadek. Jeśli wiadomość nie przyjdzie w ciągu najbliższej godziny (zazwyczaj jest to maksymalnie kilka minut) sprawdź folder SPAM.

Patryk

CEO Webinsider.pl, a do tego CTO, CIO, CFO, CMO, CSO, COO i CRO ;-)
Pasjonat nowych technologii - od sprzętu po oprogramowanie, od serwerów po smartfony i rozwiązania IoT. Potencjalnie kiepski bloger, bo nie robi zdjęć "talerza" zanim zacznie jeść.

Dumny przyjaciel swoich psów :-)
Napisz komentarz
wipl_napisz-komentarz_01Jeśli informacje zawarte na tej stronie okazały się pomocne, możesz nam podziękować zostawiając poniżej swój komentarz.

W tej formie możesz również zadać dodatkowe pytania dotyczące wpisu, na które – w miarę możliwości – spróbujemy Ci odpowiedzieć.
Linki partnerskie
Niektóre z linków na tej stronie to tzw. „linki partnerskie”, co oznacza, że jeśli klikniesz na link i dokonasz wymaganej akcji (np. zakup/rejestracja) możemy otrzymać za to prowizję. Pamiętaj, że polecamy tylko te produkty i usługi, z których sami korzystamy, i uważamy, że są tego na prawdę warte… :-)
Znaki towarowe i nazwy marek
W niektórych wpisach (oraz innych miejscach na stronie) mogą być przedstawione/użyte znaki towarowe i/lub nazwy marek, które stanowią własność intelektualną tych podmiotów, a zostały użyte wyłącznie w celach informacyjnych.