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… :-)