Skuteczne wykrywanie ataków typu brute-force decyduje o stabilności i reputacji usług sieciowych. To z pozoru banalna metoda łamania haseł — wielokrotne, zautomatyzowane próby logowania — która przynosi realne koszty: obciążenie procesora i łącza, wzrost opóźnień, blokady kont, a w skrajnym wypadku nieautoryzowany dostęp. W ekosystemie publicznych serwerów, paneli administracyjnych i środowisk multitenant (shared hosting, VPS, chmura), przeoczenie wczesnych sygnałów może uruchomić kaskadę incydentów, w tym nadużycia zasobów i spam wysyłany z przejętej skrzynki. Poniżej znajduje się przewodnik, który porządkuje wiedzę: od podstaw, przez praktyczną analizę śladów w systemach, po zaawansowane metody korelacji i automatyzacji reakcji.

Na czym polega atak brute-force i jakie ma wektory

Atak polega na systematycznym testowaniu wielu kombinacji danych logowania: najczęściej hasła do istniejących kont. Warianty obejmują:

• Brute-force klasyczny — szybkie próby na jednym koncie, zwykle z jednego adresu IP lub niewielkiej puli.
• Password spraying — niewielka liczba popularnych haseł testowana na wielu kontach, by uniknąć blokady jednego użytkownika.
• Credential stuffing — użycie zestawów wyciekłych loginów i haseł z innych serwisów z myślą o „recyklingu” haseł.
• Low-and-slow — rozproszone, wolne próby rozciągnięte w czasie, aby nie przekroczyć progów detekcji.

Wektory najczęściej dotyczą usług wystawionych publicznie: logowanie do systemów CMS, panele pocztowe (IMAP/POP3/SMTP Auth), interfejsy administracyjne (np. cPanel, Plesk), interfejsy API, a także usługi systemowe: SSH w Linuksie i RDP w Windows. W środowiskach korporacyjnych i chmurach publicznych dochodzą konsolowe loginy SSO/OAuth, VPN-y, rejestry kontenerów oraz panele orkiestracji.

Wczesne sygnały i wzorce w logach

Najlepszym źródłem prawdy o próbach logowania są logi: systemowe, aplikacyjne i sieciowe. Wzorce, na które warto zwrócić uwagę:

• Nagłe skoki liczby nieudanych logowań (HTTP 401/403, SMTP 535, IMAP/POP3 błędy AUTH, kody PAM dla Linuksa, zdarzenia 4625 w Windows).
• Powtarzalność prób dla jednego użytkownika z jednego lub wielu IP, albo na odwrót — wiele użytkowników z jednego IP (password spraying).
• Sekwencja fail → fail → fail → sukces tuż po serii niepowodzeń z tej samej podsieci lub systemu autonomicznego (ASN).
• Anomalie geolokalizacyjne: logowania z krajów, z których organizacja zwykle nie ma ruchu.
• Częstość prób wykraczająca poza oczekiwane wzorce dobowo-tygodniowe (np. noce/weekendy).
• Zmiana agentów użytkownika i parametrów TLS/JA3 między próbami, sugerująca automatyzację lub rotację narzędzi.

Na poziomie serwerów Linuksowych kluczowy jest syslog i auth.log, w którym znajdziemy wpisy typu „Failed password for invalid user…”, „Connection closed by authenticating user…”. W Windows Server ważne są dzienniki Zabezpieczeń z eventami 4625 (nieudane logowanie) i 4624 (udane), wraz z polami źródłowego adresu sieciowego. Dla HTTP warto korelować statystyki 401/403, błędy w aplikacji i metryki reverse proxy (Nginx/Apache), a dla poczty — dzienniki MTA i uwierzytelnienia SASL.

Narzędzia i techniki detekcji w środowiskach hostingowych

W praktyce hostingowej ważne jest połączenie analiz lokalnych z centralnymi. Na pojedynczym serwerze można stosować lokalne reguły i grok/regex do parsowania logów oraz proste ograniczanie tempa (rate limiting). W większym środowisku, gdzie współistnieją dziesiątki hostów webowych, paneli i usług pocztowych, liczy się agregacja i korelacja. Tu do gry wchodzi SIEM, które porządkuje zdarzenia i pozwala budować reguły wykrywające semantyczne wzorce ataku.

