Jak skonfigurować wtyczkę Limit Login Attempts Reloaded

Próby logowania do WordPressa zaczynają się zwykle zanim strona zdąży zdobyć jakikolwiek ruch z Google. Boty nie sprawdzają, czy serwis jest duży, świeży, firmowy czy hobbystyczny. Wchodzą na /wp-login.php, testują loginy typu admin, administrator, nazwę domeny, imię autora wpisów, a czasem od razu uderzają w xmlrpc.php.

Limit Login Attempts Reloaded rozwiązuje jeden konkretny problem: ucina nielimitowane próby logowania. Nie zastępuje dobrego hasła, aktualizacji WordPressa, kopii zapasowych ani rozsądnych uprawnień użytkowników, ale usuwa sytuację, w której bot może przez całą noc zgadywać hasło bez żadnej reakcji ze strony witryny.

Najważniejsze jest ustawienie wtyczki tak, żeby blokowała automaty, ale nie odcinała administratora, redaktora albo klienta po kilku literówkach. Zbyt łagodne limity są dekoracją. Zbyt ostre limity potrafią zablokować legalnych użytkowników, szczególnie gdy strona działa za Cloudflare, proxy hostingu albo konfiguracją, która źle przekazuje prawdziwy adres IP.

Instalacja i pierwsze ustawienia wtyczki

Najprostsza instalacja wygląda tak: w panelu WordPressa przejdź do Wtyczki → Dodaj nową, wyszukaj Limit Login Attempts Reloaded, kliknij Zainstaluj, a potem Włącz. Ręczne wgrywanie paczki .zip ma sens tylko wtedy, gdy pracujesz na środowisku bez standardowego dostępu do katalogu wtyczek albo instalujesz konkretną wersję rozszerzenia.

Po aktywacji nie zaczynaj od dokręcania limitów. Najpierw sprawdź trzy rzeczy:

• czy ochrona jest aktywna,
• czy wtyczka rejestruje nieudane próby logowania,
• czy WordPress widzi prawdziwy adres IP użytkownika.

Ten trzeci punkt jest krytyczny. Jeżeli serwer widzi wszystkich odwiedzających jako jeden adres IP, jedna blokada może objąć boty, administratora i normalnych użytkowników. Efekt jest prosty: ktoś źle wpisuje hasło albo bot wykonuje serię prób, a po chwili legalna osoba nie może wejść do panelu.

Przy stronie działającej za Cloudflare sprawdź to od razu. Wejdź w ustawienia wtyczki i przejdź do zakładki Settings / Ustawienia. Następnie znajdź część związaną z aplikacją lokalną, zwykle opisaną jako App Settings → Local App, oraz sekcję Trusted IP Origins.

Na górze panelu wtyczka pokazuje wykrywany adres IP. Porównaj go z adresem, który widzisz po wejściu na dowolną stronę typu „what is my IP”. Jeżeli WordPress pokazuje adres Cloudflare albo adres proxy hostingu zamiast prawdziwego IP użytkownika, limity będą działały źle.

W typowej konfiguracji zacznij od REMOTE_ADDR, bo to najbezpieczniejsze źródło po stronie serwera. Jeżeli strona stoi za Cloudflare i REMOTE_ADDR wskazuje adres pośrednika, trzeba poprawić przekazywanie IP na poziomie hostingu albo w sekcji Trusted IP Origins wskazać nagłówek Cloudflare. W praktyce chodzi o CF-Connecting-IP, który w konfiguracjach PHP bywa widoczny jako HTTP_CF_CONNECTING_IP.

Nie zmieniaj tego ustawienia „bo tak jest w poradniku”. Zmień je dopiero wtedy, gdy widzisz konkretny problem: WordPress zapisuje IP Cloudflare zamiast IP odwiedzającego. Źle ustawione źródło IP może być gorsze niż brak zmiany, bo wtyczka zacznie ufać nagłówkowi, którego w danej konfiguracji nie powinna używać.

Priorytet konfiguracji jest taki:

1. najpierw poprawne wykrywanie IP,
2. potem limity prób logowania,
3. dopiero później safelista, denylista i dodatkowe blokady.

Jeżeli zaczniesz od agresywnych blokad bez sprawdzenia IP, możesz jednocześnie ograniczyć boty i zablokować własny zespół.

Limity logowania, blokady IP i lista zaufanych adresów

