Krótko: Skuteczna ochrona logowania przed brute force składa się z kilku warstw: logowania dwuskładnikowego dla wszystkich administratorów, hamulca dla prób logowania na serwerze WWW, automatycznych blokad na poziomie sieci i bezpiecznego przechowywania haseł w kodzie. Tam, gdzie to możliwe, obszar administracyjny jest dodatkowo dostępny tylko ze znanych sieci.
Jak przebiegają ataki brute force na logowania
Każda publicznie dostępna strona logowania prędzej czy później jest atakowana w sposób zautomatyzowany. Dotyczy to logowań do CMS, paneli sklepów, paneli hostingowych, poczty webowej i SSH. Atakujący nie muszą w tym celu wiedzieć, do kogo należy strona; ich narzędzia przeszukują internet w poszukiwaniu znanych adresów logowania.
Rozpowszechnione są trzy warianty. W klasycznym brute force wiele haseł jest próbowanych na jednym koncie. W password spraying jedno częste hasło jest testowane na wielu kontach, aby ominąć blokady. W credential stuffing używa się danych dostępowych skradzionych w innych usługach.
Dla zarządu i właścicieli sytuację łatwo podsumować: przejęte konto administratora jest tak samo niebezpieczne jak luka bezpieczeństwa na serwerze. Kto jest administratorem, może instalować rozszerzenia, zmieniać kod i eksportować dane.
Takie ataki rozpoznaje się po nagromadzeniu nieudanych logowań, po żądaniach POST na adres logowania z wielu różnych adresów IP oraz po próbach logowania z nazwami użytkowników takimi jak „admin” lub nazwami z impressum. Na to może wskazywać także wyraźnie wyższe obciążenie serwera w nietypowych godzinach, ponieważ każde logowanie kosztuje czas obliczeniowy na sprawdzenie hasła.
Ochrona logowania przed brute force: najskuteczniejsze środki
Nie każdy środek pasuje do każdego systemu. Poniższa kolejność się sprawdziła, ponieważ pierwsze punkty łączą największy efekt z niewielkim nakładem:
- Logowanie dwuskładnikowe dla wszystkich kont z uprawnieniami administratora. Nawet odgadnięte hasło już wtedy nie wystarcza. Szczegóły w poradniku Logowanie dwuskładnikowe dla dostępów administratora.
- Unikalne, długie hasła z menedżera haseł, bez współdzielonych kont.
- Rate limiting na serwerze WWW, tak aby z jednego adresu możliwych było tylko kilka prób na minutę.
- Automatyczne blokady wielokrotnie podejrzanych adresów na poziomie sieci, na przykład za pomocą Fail2ban.
- Zmniejszyć obszar administracyjny: dostęp tylko z sieci firmowej lub przez VPN, wyłączyć niepotrzebne interfejsy.
- Jednolite komunikaty o błędach, które nie zdradzają, czy nazwa użytkownika istnieje.
- Monitoring nieudanych logowań i powiadomienia przy nietypowych zdarzeniach.
Rate limiting na serwerze WWW
W Nginx można ograniczyć liczbę żądań na adres logowania na jeden adres IP. Przykład pokazuje stronę logowania WordPressa; ścieżkę i przekazanie do PHP proszę dostosować do swojego systemu.
# w bloku http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# w bloku server
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
# tutaj włączyć zwykłe przekazanie do PHP na Państwa serwerze
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
W Apache prostą, skuteczną ochronę daje ograniczenie obszaru administracyjnego do znanych adresów:
<Location "/admin">
Require ip 192.0.2.0/24
</Location>
Adres 192.0.2.0/24 to zastępnik z zakresu dokumentacyjnego; proszę wstawić swoją sieć firmową lub adres swojego VPN. Jeśli strona stoi za proxy lub CDN, serwer musi znać prawdziwy adres odwiedzającego, w przeciwnym razie reguła nie zadziała zgodnie z oczekiwaniami.
Fail2ban i blokady na poziomie sieci
Fail2ban czyta pliki logów i blokuje w zaporze na ustalony czas adresy, które wielokrotnie zwracają uwagę. Dla rate limitingu Nginx Fail2ban ma już odpowiedni filtr:
# /etc/fail2ban/jail.local
[nginx-limit-req]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 10m
bantime = 1h
[sshd]
enabled = true
maxretry = 5
bantime = 1h
Po restarcie proszę sprawdzić poleceniem fail2ban-client status, czy jail-e są aktywne. Proszę zadbać o to, by własne stałe adresy wyłączyć przez ignoreip, abyście nie zablokowali się sami. Dla stron logowania poszczególnych CMS możliwe są własne filtry, muszą one jednak pasować do faktycznego formatu logu i być wcześniej przetestowane.
Jeśli przed serwerem stoi CDN lub proxy, Fail2ban bez dalszych ustawień widzi tylko jego adresy. Blokada dotknęłaby wtedy wszystkich odwiedzających. W takim przypadku serwer WWW musi przejmować prawdziwy adres odwiedzającego z nagłówka usługi wstępnej, a blokady lepiej ustawiać bezpośrednio w CDN.
Blokady na poziomie sieci to narzędzie przeciw masowości, a nie przeciw atakom celowanym. Rozproszone ataki z bardzo wielu adresów z kilkoma próbami na adres obchodzą każdy próg. Dlatego drugi składnik pozostaje najważniejszą warstwą, a Fail2ban obniża przede wszystkim obciążenie i szum w logach.
Prawidłowe przechowywanie haseł we własnym oprogramowaniu
Kto programuje własne logowania, nigdy nie powinien przechowywać haseł w postaci jawnej ani z szybkimi funkcjami skrótu, takimi jak MD5 czy SHA-1. PHP ma z password_hash() bezpieczne rozwiązanie, które automatycznie zarządza solą i algorytmem.
<?php
declare(strict_types=1);
// Przy rejestracji lub zmianie hasła
$hash = password_hash($passwort, PASSWORD_DEFAULT);
// Przy logowaniu
if (password_verify($eingabe, $hashAusDatenbank)) {
if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
$neu = password_hash($eingabe, PASSWORD_DEFAULT);
// zapisać $neu w bazie danych
}
// Logowanie udane, odnowić identyfikator sesji
} else {
usleep(random_int(200000, 400000)); // równomierny czas odpowiedzi
// wyświetlić jednolity komunikat o błędzie
}
password_needs_rehash() dba o to, by starsze skróty przy następnym logowaniu zostały automatycznie przestawione na aktualny algorytm. Nieudane próby proszę protokołować z czasem, kontem i adresem, aby wzorce rzucały się w oczy. Wskazówki dotyczące analizy znajdują się w poradniku Analiza logów serwera WWW po ataku.
Szczególne przypadki: CMS, sklepy i panele
Wiele systemów ma obok widocznej strony logowania inne drogi, którymi sprawdzane są dane dostępowe. Te boczne wejścia są przy ochronie często pomijane.
- WordPress: interfejs
xmlrpc.phprównież przyjmuje logowania. Jeśli nie jest potrzebny, na przykład dla starszych aplikacji, proszę zablokować go na serwerze WWW. Proszę sprawdzić ponadto, czy nazwy użytkowników są widoczne na stronach autorów lub w interfejsie REST, i stosować dla administratorów nazwy, które nie pojawiają się publicznie. - Sklepy: obok obszaru administracyjnego celem są konta klientów, zwłaszcza dla credential stuffing. Pomagają tu rate limiting, powiadomienia o nowych logowaniach i opcjonalny drugi składnik dla klientów.
- Panele hostingowe i poczta webowa: te interfejsy są często dostępne z całego świata i chronią cały serwer. Powinny być dostępne tylko ze znanych sieci lub przez VPN.
- SSH: logowanie kluczem zamiast hasłem sprawia, że klasyczne zgadywanie jest nieskuteczne.
Jakie funkcje ochronne Państwa system ma sam w sobie, opisuje dokumentacja producenta. Rozszerzenia zewnętrznych dostawców powinny być aktywnie utrzymywane, w przeciwnym razie same stają się ryzykiem. Dla operatorów WordPressa aktualne priorytety zbiera strona WordPress i PHP2Shell.
Jak konkretnie pomaga PHP SOS?
- Ustalamy wszystkie dostępne strony logowania na Państwa serwerach, od CMS po panel hostingowy, i oceniamy ich ochronę.
- Wdrażamy rate limiting, Fail2ban i ograniczenia dostępu w ramach utwardzania serwera i testujemy je.
- Wspieramy wprowadzenie logowania dwuskładnikowego dla administratorów i dokumentujemy dostępy awaryjne.
- Dzięki monitoringowi bezpieczeństwa stale mamy na oku nieudane logowania i nowe konta administratorów.
Częste pytania
Po czym poznać atak brute force?
Typowe są liczne nieudane logowania w krótkim czasie, często na tę samą stronę logowania i ze zmieniającymi się nazwami użytkowników. W logu dostępu przejawia się to jako nagromadzenie żądań POST na adres logowania, często z wielu różnych adresów IP.
Czy konto należy blokować po kilku nieudanych próbach?
Ostrożnie: twarde blokady mogą posłużyć atakującym do wykluczenia uprawnionych użytkowników. Lepsze są rosnące opóźnienia, ograniczone czasowo blokady dla każdego adresu IP i powiadomienie właściciela konta.
Czy pomaga zmiana nazwy adresu logowania?
Zmniejsza zautomatyzowany szum w logach, ale nie jest prawdziwą ochroną. Kto zna lub znajdzie adres, może atakować dalej. Skuteczne są logowanie dwuskładnikowe, rate limiting i ograniczenie obszaru administracyjnego.
Czym jest credential stuffing?
Atakujący wypróbowują wtedy kombinacje adresu e-mail i hasła skradzione w innych usługach. Działa to, gdy użytkownicy używają tego samego hasła wielokrotnie. Unikalne hasła i drugi składnik odbierają tej metodzie podstawę.