W warstwie sieciowej dodatkowym źródłem są strumienie przepływów (NetFlow/sFlow/IPFIX), logi zapór, statystyki load balancerów oraz informacje z systemów IDS/IPS (np. sygnatury dla surowego ruchu do portów logowania). W warstwie aplikacyjnej kluczowe są moduły analizy logowań, rate-limiting w proxy i moduły WAF, które wyłapują nietypowe wzorce żądań POST do endpointów logowania.

Analiza logów: praktyczne przykłady dla SSH, RDP, HTTP i poczty

SSH: Typowy atak to skanowanie IPv4 i próby na domyślnym porcie 22. Wpisy w /var/log/auth.log pokażą „Failed password for root from X.X.X.X port Y ssh2” oraz „Invalid user admin from…”. Wykrywanie obejmuje sumowanie nieudanych prób dla pary (IP, user) i wyliczanie krótkich okien czasowych (np. 1–5 minut). Anomalie to też wiele nieudanych prób „invalid user” — zwykle słownikowe loginy typu admin, test, user.

RDP: W Windows często widać masowe 4625 z parametrami LogonType 10 (zdalne interaktywne), z adresami zewnętrznymi. Analiza powinna łączyć liczbę 4625 per IP, per konto, oraz monitorować natychmiastowe przejście do 4624 dla tego samego połączenia. Dobrym sygnałem jest też próba logowania do wielu kont w krótkim czasie.

HTTP (panele i CMS): Strony logowania generują 401/403 lub niestandardowe kody aplikacyjne. Reverse proxy (Nginx/Apache) ujawni wzrost żądań POST na /wp-login.php, /administrator, /user/login itp. W logach warto szukać nierealistycznych wartości „req_per_minute” dla jednego IP, wskaźnika „fail-to-success” (np. 50 niepowodzeń bez sukcesu), oraz rotacji User-Agent sugerującej botnet.

Poczta (IMAP/POP3/SMTP AUTH): Ataki prowadzą do zapełnienia kolejki MTA lub prób wysyłki spamowej po ewentualnym przejęciu konta. Logi zawierają „SASL LOGIN authentication failed”, kody 535 i 454. Warto mierzyć nieudane logowania per konto, per IP, oraz sprawdzać powiązanie pór dnia i geolokacji (konta ludzkie często mają stabilne rytmy).

Wykrywanie anomalii i wskaźniki behawioralne

Klasyczne progi „5 nieudanych logowań w 1 minutę” są potrzebne, ale współczesne botnety adaptują tempo. Dlatego rośnie znaczenie detekcji anomalii. Przykładowe sygnały:

• Odchylenie od profilu dobowego: użytkownik zwykle loguje się 1–3 razy rano, tymczasem widzimy 200 prób w nocy.
• Podejrzany „fail ratio”: konto, które normalnie ma 0–1 błędów na tydzień, nagle generuje 50 błędów w godzinę.
• Zmienna entropia kont docelowych: lista loginów testowanych przez jedno IP wygląda jak słownik popularnych nazw („admin”, „guest”, „test”).
• Rozproszona aktywność per ASN: wiele źródeł, ale z tych samych kilku systemów autonomicznych, co sugeruje wynajęte zasoby chmurowe.
• „Success-after-distribution”: po wielu nieudanych próbach rozłożonych na różne IP pojawia się pojedynczy sukces na jednym IP z tej samej puli.

W środowiskach z dużą liczbą witryn dobrym uzupełnieniem jest korelacja metadanych TLS (odciski JA3/JA3S), parametry TCP (np. pcap z SYN rate), a także reputacja źródeł (RBL/Threat Intelligence). To pozwala wychwycić łagodne, ale długotrwałe kampanie.

Integracja z SIEM i automatyzacja reakcji

Centralizacja logów i zdarzeń w SIEM umożliwia budowę reguł łączących dane z wielu warstw: aplikacji, systemu, sieci i bram. Skuteczne reguły obejmują:

• Korelację „fail burst”: X nieudanych logowań per konto lub per IP w Y minut z dowolnej aplikacji.
• „Cross-service correlation”: to samo IP próbuje zalogować się do panelu WWW, SMTP AUTH i SSH w 15 minut.
• „Geo hop”: nagłe przejście między odległymi krajami w krótkim czasie dla tego samego konta.
• „New user at scale”: próby do kont, które nigdy nie istniały w systemie (filtrowanie listy aktywnych użytkowników).

