Jak zablokować atak brute force w WordPress?

Atak brute force w WordPressie zatrzymasz przede wszystkim przez ograniczenie liczby prób logowania, włączenie 2FA oraz zablokowanie XML-RPC, jeśli nie korzystasz z tej funkcji. Najszybciej wdrożysz limit prób za pomocą wtyczki Limit Login Attempts Reloaded, a blokadę XML-RPC możesz ustawić na poziomie serwera w pliku .htaccess.

Jak rozpoznać atak brute force?

Brute force polega na automatycznym testowaniu wielu kombinacji loginów i haseł. Boty najczęściej kierują żądania do /wp-login.php, /wp-admin/ oraz /xmlrpc.php. Celem jest przejęcie konta, ale same próby mogą też zwiększyć zużycie procesora i pamięci serwera.

Na trwający atak mogą wskazywać następujące sygnały:

• Nagłe spowolnienie panelu administracyjnego lub całej strony.
• Duża liczba żądań POST do wp-login.php w logach serwera.
• Wysokie obciążenie PHP lub serwera bez wyraźnej przyczyny.
• Alerty wtyczki bezpieczeństwa o nieudanych logowaniach i blokadach adresów IP.
• Powtarzające się próby logowania na konto „admin” lub inne przewidywalne loginy.

Jak ustawić limit prób logowania?

Najprostsze rozwiązanie to wtyczka ograniczająca liczbę nieudanych logowań. Przykładem jest Limit Login Attempts Reloaded. Po przekroczeniu ustalonego progu wtyczka czasowo blokuje adres IP, a w zależności od konfiguracji może także rejestrować próby i wysyłać powiadomienia.

Przed zmianami wykonaj kopię zapasową strony. Następnie skonfiguruj ochronę w następującej kolejności:

1. W panelu WordPressa przejdź do „Wtyczki” i wybierz „Dodaj nową”.
2. Wyszukaj Limit Login Attempts Reloaded, zainstaluj wtyczkę i ją aktywuj.
3. Otwórz jej ustawienia i ustaw limit na 3–5 nieudanych prób.
4. Ustaw czas pierwszej blokady, na przykład 20 minut, a przy kolejnych naruszeniach dłuższy okres.
5. Dodaj własny adres IP do białej listy, jeśli wtyczka udostępnia taką opcję.
6. Włącz powiadomienia, aby otrzymywać informacje o przekroczeniu limitu.

Limit 3–5 prób sprawdzi się na małej stronie z jednym lub kilkoma administratorami. Przy witrynie z wieloma użytkownikami ustawienia trzeba dobrać ostrożniej, aby pojedyncza pomyłka nie blokowała dostępu całemu zespołowi.

Najpierw dodaj własny adres IP do białej listy, a dopiero później włącz restrykcyjne limity. Błędna konfiguracja, wspólna sieć biurowa albo nieaktualne hasło zapisane w telefonie mogą zablokować także prawowitego administratora.

Jeśli korzystasz z Cloudflare lub innego proxy, sprawdź, czy wtyczka otrzymuje prawdziwy adres IP użytkownika. Przy złej konfiguracji wszyscy odwiedzający mogą wyglądać jak jeden adres, co prowadzi do przypadkowych blokad. Gdy utracisz dostęp, tymczasowo zmień nazwę katalogu wtyczki przez FTP lub menedżer plików hostingu.

Dlaczego warto włączyć 2FA?

Limit prób chroni formularz logowania, ale nie rozwiązuje problemu wykradzionego hasła. Uwierzytelnianie dwuskładnikowe wymaga dodatkowego kodu z aplikacji uwierzytelniającej, klucza sprzętowego albo innego skonfigurowanego mechanizmu. Dzięki temu samo hasło nie wystarcza do przejęcia konta.

Włącz 2FA co najmniej dla wszystkich kont z rolą administratora. Procedura zwykle wygląda tak:

• Zainstaluj aktualną wtyczkę obsługującą 2FA.
• Połącz konto z aplikacją uwierzytelniającą, na przykład Google Authenticator.
• Zeskanuj kod QR i wpisz kod testowy wyświetlany w aplikacji.
• Zapisz kody zapasowe w bezpiecznym miejscu.
• Przetestuj ponowne logowanie w osobnej karcie lub przeglądarce.

2FA ogranicza także ryzyko związane z credential stuffing, czyli użyciem loginu i hasła wykradzionych z innego serwisu. Stosuj przy tym długie, unikalne hasła i nie używaj loginu „admin”, jeśli takie konto nadal istnieje.

Jak zablokować XML-RPC w WordPressie?

XML-RPC to punkt końcowy dostępny pod adresem /xmlrpc.php. Umożliwia zewnętrznym aplikacjom zdalne wykonywanie operacji w WordPressie, między innymi publikowanie treści. Jest też wykorzystywany do masowych prób logowania, dlatego może stać się dodatkowym wektorem brute force.

Jeśli nie używasz aplikacji mobilnej WordPress, Jetpacka ani starszych integracji, możesz zablokować ten plik na poziomie serwera. W przypadku Apache otwórz przez FTP lub menedżer plików plik .htaccess w katalogu głównym instalacji, wykonaj jego kopię i dodaj:

<Files xmlrpc.php>
    Order Allow,Deny
    Deny from all
</Files>

Reguła odrzuca żądania do XML-RPC, zanim trafią do PHP i WordPressa. Po zapisaniu zmian sprawdź działanie strony, logowanie, publikowanie treści oraz wszystkie zewnętrzne integracje.

Jeżeli XML-RPC musi pozostać dostępny tylko dla wybranych adresów, możesz ograniczyć dostęp do własnego IP lub adresu VPN:

<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
    Allow from 100.100.100.100
</Files>

Podmień przykładowy adres na własny. Stały adres IP jest w tym przypadku ważny, ponieważ zmienne adresy mogą ponownie odciąć potrzebną integrację. Serwery Nginx nie korzystają z pliku .htaccess, więc blokadę trzeba ustawić w konfiguracji serwera. Jeśli używasz Jetpacka lub aplikacji mobilnej, nie wyłączaj XML-RPC bez wcześniejszego testu.

Wtyczka działa na poziomie aplikacji, natomiast .htaccess działa wcześniej, na poziomie serwera. Z tego powodu blokada XML-RPC może ograniczyć obciążenie PHP, ale nie zastąpi limitu logowania ani 2FA.

Lista kontrolna po wdrożeniu

Przed zakończeniem konfiguracji sprawdź, czy wszystkie podstawowe warstwy ochrony są aktywne:

• Hasła administratorów są długie, unikalne i przechowywane w menedżerze haseł.
• Uwierzytelnianie 2FA działa na każdym koncie administratora.
• Limit logowania wynosi 3–5 prób, a czasowa blokada jest skonfigurowana.
• Własny adres IP znajduje się na białej liście, jeśli wymaga tego konfiguracja wtyczki.
• XML-RPC jest wyłączony albo ograniczony do niezbędnych adresów.
• WordPress, motyw i wtyczki mają aktualne wersje oraz istnieje świeża kopia zapasowa.

Po wdrożeniu obserwuj logi i alerty bezpieczeństwa. Jeśli liczba prób nadal rośnie, rozważ ochronę WAF na poziomie hostingu oraz dodatkowe ograniczenia ruchu. Nie zmieniaj kilku reguł serwera naraz bez kopii zapasowej, ponieważ błąd w .htaccess może spowodować niedostępność całej strony.