W ciągu ostatniego tygodnia nasz system monitorowania bezpieczeństwa odnotował setki prób uzyskania dostępu do naszej strony. Liczba brzmi niepokojąco, ale rzeczywistość jest znacznie spokojniejsza – a ten artykuł wyjaśni, dlaczego.
Prawdziwych ataków nie było. Wszystkie 616 zewnętrznych zdarzeń bezpieczeństwa zarejestrowanych w dniach od 7 do 15 lipca okazało się szumem generowanym przez automatyczne boty – skanery, które masowo sprawdzają tysiące stron w poszukiwaniu znanych luk w WordPress. Nasza strona nie jest zbudowana na WordPress, więc ścieżki, których szukano, nigdy nie istniały, a każda próba kończyła się blokadą lub błędem 404.
Liczby
Czego dokładnie szukano – i dlaczego jest to groźne dla niezabezpieczonej strony
Poniższe ścieżki to klasyczne cele ataków na WordPress. W naszym przypadku były nieszkodliwe, ponieważ takich plików po prostu nie ma, ale warto zrozumieć, dlaczego właśnie te ścieżki są w ogóle skanowane.
/wp-login.php – 273 żądania, 197 unikalnych adresów IP To formularz logowania do panelu administracyjnego WordPress. Boty przeprowadzają ataki brute force – automatycznie testują tysiące kombinacji nazw użytkowników i haseł, mając nadzieję na odgadnięcie prawidłowych danych dostępu. Jeśli strona ma słabe hasła lub brak limitu prób logowania, taki atak może zakończyć się pełnym dostępem administratora.
/xmlrpc.php – 255 żądań, 183 unikalne adresy IP Stary plik interfejsu WordPress, używany do zdalnego publikowania. Jest popularnym celem ataków z dwóch powodów: można go użyć do zgadywania haseł znacznie szybciej niż przez zwykły formularz logowania (setki kombinacji w jednym żądaniu), a także wykorzystać w atakach DDoS typu amplification przeciwko osobom trzecim za pośrednictwem funkcji “pingback”.
/en/wp-json/wp/v2/users/me – 23 żądania, 21 unikalnych adresów IP Punkt końcowy REST API WordPress, który domyślnie może ujawniać prawidłowe nazwy użytkowników. Sam w sobie nie jest atakiem, ale stanowi etap rozpoznania – poznając prawdziwe nazwy użytkowników, atakujący może precyzyjniej kierować dalsze próby brute force.
/.env – 14 żądań, 12 unikalnych adresów IP To jedyny cel na naszej liście, który miał realny potencjał szkodliwy. Pliki .env zwykle zawierają hasła do baz danych, klucze API i inne sekrety. Jeśli taki plik jest dostępny z zewnątrz (z powodu błędnej konfiguracji serwera), wyciek jego zawartości może oznaczać pełne przejęcie systemu – nie tylko strony, ale także powiązanych usług. W naszym przypadku Next.js nie udostępnia tego pliku publicznie, dlatego wszystkie próby kończyły się błędem 404 lub blokadą.
/lv/wp-content/uploads – 7 żądań, 7 unikalnych adresów IP Folder przesyłanych plików WordPress. Jeśli jest błędnie skonfigurowany (na przykład pozwala wykonywać pliki PHP), atakujący, który zdobył choćby minimalny dostęp, może przesłać złośliwy skrypt i przejąć pełną kontrolę nad serwerem.
Jak działa nasz system monitorowania bezpieczeństwa
Te dane nie pochodzą ze zwykłych logów serwera – analizuje je opracowany przez nas system bezpieczeństwa oparty na AI, który śledzi cały ruch przychodzący, klasyfikuje każde zdarzenie według stopnia ważności i w czasie rzeczywistym podejmuje decyzję o blokadzie. System jest połączony z kanałem powiadomień na Discordzie, gdzie dwa razy dziennie publikowany jest raport podsumowujący – ile było zdarzeń, ile zablokowano i czy jest coś, na co warto zwrócić uwagę.
Oprócz regularnych raportów system ma także tzw. mechanizm page call – bezpośrednie pilne powiadomienie dla zespołu deweloperskiego, które omija zwykłe podsumowanie dwa razy dziennie i ostrzega natychmiast, gdy dzieje się coś wymagającego natychmiastowej reakcji. W odróżnieniu od zwykłego dziennika szumu (w którym setki żądań botów są po prostu cicho rejestrowane i blokowane), page call jest zarezerwowany dla rzadkich, naprawdę istotnych przypadków.
W praktyce page call wygląda tak: na telefon przychodzi bezpośrednie, pilne połączenie informujące o zdarzeniu. Nie można go odłożyć (snooze) – aby je wyłączyć, trzeba wstać i zalogować się do systemu. Gdy tylko ktoś z zespołu się zaloguje, page call zostaje wyłączony, a system pokazuje, kto dokładnie przejął rozwiązywanie incydentu. Po usunięciu problemu system przed wdrożeniem automatycznie sprawdza kod, błędy i luki – najpierw zanim trafi do naszego prywatnego repozytorium GitHub, potem na serwer, a na końcu na stronę live – aby upewnić się, że wszędzie jest spójna i poprawiona wersja.
W ostatnim okresie ten mechanizm zadziałał dwa razy:
- Próba dostępu do pliku
.env– ponieważ ten plik może zawierać hasła do baz danych i klucze API, system zaklasyfikował to jako zdarzenie wysokiego ryzyka i natychmiast ostrzegł zespół, mimo że żądanie zostało zablokowane automatycznie. - gramatika.evoex.eu – niedostępność – gdy strona tej subdomeny stała się nieosiągalna, system rozpoznał to jako przerwę w działaniu (a nie incydent bezpieczeństwa) i od razu powiadomił zespół, aby można było szybko zareagować i przywrócić usługę.
Takie dwupoziomowe podejście – ciche logowanie w przypadku masowego szumu generowanego przez boty, ale natychmiastowe powiadomienie w rzadkich, naprawdę istotnych sytuacjach – pozwala zespołowi deweloperskiemu nie skupiać się na setkach nieszkodliwych prób skanowania, a jednocześnie daje pewność, że naprawdę ważne zdarzenie nie zostanie niezauważone aż do kolejnego zaplanowanego raportu.
Pochodzenie
Większość ruchu pochodziła z USA (157), Francji (52), Wielkiej Brytanii (48), Wietnamu (46), Niemiec (39), Singapuru (36) i Indii (32). Ciągi User-Agent były podszywane pod zwykłe przeglądarki – typowy znak botnetu, który próbuje wyglądać jak prawdziwy użytkownik.
Wyraźny trend spadkowy
Liczba zdarzeń według dni (07-07 do 07-15): 148 → 137 → 75 → 61 → 110 → 41 → 38 → 13 → 1.
Spadek zbiega się ze stałym zablokowaniem 95 adresów IP – ochrona działa dokładnie tak, jak powinna.
Wniosek
Nie odnotowano ani jednego udanego ataku, wycieku danych, spamu z formularzy ani problemu z uwierzytelnianiem. Wszystkie próby były zautomatyzowanymi skanerami WordPress, które szukały celów, jakich tu nie ma. To nie znaczy, że zabezpieczenia są zbędne – wręcz przeciwnie, pokazuje to, że poprawnie skonfigurowana architektura inna niż WordPress oraz aktywne blokowanie IP skutecznie powstrzymują nawet masowe zautomatyzowane ataki, zanim dotrą do czegokolwiek wartościowego.