Automatyzacja reakcji (SOAR) zmniejsza czas od wykrycia do działania: tymczasowa blokada IP/ASN, podniesienie poziomu wymagań (np. dodatkowy token), izolacja konta, powiadomienia do właściciela usługi. Ważne, by reagować proporcjonalnie: blokada adresu NAT może dotknąć wielu klientów; wówczas preferowane jest ograniczenie tempa i wyższe tarcie po stronie uwierzytelnienia (np. CAPTCHA).

Monitoring na poziomie sieci i infrastruktury chmurowej

W środowiskach multi-cloud i CDN logi aplikacyjne to za mało. Należy wykorzystywać:

• Flow logs (np. VPC Flow Logs) do wykrywania nietypowego natężenia połączeń do portów logowania.
• Zapory aplikacyjne i WAF/CDN do obserwacji żądań HTTP oraz analizy sygnatur botów.
• Load balancery i ich logi (ELB/ALB, HAProxy, Nginx) jako centralny punkt widzenia na wzorce failed auth.
• Listy reputacyjne źródeł (TOR, proxy, bulletproof hosting) z automatycznym nadawaniem scoringu ryzyka.

W kontenerach (Kubernetes) detekcja wymaga zbierania logów z sidecarów, Ingress Controllerów i komponentów typu API Server. Mapowanie ruchu do konkretnej aplikacji/namespace’u pozwala precyzyjnie zidentyfikować zasób będący celem ataku, nawet przy dynamicznym skalowaniu.

Honeypoty, tarpit i testy kontrolowane

Deceptive defense, jak honeypot, działa jak czujnik dymu w korytarzu. Wystawienie kontrolowanego punktu logowania z nieistniejącymi kontami pozwala szybko dowiedzieć się o aktywności skanera i wzorcach ataku w Twojej adresacji. Tarpit spowalnia sesje (np. wydłużając czas odpowiedzi przy nieudanym logowaniu), co obniża skuteczność narzędzi atakującego bez dotykania realnych użytkowników.

Testy kontrolowane (red team, purple team) uczą system detekcji rozpoznawania legalnie zainscenizowanych kampanii. Na tej bazie można stroić progi, reguły i automatyczne playbooki, a także mierzyć średni czas wykrycia i reakcji.

Metryki, alerty i progi, które mają sens

Warto zdefiniować metryki, które są stabilne i zgodne z rytmem biznesu:

• Nieudane logowania per konto, per IP, per kraj, z oknami czasowymi 1/5/15/60 min.
• Współczynnik niepowodzeń do udanych logowań (fail/success ratio) i jego odchylenia.
• Entropia nazw użytkowników w próbach z jednego źródła (czy to słownik?).
• Liczba endpointów logowania trafionych przez jedno IP w krótkim czasie.
• Wzrost kodów 401/403 po wdrożeniach — korelacja z release’ami pomaga oddzielić błąd konfiguracyjny od ataku.

Alerty powinny mieć priorytety: od informacyjnych (skan do portu) przez ostrzeżenia (seria nieudanych logowań) po krytyczne (sukces po serii prób, udany login z nietypowego kraju z nowego urządzenia). Istotne jest uczenie się sezonowości — w Black Friday czy po kampanii marketingowej ruch rośnie i progi muszą to uwzględniać.

Błędy i pułapki w detekcji oraz jak ograniczać false positive

Najczęstsze problemy:

• Zbyt agresywne progi: blokada adresów NAT dostawców mobilnych powoduje lawinę zgłoszeń od klientów.
• Brak whitelisting/allowlist dla monitoringu i skanerów bezpieczeństwa własnej organizacji.
• Niedoszacowanie rozproszonych ataków low-and-slow — pojedyncze źródła są „czyste”, dopiero agregacja pokazuje wzorzec.
• Niespójne strefy czasu w logach — trudna korelacja i fałszywe wnioski.
• Brak powiązania kont z kontekstem ryzyka (VIP, konta techniczne, serwisy krytyczne).

Aby ograniczyć false positive, stosuj profilowanie kont i usług (baseline), korelację wielu sygnałów (np. reputacja IP + anomalie behawioralne), a także mechanizmy potwierdzania: dodatkowy krok tylko przy podwyższonym ryzyku zamiast globalnej blokady.