Wtyczka działa według prostego schematu: po określonej liczbie nieudanych prób logowania blokuje dalsze próby dla danego adresu IP lub użytkownika. To ogranicza ataki brute force, czyli automatyczne zgadywanie loginów i haseł.

Dla zwykłej strony firmowej rekomenduję taki punkt startowy:

• dozwolone próby logowania: 3 albo 4,
• czas pierwszej blokady: 20 minut,
• dłuższa blokada po powtarzających się blokadach: 24 godziny,
• liczba blokad przed wydłużeniem kary: 3,
• reset licznika prób: 12 godzin.

To jest konfiguracja wystarczająco ostra, żeby zatrzymać proste boty, ale jeszcze nie tak nerwowa, żeby blokować administratora po jednej pomyłce. Jeżeli jedna osoba nie potrafi wpisać hasła poprawnie po 3–4 próbach, powinna użyć resetu hasła, a nie próbować dalej na siłę.

Dla WooCommerce i serwisów z kontami klientów ustawienia powinny być łagodniejsze, bo tam pomyłki są częstsze. Bezpieczniejszy punkt startowy to:

• dozwolone próby logowania: 5,
• czas pierwszej blokady: 15 minut,
• dłuższa blokada: 12 godzin,
• wydłużenie blokady po: 4 blokadach,
• reset licznika prób: 6–12 godzin.

Sklep internetowy ma inne ryzyko niż firmowa wizytówka. Na stronie firmowej loguje się zwykle właściciel, agencja i czasem redaktor. W sklepie logują się klienci, którzy mylą hasła, wracają po kilku miesiącach, używają menedżerów haseł albo próbują odzyskać konto z telefonu. Zbyt ostry limit w WooCommerce zamieni ochronę w generator zgłoszeń do obsługi.

Dobry schemat decyzyjny wygląda tak:

• strona firmowa bez kont klientów — 3–4 próby, 20 minut blokady, dłuższa blokada 24 godziny po 3 blokadach;
• blog z kilkoma autorami — 4 próby, 20 minut blokady, obowiązkowy reset hasła przy powtarzających się problemach;
• WooCommerce — 5 prób, 15 minut blokady, ostrożne używanie denylisty;
• serwis członkowski — najpierw test na realnych użytkownikach, potem zaostrzanie limitów;
• strona za Cloudflare lub proxy — najpierw Trusted IP Origins, potem limity.

Najczęstszy błąd to ręczne blokowanie całych zakresów IP po pierwszym dniu logów. W logach może wyglądać to groźnie: dziesiątki prób, różne adresy, powtarzające się loginy. Nie każdy zakres warto jednak blokować. Część IP należy do operatorów komórkowych, VPN-ów, firmowych sieci, usług chmurowych albo dostawców internetu, z których mogą korzystać normalni użytkownicy.

Lepsza kolejność działań:

• sprawdź w logach, jakie loginy są atakowane;
• usuń konto admin, jeżeli nadal istnieje;
• nie publikuj wpisów z konta administratora, bo nazwa autora może zdradzać login;
• dodaj własny stały adres IP do safelisty, jeśli faktycznie masz stałe IP;
• ręcznie blokuj tylko te adresy lub zakresy, co do których masz uzasadnioną pewność;
• nie blokuj krajów, jeśli firma, klienci albo zespół mogą logować się z zagranicy.

Safelista jest przydatna, ale tylko przy stałym IP. Jeżeli pracujesz z domu na zmiennym adresie, wpisanie obecnego IP do safelisty da krótkotrwały efekt. Dzisiaj zadziała, jutro operator przydzieli inny adres i znowu możesz zostać potraktowany jak każdy inny użytkownik.

Wtyczka powinna chronić nie tylko klasyczny ekran logowania WordPressa. Sprawdź również ochronę dla:

• wp-login.php,
• /wp-admin/,
• xmlrpc.php,
• logowania WooCommerce,
• niestandardowych formularzy logowania, jeśli korzystają z mechanizmów WordPressa.

Szczególnie ważny jest XML-RPC. Boty lubią ten protokół, ponieważ endpoint xmlrpc.php pozwala wykonywać operacje poza standardowym formularzem logowania. Przy źle zabezpieczonej konfiguracji atakujący może używać mechanizmu multicall, czyli testować wiele kombinacji loginów i haseł w ramach jednego zapytania do serwera. To omija zwykłe „widzę formularz logowania, więc go chronię” i dlatego XML-RPC trzeba traktować osobno.

