Ile ataków odpiera Twój serwer, gdy śpisz

Jeden serwer pod naszą opieką odparł prawie trzy tysiące prób logowania w ciągu dwóch i pół doby. Nie skok, nie incydent, nie „zhakowali nas” — zwykły wtorek serwera wystawionego do internetu. Najbardziej niepokojące jest tu jednak nie te trzy tysiące, tylko to, jak łatwo dało się je zupełnie przeoczyć. Nasz monitoring uczciwie zapisywał wszystko — ale kanał powiadomień milczał: jeden zepsuty parametr konfiguracji przez kilka dni z rzędu cicho połykał każde ostrzeżenie. Natrafiliśmy na to podczas rutynowego przeglądu własnej floty: naprawiliśmy jedną linijkę — i zobaczyliśmy, co spokojnie działo się przez cały ten czas.

Opowiemy tę historię na żywych liczbach z własnego sprzętu — zanonimizowanych, ale bez upiększeń. Bo najlepsze wyjaśnienie bezpieczeństwa to nie horror rodem z podręcznika, tylko to, co dzieje się właśnie teraz na Twoim serwerze, gdy o tym nie myślisz.

Czym jest atak brute-force na RDP i kogo dotyczy

RDP to protokół pulpitu zdalnego — ten sam przycisk „połącz się z serwerem z domu”, z którego korzystają miliony. Domyślnie nasłuchuje na porcie 3389, a ten numer zna na pamięć każdy bot w sieci. Schemat jest banalnie prosty: automaty dniem i nocą przeczesują internet w poszukiwaniu otwartego 3389, a gdy go znajdą — mielą tysiącami kombinacji „login-hasło”, dopóki nie trafią albo nie zostaną zablokowane.

Najważniejsze: to nie jest atak wymierzony osobiście w Ciebie. To szum tła, który uderza we wszystkich jednakowo — w bank, w piekarnię i w testowy serwer, który ktoś postawił „na pięć minut” trzy lata temu. Jeśli kiedyś wystawiłeś na zewnątrz port 3389 — sam albo za sprawą podwykonawcy — „żeby wygodnie łączyć się zdalnie”, gratulacje: już jesteś w tej puli. Pytanie tylko, czy drzwi są zamknięte — i czy dowiesz się, gdy ktoś jednak wejdzie.

Pisaliśmy już o niewidocznych czytelnikach Twojej strony — nieszkodliwych botach AI, które po cichu przeglądają Twoje strony. Ci goście są z tej samej rodziny — równie niewidzialni, tylko z przeciwnym zamiarem.

Co pokazują żywe liczby

Zacznijmy od firewalla. W ciągu ponad stu dni nieprzerwanej pracy zablokował na jednym serwerze 218 211 pakietów walących w port RDP — to około dwóch tysięcy dziennie. Na innym naszym serwerze — 61 436, kolejne sześćset dziennie. To nawet nie są próby logowania, to agresywne źródła, które firewall odciął już na podejściu prostą regułą: pięć prób z jednego adresu w ciągu minuty — i adres leci na czarną listę.

Najciekawsze zaczyna się za tą barierą. Rozproszony atak celowo omija limit „na adres”: wiele źródeł, każde puka po trochu, żeby blokada nie zadziałała. Dziennik jednej maszyny z tych samych 2,5 doby pokazał 2893 nieudane próby logowania, które przebiły się aż do okna uwierzytelniania. Z tego 2890 — dokładnie 99,9% — celowało w jedno jedyne konto: wbudowane administrator. Źródeł było 34, rozsianych po całym świecie: Korea Południowa, Niemcy, USA, kilka zakresów azjatyckich i latynoamerykańskich — typowy globalny botnet, któremu jest zupełnie obojętne, kim jesteś. I atak nie słabł — trzymał się na poziomie setek i tysięcy prób dziennie: 571, potem 1242, potem 1080.

Żadna się nie udała — bo administrator na tym serwerze jest wyłączony. Ale oto liczba, dla której warto było czytać aż dotąd. Kolejny serwer — bardzo podobny, tylko jego RDP nasłuchuje na niestandardowym porcie zamiast gołego 3389 — w tym samym okresie zebrał zaledwie 634 blokady. Wobec 218 tysięcy. Ten sam internet, te same botnety, jeden parametr konfiguracji — i mniej więcej trzysta razy mniej szumu na wejściu.

„Wszystko zielone” to najdroższe kłamstwo w monitoringu

Teraz najbardziej szczera część. Wszystkie te serwery przez cały czas pokazywały „wszystko w porządku” — i właśnie tam czai się największa pułapka. Oto trzy pułapki, w które wpadliśmy we własnej flocie podczas tego samego przeglądu.