Rola polityk bezpieczeństwa i ergonomii logowania

Detekcja to połowa sukcesu. Druga połowa to higiena uwierzytelniania. Wymuszanie złożonych haseł, ich rotacja zależna od ryzyka, blokady czasowe po serii błędów, mechanizmy „progressive delay”, oraz dodatkowe czynniki (MFA/OTP/WebAuthn) — to elementy, które radykalnie zmniejszają skuteczność brute-force. Równie ważne jest wyłączenie nieużywanych kont i protokołów (np. zakaz logowania root przez SSH, tylko klucze), a także rozdzielenie kanałów logowania administracyjnego od publicznego.

Specyfika środowisk hostingowych: shared, VPS i dedykowane

W shared hosting jeden atakujący może wpływać na throughput całego węzła. Kluczowe jest odizolowanie zasobów (cgroups/LSAPI), ratelimiting na poziomie reverse proxy, a także centralny WAF przed farmą. Na VPS operator powinien dostarczać profile zabezpieczeń domyślnych (cis-hardening, firewall, brak zbędnych usług), a właściciel instancji — dbać o logi i integrację z centralnym SIEM, jeśli to możliwe. Serwery dedykowane i bare-metal dają pełną kontrolę, ale i pełną odpowiedzialność: polityki zapory, segmentacja, monitoring, skanowanie publicznych punktów wejścia powinny być standardem.

Operacjonalizacja: playbooki, runbooki i podział obowiązków

Dokumentuj proces: kto odbiera alert, jakie są progi i rodzaje reakcji, jak długo trwa blokada tymczasowa, kiedy eskalować i kiedy kontaktować właściciela usługi. Runbooki powinny obejmować również weryfikację wpływu na klientów (czy blokujemy popularny dostawca NAT?), oraz ścieżkę odblokowania, jeśli uznamy zdarzenie za fałszywie pozytywne. Playbook automatyzacji powinien zawierać rollback.

Współpraca WAF/IDS/IPS i backendów aplikacyjnych

Najlepsze wyniki osiąga się, gdy urządzenia brzegowe komunikują się z backendami. WAF może dodawać nagłówki kontekstowe (scoring ryzyka), które backend interpretuje, np. zaostrza mechanikę logowania: dodatkowa weryfikacja dla wysokiego ryzyka. Z kolei backend może zwracać sygnały do WAF (np. tag „failed_auth”), co upraszcza globalny rate limit dla punktów logowania. Integracja z systemem IDS zwiększa szansę wykrycia rozproszonych ataków na poziomie pakietów, które nie zostawią oczywistych śladów w aplikacji.

Praktyczne wskazówki: szybkie wygrane

• Ustal listę wszystkich punktów logowania w organizacji (inventory). Niechronione, zapomniane endpointy są częstym wektorem.
• Włącz centralne rejestrowanie oraz korelację z reputacją IP. Nawet proste listy RBL pomagają.
• Wprowadź zróżnicowane limity: twardsze na kontach krytycznych, łagodniejsze dla publicznych formularzy, ale z dodatkowymi tarciami.
• Wykorzystaj detekcję rzadkich agentów użytkownika i cech TLS. Boty często mają charakterystyczne odciski.
• Wdrażaj MFA dla paneli administracyjnych i poczty; brak MFA to najprostszy sukces dla atakującego.
• Wyłącz logowanie hasłem tam, gdzie możesz (klucze SSH, certyfikaty mTLS na wrażliwych API).

Wartościowe wzbogacanie kontekstu i ryzyka

Każde zdarzenie logowania zyskuje na znaczeniu, gdy dodasz kontekst: czy konto jest VIP, jaki jest normalny kraj pochodzenia, jaki to typ urządzenia, czy login pojawił się w znanych wyciekach, jaka jest historia sesji. System scoringu (niski/średni/wysoki) bazujący na tych atrybutach pozwala precyzyjniej kierować alerty do SOC i minimalizować „alert fatigue”.

Specjalne przypadki: API, SSO, IoT i nietypowe protokoły