W ustawieniach zaawansowanych wtyczki upewnij się, że ochrona XML-RPC jest włączona. Jeżeli strona nie używa aplikacji mobilnej WordPressa, Jetpacka ani integracji wymagających XML-RPC, rozważ pełne wyłączenie XML-RPC na poziomie dodatkowej reguły bezpieczeństwa albo konfiguracji serwera. Sama wtyczka ograniczy próby, ale wyłączenie niepotrzebnego wejścia zmniejsza powierzchnię ataku.

Jest jeszcze procedura awaryjna. Jeżeli administrator sam się zablokuje, spróbuj najpierw wejść z innego IP, na przykład przez internet mobilny. Gdy to nie działa, zaloguj się do hostingu przez FTP albo menedżer plików i przejdź do katalogu:

wp-content/plugins/

Następnie zmień nazwę folderu:

limit-login-attempts-reloaded

na przykład na:

_limit-login-attempts-reloaded

WordPress automatycznie dezaktywuje wtyczkę, bo nie znajdzie jej pod właściwą nazwą. Po odzyskaniu dostępu przywróć poprawną nazwę folderu, wejdź do panelu WordPressa i kliknij Włącz przy wtyczce. Samo przywrócenie nazwy folderu nie zawsze oznacza, że ochrona znowu działa. Trzeba ją ponownie aktywować i dopiero wtedy poprawić konfigurację.

Kiedy wystarczy wersja darmowa, a kiedy rozważyć Premium

Darmowa wersja Limit Login Attempts Reloaded wystarczy na wielu stronach firmowych, blogach i prostych serwisach WordPress. Jej główne zadanie to ograniczenie prób logowania, prowadzenie logów i blokowanie podejrzanej aktywności po przekroczeniu limitu.

To ma realną wartość, bo czysty WordPress nie jest projektowany jako kompletna zapora przed powtarzalnym zgadywaniem haseł. Jeżeli wcześniej strona przyjmowała nielimitowane próby logowania, nawet prosta blokada po 3–4 błędach jest dużą zmianą.

Darmowa wersja wystarczy, jeżeli:

• prowadzisz zwykłą stronę firmową albo blog,
• do panelu loguje się mały zespół,
• liczba prób logowania jest umiarkowana,
• hosting działa stabilnie,
• masz dostęp awaryjny przez FTP lub menedżer plików,
• nie potrzebujesz blokowania krajów ani globalnych list złośliwych IP.

Premium ma sens dopiero wtedy, gdy problem jest większy niż kilka lub kilkadziesiąt prób logowania dziennie. Jeżeli boty generują setki albo tysiące żądań, darmowa blokada nadal działa, ale część ruchu i tak dociera do serwera. Przy słabszym hostingu może to oznaczać wyższe użycie CPU, wolniejszy panel albo komunikaty od dostawcy hostingu.

Wersję płatną warto rozważyć, gdy:

• strona regularnie łapie setki lub tysiące prób logowania,
• ataki obciążają hosting,
• logowanie dotyczy klientów, sklepu albo kont użytkowników,
• zarządzasz wieloma stronami,
• potrzebujesz ochrony chmurowej, IP intelligence, automatyzacji denylisty albo blokowania krajów,
• chcesz szybciej reagować na powtarzalne adresy złośliwego ruchu.

Aktualny cennik trzeba sprawdzić przed zakupem, bo promocje i warunki subskrypcji mogą się zmieniać. W czerwcu 2026 r. producent pokazywał m.in.:

• Premium — 25,99 zł miesięcznie albo 259,99 zł rocznie, z promocyjną ceną 194,99 zł za pierwszy rok;
• Premium Plus — 35,99 zł miesięcznie albo 359,99 zł rocznie, z promocyjną ceną 269,99 zł za pierwszy rok;
• Professional — 54,99 zł miesięcznie albo 529,99 zł rocznie, z promocyjną ceną 397,49 zł za pierwszy rok;
• Agency — od 149,99 zł miesięcznie dla pakietu 10 domen, z promocyjną ceną 93,12 zł miesięcznie przy rozliczeniu rocznym w pierwszym roku.

