Ataki brute force należą do najczęstszych zagrożeń dla serwerów dostępnych z internetu. Zwykle są zautomatyzowane, uporczywe i niedrogie w przeprowadzaniu. Atakujący nie musi wiedzieć wiele o firmie, aby testować demona SSH, punkt końcowy RDP, panel administracyjny, bazę danych lub interfejs zdalnej administracji przy użyciu tysięcy skradzionych albo odgadniętych danych uwierzytelniających.
Wiele prób kończy się niepowodzeniem i początkowo stwarza niewielkie ryzyko. Niebezpieczeństwo polega na tym, że jedna z nich może się powieść, szczególnie gdy hasło zostało ponownie użyte, stare konto nadal jest aktywne albo usługa jest dostępna bez uwierzytelniania wieloskładnikowego. Powtarzające się nieudane logowania należy zatem traktować jako przydatne dane telemetryczne dotyczące bezpieczeństwa, a nie tylko internetowy szum w tle.
Ten poradnik wyjaśnia, jak rozpoznawać ataki brute force na serwery, które mechanizmy ograniczają ich skuteczność, gdzie strategie blokowania mogą zawieść oraz co zrobić, gdy atakujący uzyska dostęp.
Jak wygląda atak brute force na serwer
Atak brute force to próba uzyskania dostępu poprzez testowanie wielu haseł, nazw użytkowników lub kombinacji danych uwierzytelniających. Współczesne kampanie często wykorzystują credential stuffing zamiast losowego zgadywania: atakujący testuje pary nazw użytkowników i haseł zebrane podczas wcześniejszych wycieków. Password spraying opiera się na innym podejściu — jedno popularne hasło jest testowane na wielu kontach, co pomaga uniknąć blokad nakładanych na pojedyncze konto.
SSH i RDP są częstymi celami, ponieważ zapewniają bezpośredni dostęp administracyjny. Inne publicznie dostępne usługi mogą być równie istotne:
- Panele hostingu i zarządzania serwerem
- Bramy VPN i portale zdalnego dostępu
- Administracja pocztą i interfejsy webmail
- Nasłuchujące bazy danych, takie jak MySQL, PostgreSQL lub Microsoft SQL Server
- Strony logowania aplikacji i punkty końcowe API
- Konsole wirtualizacji, kopii zapasowych i monitoringu
Aktywność może pochodzić z jednego adresu, zmieniającej się listy serwerów w chmurze lub szerokiego zakresu adresów IP. Rozproszony atak może generować tylko kilka prób z każdego adresu, a jednocześnie dużą łączną liczbę nieudanych logowań. Dlatego analiza pojedynczej reguły zapory lub jednego dziennika serwera często nie wystarcza.
Jak wykrywać zautomatyzowane próby logowania
Zacznij od dzienników uwierzytelniania
Dzienniki uwierzytelniania to pierwsze miejsce, które należy sprawdzić. W systemie Linux zdarzenia SSH są zwykle zapisywane w dzienniku systemowym lub dzienniku uwierzytelniania. Administratorzy Windows powinni przejrzeć zdarzenia RDP i inne istotne zdarzenia w Podglądzie zdarzeń lub centralnej platformie rejestrowania Windows. Panele administracyjne, produkty VPN i bazy danych zazwyczaj prowadzą własne dzienniki audytowe.
Szukaj wzorców, a nie pojedynczych zdarzeń:
- Dziesiątki lub setki nieudanych logowań w krótkim czasie
- Próby logowania na wiele nazw użytkowników, także takich, które nie istnieją
- Powtarzające się próby na konta uprzywilejowane, takie jak root, administrator lub konta usług
- Połączenia przychodzące w regularnych odstępach czasu ze zmieniających się adresów
- Udane uwierzytelnienie bezpośrednio po długiej serii niepowodzeń
- Logowania o nietypowych porach, z nietypowych krajów lub przez nieznane sieci
- Nowe konta, zmienione hasła, zmodyfikowane klucze SSH lub zmienione członkostwo w grupach
Pojedyncze nieudane logowanie nie jest incydentem. Wzorzec niepowodzeń w kilku systemach, szczególnie zakończony sukcesem, wymaga zbadania. Zespoły oceniające narzędzia do wykrywania i blokowania mogą porównać dostępne rozwiązania, korzystając z tych materiałów dotyczących wykrywania brute force na serwerach i Fail2ban, ale przed wdrożeniem automatycznych blokad powinny sprawdzić każde narzędzie we własnym środowisku.
Wykorzystaj alerty i sygnały sieciowe
Zbieranie dzienników jest przydatne tylko wtedy, gdy ktoś lub coś je analizuje. Alerty mogą opierać się na progach, na przykład dziesięciu nieudanych logowaniach SSH w ciągu pięciu minut, ale reguły bazujące wyłącznie na progach mogą nie wykryć powolnego password sprayingu. Lepszy monitoring łączy zdarzenia uwierzytelniania z adresami źródłowymi, nazwami użytkowników, geolokalizacją, krytycznością zasobów i udanymi logowaniami.
Telemetria sieciowa może dostarczyć dodatkowego kontekstu. Obserwuj nagły wzrost liczby prób połączeń z portami zarządzania, powtarzające się uzgadnianie połączeń TCP, które nigdy się nie kończy, skanowanie kilku usług lub nietypowy ruch wychodzący po podejrzanym logowaniu. Zaatakowany serwer może zacząć łączyć się z infrastrukturą command and control, skanować systemy wewnętrzne lub przesyłać dane.
Centralny monitoring jest szczególnie ważny dla agencji zarządzających kilkoma środowiskami klientów. Jeden pulpit lub platforma SIEM ułatwia wykrycie tego samego zakresu IP, wzorca nazw użytkowników lub kampanii password sprayingu na wielu serwerach. Alerty powinny trafiać do osoby, która może podjąć działanie, i zawierać wystarczająco dużo szczegółów, aby podczas incydentu nie zmuszać reagujących do przeszukiwania surowych dzienników.
Zabezpieczanie SSH i innych publicznie dostępnych usług
Stosuj silne uwierzytelnianie
Jeśli jest to praktyczne, wyłącz uwierzytelnianie SSH za pomocą haseł i wymagaj używania indywidualnych kluczy kryptograficznych. Każdy administrator powinien mieć oddzielne konto i klucz, a dostęp uprzywilejowany powinien być uzyskiwany poprzez kontrolowane podniesienie uprawnień, a nie współdzielone dane root. Chroń klucze prywatne hasłami i przechowuj je bezpiecznie. Niezwłocznie usuwaj klucze, gdy pracownik lub dostawca nie potrzebuje już dostępu.
W przypadku RDP, VPN i paneli administracyjnych korzystaj z MFA wszędzie tam, gdzie produkt je obsługuje. Jeśli jest to możliwe, wybieraj metody odporne na phishing, szczególnie dla kont administratorów. MFA nie sprawia, że podatna usługa staje się całkowicie bezpieczna, ale znacząco zmniejsza wartość skradzionego hasła.
Zasady dotyczące haseł nadal mają znaczenie w usługach, które wymagają haseł. Stosuj długie, unikalne dane uwierzytelniające, menedżer haseł oraz oddzielne konta do administracji, aplikacji i baz danych. Nigdy nie pozostawiaj domyślnych danych dostawcy. Wyłącz nieaktywne konta i sprawdzaj konta usług pod kątem niepotrzebnego dostępu interaktywnego.
Ogranicz dostępność
Najbezpieczniejszy interfejs zarządzania to taki, który nie jest publicznie dostępny. W miarę możliwości ogranicz dostęp do SSH, RDP i baz danych do VPN, sieci prywatnej, serwera bastionowego lub określonych zakresów adresów IP administratorów. Nasłuchująca baza danych zazwyczaj nie ma powodu przyjmować połączeń z publicznego internetu.
Zmiana domyślnego portu SSH może ograniczyć przypadkowe skanowanie, ale sama w sobie nie jest mechanizmem bezpieczeństwa. Atakujący mogą szybko wykryć niestandardowe porty. Traktuj to jako ograniczanie szumu, a nie ochronę. Silniejszymi mechanizmami są ograniczenia sieciowe, nowoczesne uwierzytelnianie, aktualizacje i monitoring.
Stosuj aktualizacje bezpieczeństwa systemów operacyjnych, paneli administracyjnych, VPN i aplikacji. Usuń niepotrzebne usługi oraz sprawdź, czy interfejsy administracyjne nie zostały przypadkowo ujawnione po migracjach lub zmianach zapory. Zabezpiecz hosta zgodnie z udokumentowaną bazą konfiguracji, a następnie okresowo ją przeglądaj, zamiast zakładać, że jednorazowa konfiguracja pozostanie prawidłowa.
Techniki blokowania i ograniczania częstotliwości
Zapory sieciowe i filtrowanie po stronie dostawcy
Zapory hosta mogą ograniczać porty zarządzania, zakresy sieci źródłowych i odrzucać ruch, zanim dotrze on do aplikacji. Zapory sieciowe lub filtrowanie po stronie dostawcy mogą przechwycić albo odrzucić niepożądany ruch wcześniej, co jest pomocne, gdy atak generuje wystarczającą liczbę połączeń, aby zużyć zasoby serwera.
Mechanizmy po stronie dostawcy nie zastępują bezpiecznych kont. Mogą być również mniej precyzyjne niż mechanizmy świadome aplikacji, szczególnie gdy wielu prawidłowych klientów korzysta z tego samego zakresu adresów. Zdefiniuj zatwierdzone sieci administratorów i utrzymuj awaryjną ścieżkę dostępu, aby błędna reguła nie odcięła osób odpowiedzialnych za jej naprawę.
Blokowanie w stylu Fail2ban
Narzędzia takie jak Fail2ban obserwują dzienniki i dodają tymczasowe reguły zapory po określonej liczbie nieudanych prób. Są praktyczne w przypadku SSH i innych usług o spójnym formacie dzienników. Czas blokady, próg niepowodzeń i lista ignorowanych adresów należy ustalać na podstawie zaobserwowanych zachowań, a nie kopiować bez weryfikacji.
Tymczasowe blokady zwykle zapewniają lepszy kompromis niż blokowanie stałe. Spowalniają kolejne próby, ograniczają szum w dziennikach i dają administratorom czas na reakcję bez tworzenia stale rosnącej listy blokad. Upewnij się, że samo narzędzie monitorujące działa prawidłowo po rotacji dzienników, ponownym uruchomieniu usługi i zmianach systemu uwierzytelniania.
Ograniczanie częstotliwości i kontrola kont
Ograniczanie częstotliwości można wdrożyć na odwrotnym proxy, zaporze, w aplikacji lub u dostawcy tożsamości. Jest szczególnie przydatne w przypadku stron logowania i API, które muszą pozostać publicznie dostępne. Stopniowe opóźnienia, wyzwania CAPTCHA i MFA zależne od ryzyka mogą ograniczyć automatyzację bez odcinania każdego użytkownika po jednym błędzie.
Blokady kont wymagają większej ostrożności. Ścisła blokada może zatrzymać zgadywanie hasła dla jednego konta, ale atakujący może celowo zablokować wszystkich pracowników w ramach kampanii password sprayingu. Preferuj krótkie, stopniowo wydłużane blokady lub ograniczanie częstotliwości i utwórz przetestowany proces administracyjnego odzyskiwania dostępu. Nigdy nie polegaj na zasadach blokowania kont jako jedynej ochronie konta uprzywilejowanego.
Kompromisy i typowe martwe pola
Blokowanie adresów IP jest łatwe do zrozumienia, ale ma ograniczenia. Adresy mogą być współdzielone przez biura, sieci komórkowe, platformy chmurowe lub operatorów stosujących translację adresów na poziomie operatorskim. Zablokowanie całego zakresu może wpłynąć na prawidłowych użytkowników, podczas gdy blokowanie pojedynczych adresów może mieć niewielki efekt przeciwko rozproszonej kampanii. Reguły geolokalizacyjne mogą również powodować fałszywe alarmy dotyczące podróżujących pracowników i zdalnych dostawców.
Fałszywe alarmy to coś więcej niż niedogodność. Zablokowany system monitoringu, operator kopii zapasowych lub administrator awaryjny może opóźnić odzyskiwanie. W stosownych przypadkach utrzymuj listę dozwolonych zaufanych ścieżek zarządzania, ale starannie ją chroń i regularnie przeglądaj. Nie dodawaj do niej szerokiego dynamicznego zakresu tylko dlatego, że kiedyś był powiązany z prawidłowym użytkownikiem.
Rozproszone ataki wymagają mechanizmów skoncentrowanych na tożsamości. Jeśli to samo konto jest atakowane z wielu sieci, blokowanie źródeł nie rozwiąże problemu. Silne MFA, unikalne dane uwierzytelniające, wyłączone uwierzytelnianie hasłem i centralne wykrywanie są trwalszymi rozwiązaniami. Szukaj wzorców według nazwy użytkownika, urządzenia, aplikacji i czasu, a nie tylko adresu IP.
Jak zbadać podejrzany atak
Zacznij od zabezpieczenia dowodów. Zapisz zaatakowany host, strefę czasową, odpowiednie wpisy w dziennikach, adresy źródłowe, atakowane konta i wszystkie zastosowane automatyczne blokady. Wyeksportuj dzienniki, zanim zostaną nadpisane. Jeśli istnieje realne prawdopodobieństwo włamania, unikaj przedwczesnego ponownego uruchamiania lub czyszczenia serwera; ważne mogą być dane ulotne i aktywne połączenia.
Następnie ustal, czy aktywność zakończyła się niepowodzeniem, czy też konto zostało użyte. Wyszukaj udane logowania w pobliżu nieudanych prób i zweryfikuj źródło, metodę uwierzytelniania oraz czas. Następnie sprawdź:
- Nowe konta lokalne lub domenowe i nieoczekiwane członkostwo w grupach
- Nowe autoryzowane klucze SSH, zaplanowane zadania, zadania cron lub wpisy startowe
- Zmiany reguł zapory, ustawień dostępu zdalnego lub zasad bezpieczeństwa
- Nieoczekiwane procesy, nasłuchujące porty i połączenia wychodzące
- Zmodyfikowane pliki internetowe, pliki binarne, skrypty i pliki konfiguracyjne
- Nietypowy dostęp do danych, pobieranie, przesyłanie lub eskalację uprawnień
Porównaj hosta ze znaną, prawidłową konfiguracją lub standardem budowania. Przejrzyj dzienniki dostawcy tożsamości, VPN, zapory, punktów końcowych i chmury, a także sam serwer. Obróć dane uwierzytelniające i unieważnij sesje, gdy istnieje uzasadnione podejrzenie ich ujawnienia. Jeśli system przetwarza dane regulowane, informacje klientów lub obsługuje krytyczne operacje, postępuj zgodnie z procesem reagowania na incydenty obowiązującym w organizacji i rozważ wymogi prawne, regulacyjne oraz umowne dotyczące powiadomień.
Zablokowanie próby nie jest reakcją na włamanie
Reguła zapory lub blokada Fail2ban reaguje na zaobserwowane połączenie. Nie usuwa atakującego, który już się uwierzytelnił. Udane logowanie zmienia sytuację z uciążliwego ruchu w potencjalny incydent bezpieczeństwa.
Gdy podejrzewasz włamanie, odizoluj serwer od sieci, zachowując niezbędne dowody i kontrolowaną ścieżkę zarządzania. Nie usuwaj po prostu podejrzanego konta i nie przywracaj hosta do sieci. Atakujący mógł utworzyć mechanizm utrzymania dostępu, wykraść dane uwierzytelniające lub zmienić pliki binarne. Bezpieczniejsza reakcja polega na określeniu zakresu, odbudowie systemu z zaufanego źródła, gdy jest to właściwe, usunięciu pierwotnej słabości, rotacji sekretów i ścisłym monitorowaniu przywróconych usług.
Odzyskiwanie zależy również od posiadania czystych i użytecznych kopii zapasowych. Kopie zapasowe powinny być odizolowane od zwykłych danych uwierzytelniających serwera i płaszczyzny zarządzania, ponieważ atakujący z uprawnieniami administratora może próbować je usunąć lub zaszyfrować. Safenix zapewnia zewnętrzne kopie zapasowe serwerów firmowych kontrolowanych przez klienta. Dane są szyfrowane za pomocą klucza, którego Safenix nigdy nie posiada, przechowywane w Niemczech i utrzymywane w niezmiennym stanie przez wybrany okres przechowywania. Jest to mechanizm odzyskiwania, a nie zastępstwo dla hardeningu lub reagowania na incydenty: klient nadal odpowiada za kontrolę chronionego serwera i decyzję o sposobie jego przywrócenia.
Środowiska VPS, serwery dedykowane i hosting współdzielony
Dostępne mechanizmy bezpieczeństwa w dużej mierze zależą od tego, kto kontroluje system operacyjny i granicę sieci. VPS zarządzany przez klienta zwykle zapewnia dostęp do systemu operacyjnego, zapory i konfiguracji usług. Pozwala to administratorowi wymuszać używanie kluczy SSH, wyłączyć logowanie hasłem, zainstalować monitoring hosta i ograniczyć ruch zarządzania, z uwzględnieniem ograniczeń platformy dostawcy.
Serwer dedykowany zazwyczaj oferuje bardziej bezpośrednią kontrolę nad hostem, projektem sieci i separacją obciążeń, choć dokładny podział odpowiedzialności nadal zależy od umowy i modelu zarządzania. Serwer zarządzany może ograniczać niektóre zmiany, jednocześnie zapewniając wsparcie operacyjne. Podział odpowiedzialności należy udokumentować przed wystąpieniem incydentu.
Hosting współdzielony działa inaczej. Dostawca kontroluje hosta, system operacyjny, konfigurację serwera internetowego i granicę bezpieczeństwa między klientami. Klienci mogą zmieniać ustawienia aplikacji, ale zazwyczaj nie mogą instalować Fail2ban, modyfikować zapory hosta, wyłączać SSH dla platformy ani przeglądać wszystkich dzienników uwierzytelniania. Wskazówki dotyczące mechanizmów bezpieczeństwa w infrastrukturze VPS zarządzanej przez klienta w porównaniu z hostingiem współdzielonym należy zatem interpretować w kontekście faktycznie zapewnionego dostępu.
Safenix chroni serwery kontrolowane przez klienta. Nie sprzedaje planu kopii zapasowych dla witryny działającej na hostingu współdzielonym, a witryny na takim hostingu nie należy przedstawiać tak, jakby obejmowała ją usługa kopii zapasowych serwerów Safenix. W przypadku hostingu współdzielonego klient musi korzystać z dostępnych u hosta opcji tworzenia kopii i eksportu danych albo przenieść obciążenie do infrastruktury, nad którą organizacja ma wymagany poziom kontroli.
Praktyczna rutyna operacyjna
Ochrona przed brute force działa najlepiej jako rutyna operacyjna, a nie pojedyncze ustawienie. Co najmniej regularnie przeglądaj publicznie dostępne usługi i konta uprzywilejowane. Testuj alerty za pomocą autoryzowanych symulacji, potwierdzaj, że blokady wygasają zgodnie z założeniami, i sprawdzaj, czy administratorzy nadal mogą korzystać z awaryjnej ścieżki dostępu.
- Prowadź ewidencję usług dostępnych z internetu, ich właścicieli i zatwierdzonych sieci zarządzania.
- Analizuj trendy nieudanych i udanych uwierzytelnień, a nie tylko najnowszy alert.
- Do administracji używaj kluczy SSH, MFA, unikalnych kont i zasady najmniejszych uprawnień.
- Aktualizuj systemy operacyjne i publicznie dostępne aplikacje oraz usuwaj niepotrzebne usługi.
- Centralizuj dzienniki i spraw, aby alerty umożliwiały podjęcie działania zespołowi odpowiedzialnemu za reakcję.
- Testuj przywracanie kopii zapasowych i potwierdzaj, że dane odzyskiwania są odizolowane od danych uwierzytelniających serwera.
- Dokumentuj kontakty eskalacyjne, czynności związane z zabezpieczaniem dowodów i procedury odbudowy.
Zautomatyzowane ataki będą nadal testować publicznie dostępne usługi, ale nie muszą przerodzić się w kryzys. Najpierw ogranicz dostępność, utrudnij nadużycie uwierzytelniania, stosuj blokowanie jako wyważoną warstwę ochrony i monitoruj oznaki, że próba zakończyła się udanym logowaniem. Gdy granica zostanie przekroczona, niezwłocznie przejdź od blokowania do reagowania na incydent i odzyskiwania.