API logują się inaczej niż ludzie. Zamiast formularza i sesji przeglądarkowej mamy klucze, podpisy i tokeny. „Brute-force” przybiera tu formę zgadywania kluczy, tokenów lub powtarzanych prób wymiany tokenu odświeżania. Detekcja opiera się na wskaźnikach nietypowej liczby błędów uwierzytelnienia, odrzucanych podpisów oraz wysoko entropijnych nagłówków, które nie zgadzają się z polityką. W SSO należy monitorować nieudane przepływy OIDC/SAML (błędne assertions), a w IoT — powtarzane próby logowania do MQTT/AMQP z domyślnymi poświadczeniami.

Przeciwdziałanie po wykryciu: od ograniczania tempa do MFA

Po wychwyceniu ataku należy zastosować łańcuch kontroli: w pierwszej kolejności rate limiting i „progressive delay”, później tymczasowa blokada źródła (preferencyjnie per /24 lub per ASN, jeśli to konieczne), a równolegle zwiększenie wymogów na wejściu (CAPTCHA, dodatkowy czynnik, potwierdzenie e‑mail). Ważne jest, aby udane logowanie po serii nieudanych prób z innego kraju wymagało wzmocnionej weryfikacji, nawet jeśli hasło jest poprawne. Audyt konfiguracji hasła i ewentualna wymiana kluczy to standard po incydencie.

Rejestrowanie ponad minimum: co przechowywać i jak długo

Dla skutecznej forensyki przechowuj: znaczniki czasu z milisekundami, adres źródłowy i docelowy, identyfikator aplikacji/usługi, identyfikator sesji/żądania, result code, UA/JA3, korelacyjny trace-id, a przy protokołach systemowych — nazwy kont, TTY, rodzaj logowania. Retencja powinna pokrywać cykl wykrywania i analiz, a indeksowanie umożliwiać szybkie zapytania per konto/IP/ASN/kraj. Pamiętaj o zgodności z prawem i minimalizacji danych wrażliwych.

Skalowanie detekcji: od pojedynczego hosta do całej floty

Na pojedynczym hoście wystarczą lokalne mechanizmy rejestrowania i sankcji, proste wykresy i alerty. W flocie: centralizacja, standaryzacja schematów logów, globalne reguły i listy reputacyjne, wspólny namespace dla identyfikatorów żądań. Bazując na metadanych i telemetrii, można wdrożyć adaptacyjne progi: jeżeli globalnie rośnie fala ataków, tymczasowo zaostrzamy polityki dla wszystkich regionów.

Bezpieczeństwo a doświadczenie użytkownika

Walka z brute-force często ściera się z użytecznością. Zbyt twarde progi i CAPTCHA po każdym błędzie frustrują klientów. Rozwiązaniem jest dynamiczna kontrola ryzyka: niski scoring — brak dodatkowych kroków; wysoki — dodatkowa weryfikacja lub ograniczenie tempa. Takie podejście minimalizuje fałszywe alarmy i jednocześnie nie przepuszcza ataków o wysokim prawdopodobieństwie.

Dlaczego warto łączyć warstwy: od sieci po aplikację

Atakujący charakterystycznie „przesącza się” przez wiele warstw: skan portu, próby TLS, błędy logowania, odrzucenia WAF, wreszcie pojedynczy sukces. Korelacja tych śladów daje pełny obraz i lepszy kontekst dla decyzji. Z kolei pojedyncza warstwa bywa zawodna: botnet low-and-slow nie wygeneruje progu na jednym węźle, ale suma ruchu w agregacji już tak.

Podsumowanie

Wykrywanie ataków typu brute-force nie sprowadza się do liczenia nieudanych logowań. To praca na kontekście: agregacji zdarzeń, profilach użytkowników, reputacji źródeł, a także precyzyjnej automatyzacji reakcji. Połączenie logów systemowych i aplikacyjnych z danymi sieciowymi, wykorzystanie narzędzi klasy SIEM, integracja z IDS i WAF, a także wsparcie w postaci pułapek typu honeypot, daje realną przewagę w środowisku, gdzie publiczne interfejsy są permanentnie sprawdzane przez skanery. Na poziomie pojedynczego serwera i całych farm kluczowe są właściwe metryki, alerty, kontekst oraz rozsądny balans między bezpieczeństwem a wygodą. Wreszcie: hartowanie punktów logowania (MFA, klucze do SSH, blokady domyślnych kont, obserwacja RDP) sprawia, że nawet jeśli atak dotrze do drzwi, nie będzie w stanie ich otworzyć, a Ty dowiesz się o tym odpowiednio wcześnie, zanim powstanie prawdziwa szkoda.