# Ochrona logowania administratora przed brute force: ochrona każdego logowania > Ochrona logowania i panelu admina przed brute force: rate limiting, Fail2ban, logowanie dwuskładnikowe i bezpieczne przechowywanie haseł z password_hash. Źródło: https://phpsos.de/pl/ratgeber/brute-force-login-schutz/ Stan: 25.10.2026 Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6 **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](https://phpsos.de/pl/ratgeber/zwei-faktor-admin/). - **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. ```nginx # 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: ```apache Require ip 192.0.2.0/24 ``` 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: ```ini # /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