Po pierwsze. Nocny backup przez pięć nocy z rzędu raportował sukces — kod wyjścia zero, zielony ptaszek — a w rzeczywistości za każdym razem się wywalał. Przyczyna jest typowa: uruchamiał się przez pośredni launcher w trybie „odpal i zapomnij”, a harmonogram zadań widział kod wyjścia launchera (zawsze zero), a nie prawdziwego skryptu pod spodem. Morał: monitorować trzeba rezultat — świeżość pliku-znacznika, zawartość logu — a nie status zadania. „Wykonano pomyślnie” nic nie znaczy, jeśli nie sprawdzasz, co konkretnie zostało wykonane.

Po drugie — ta sama historia, od której zaczęliśmy. System bezpieczeństwa przez kilka dni rzetelnie rejestrował krytyczne zdarzenia — i tyle samo dni nie mógł nikomu o nich powiedzieć: kanał powiadomień nie był skonfigurowany. A wszystkie zadania świeciły na zielono. Milczący monitoring jest gorszy niż żaden — daje fałszywe poczucie spokoju. Dlatego pierwsze, co trzeba przetestować po skonfigurowaniu alertów, to czy naprawdę docierają.

Po trzecie. Kolejna maszyna po cichu nagromadziła ponad tysiąc procesów — setki zombie z zadania, które przy każdym uruchomieniu zostawiało po sobie dwa procesy i nigdy ich nie sprzątało. Po pięćdziesięciu dniach wyczerpała się pamięć wirtualna, a backupy zaczęły się wywalać z błędem „za mało pamięci” — i znowu pod pogodnym zielonym statusem harmonogramu. Stan procesów i zasobów to też monitoring, nie tylko kod wyjścia.

Tak, to nasze własne błędy, i pokazujemy je nie z dumy, tylko dlatego, że skoro wpadliśmy w nie my — ludzie, dla których to codzienna praca — to wpadnie w nie każdy, kto wciąż ufa zielonemu statusowi.

Jak się bronić — co naprawdę działa

Dobra wiadomość: nie trzeba tu niczego egzotycznego ani drogiego. Oto zestaw, który wdrażamy u siebie i u klientów.

Poniższa lista jest już czysto techniczna — najprościej pokazać ją swojemu informatykowi i zapytać, które punkty są u Ciebie już wdrożone.

1. Niestandardowy port zamiast gołego 3389. Różnica 218 tysięcy do 634 to bezpośredni dowód, że to działa. Nie jedyna ochrona, ale najtańszy pierwszy filtr, który odsiewa zdecydowaną większość automatycznego szumu.
2. Rate-limit na poziomie firewalla — ta sama reguła „pięć prób na minutę z jednego adresu → blokada”. Wyłapuje pojedyncze agresywne źródła, zanim dotrą do logowania.
3. Wyłączyć wbudowane konta administrator i guest. Skoro 99,9% ataków celuje w konto administrator, jego wyłączenie sprawia, że cały ten brute-force traci sens.
4. Zapasowe konto do awaryjnego dostępu — z niestandardową nazwą i mocnym hasłem w menedżerze haseł, żeby po wyłączeniu domyślnego konta nie zamknąć sobie drzwi.
5. Monitoring zdarzeń bezpieczeństwa z żywym kanałem powiadomień — u nas to dziennik zdarzeń w postaci krótkiego podsumowania, wysyłanego do komunikatora. Koniecznie z weryfikacją, że alert dociera: patrz pułapka numer dwa.
6. Zarządzanie przez prywatną sieć mesh (Tailscale i podobne), a publiczny RDP usunąć całkowicie, jeśli dostęp z zewnątrz nie jest potrzebny. Najpewniejsza ochrona otwartego portu to port zamknięty.

Drzwi, do których pukają co noc

Trzy tysiące prób w dwie i pół doby nie biorą się stąd, że Twój serwer jest dla kogoś interesujący. Biorą się stąd, że w internecie nigdy nie jest tak cicho — dla nikogo: automaty sprawdzają każde drzwi co noc, Twoje też. Cała różnica polega na tym, kto jest gotowy — jedne drzwi są zamknięte i ktoś zobaczy pukanie, a na drugich widnieje „wszystko zielone”, po prostu dlatego, że nikt nie ustawił alarmu.

Ten szum tła pokazujemy na żywo i zanonimizowany — zobacz nasz publiczny dashboard bezpieczeństwa, gdzie widać dostawcę i kraj każdej próby, bez pełnych adresów. To samo podejście stoi za naszym „Strażnikiem” — stałym nadzorem, który wyłapuje to, co ważne, i milczy o drobiazgach. A jeśli interesuje Cię, jak głośna jest Twoja własna noc i czy zielony status Cię nie okłamuje — bezpłatny audyt pokaże to spokojnie, na liczbach.