Są też warianty lifetime dla części planów, ale nie kupowałbym ich w ciemno. Najpierw trzeba sprawdzić, czy strona rzeczywiście potrzebuje płatnych funkcji. Kupowanie Premium tylko dlatego, że „bezpieczeństwo jest ważne”, to słaba decyzja. Bezpieczeństwo jest ważne, ale budżet powinien rozwiązywać konkretny problem.

Najpierw włącz darmową wersję, ustaw limity, sprawdź IP, przejrzyj logi po kilku dniach i dopiero wtedy zdecyduj. Jeżeli widzisz kilka prób dziennie na login admin, popraw nazwę użytkownika i hasła. Jeżeli widzisz tysiące żądań, spadki wydajności i powtarzalne ataki na xmlrpc.php, wtedy Premium zaczyna mieć sens.

FAQ — najczęstsze pytania o Limit Login Attempts Reloaded

Czy Limit Login Attempts Reloaded jest darmowa?
Tak. Wtyczka ma wersję darmową dostępną w katalogu WordPressa. Producent oferuje też płatne plany Premium z funkcjami takimi jak ochrona chmurowa, IP intelligence, denylista, blokowanie krajów i bardziej rozbudowane logi.

Ile prób logowania ustawić na stronie firmowej?
Dla typowej strony firmowej ustaw 3–4 dozwolone próby, 20 minut pierwszej blokady i 24 godziny dłuższej blokady po 3 kolejnych blokadach. To dobry kompromis między ochroną przed botami a wygodą administratora.

Jak ustawić limity w sklepie WooCommerce?
Zacznij od 5 prób i 15 minut blokady. Klienci częściej mylą hasła niż administratorzy, więc zbyt agresywne limity szybko zwiększą liczbę zgłoszeń do obsługi.

Co zrobić, jeśli wtyczka pokazuje zły adres IP pod Cloudflare?
Wejdź w Settings / Ustawienia → App Settings → Local App → Trusted IP Origins. Najpierw sprawdź, czy REMOTE_ADDR pokazuje prawdziwe IP użytkownika. Jeżeli pokazuje IP Cloudflare, popraw konfigurację hostingu albo ustaw źródło IP na nagłówek Cloudflare, czyli CF-Connecting-IP / HTTP_CF_CONNECTING_IP.

Czy warto dodać swoje IP do safelisty?
Tak, ale tylko jeśli masz stały adres IP. Przy zmiennym IP safelista działa tymczasowo i może dać fałszywe poczucie bezpieczeństwa.

Czy wtyczka chroni XML-RPC?
Tak, ale trzeba sprawdzić, czy ochrona XML-RPC jest aktywna w konfiguracji. Boty atakują xmlrpc.php, bo ten endpoint pozwala próbować logowania poza standardowym formularzem, a mechanizm multicall może pakować wiele prób w jedno zapytanie.

Czy najlepiej całkowicie wyłączyć XML-RPC?
Jeżeli strona nie korzysta z aplikacji mobilnej WordPressa, Jetpacka ani integracji wymagających XML-RPC, wyłączenie XML-RPC jest rozsądną decyzją. Nie zostawiaj aktywnego wejścia tylko dlatego, że „może kiedyś się przyda”.

Czy wtyczka spowolni stronę?
Przy normalnym ruchu nie powinna być zauważalnym obciążeniem. Problem może pojawić się przy mocnym ataku, bo w darmowej wersji część żądań nadal trafia do hostingu. Wtedy sprawdź logi, użycie CPU i liczbę prób logowania.

Co zrobić, jeśli administrator został zablokowany?
Spróbuj wejść z innego IP, na przykład przez internet mobilny. Jeżeli to nie działa, przez FTP albo menedżer plików zmień nazwę folderu wp-content/plugins/limit-login-attempts-reloaded, zaloguj się do WordPressa, przywróć poprawną nazwę folderu i ponownie kliknij Włącz przy wtyczce.

Czy sama wtyczka wystarczy do zabezpieczenia WordPressa?
Nie. To ochrona logowania, a nie pełny system bezpieczeństwa. Nadal potrzebujesz mocnych haseł, aktualizacji WordPressa, ograniczonej liczby kont administratorów, kopii zapasowych i usunięcia nieużywanych wtyczek.

Od czego zacząć konfigurację?
Zacznij od sprawdzenia IP. Potem ustaw 3–4 próby, 20 minut blokady i dłuższą blokadę 24 godziny po 3 powtórzeniach. Dopiero po kilku dniach logów decyduj o denyliście, blokowaniu krajów albo Premium.