Zmiana URL logowania WordPress (/wp-login.php)

Otwórz log dostępu witryny WordPress, która jest online dłużej niż kilka dni, i wyszukaj wp-login.php. Znajdziesz setki, często tysiące linii adresów IP, o których nigdy nie słyszałeś, wszystkie próbujące popularnych kombinacji nazw użytkownika i haseł. Logowanie WordPress jest jednym z najmocniej atakowanych endpointów w publicznym internecie, po prostu dlatego, że URL jest uniwersalny. Każda witryna WordPress na świecie serwuje formularz logowania na /wp-login.php i /wp-admin. To czyni trywialnie łatwym dla botnetów atakowanie na dużą skalę.

Przeniesienie URL logowania do czegoś niestandardowego nie rozwiązuje podstawowego problemu (ktoś z prawdziwym zainteresowaniem Twoją konkretną witryną i tak znajdzie nowy URL), ale usuwa witrynę z milionów automatycznych list, które skrapują domyślny endpoint. W praktyce to powoduje spadek ruchu logowania o 95% lub więcej, co jest znaczącą wygraną już tylko z perspektywy obciążenia serwera. Ten przewodnik wyjaśnia, co zmiana faktycznie osiąga, różne sposoby jej wdrożenia i pułapki, których należy unikać.

Co zmiana URL logowania robi a czego nie robi

Warto być precyzyjnym tutaj, ponieważ temat jest źle przedstawiany w obu kierunkach. Niektóre przewodniki sprzedają to jako kompletną obronę, inne odrzucają to jako teatr bezpieczeństwa. Dokładna pozycja leży między nimi.

Co robi dobrze:

• Zatrzymuje automatyczne botnety celujące bezpośrednio w /wp-login.php. Zdecydowana większość ruchu brute-force to głupie skrypty iterujące przez listy słów. Nie szukają nowego URL, ponieważ wymaga to prawdziwej wizyty i parsowania HTML.
• Usuwa Cię z list filtrów "logowanie WordPress obecne", które skanery budują, aby szybko znaleźć cele.
• Drastycznie zmniejsza obciążenie serwera i szum logów. Na zajętych witrynach to wystarczający powód sam w sobie.
• Ogranicza niezamierzoną widoczność admina. Strona logowania już wycieka przez swoje istnienie: komunikaty błędów, favicon, logo WordPress, wersja szablonu logowania. Ukrycie URL ukrywa to wszystko.

Czego nie robi:

• Zatrzymania zdeterminowanego atakującego konkretnie celującego w Twoją witrynę. Znajdą nowy URL przez jeden z: przekierowanie po wylogowaniu, e-mail resetu hasła, który linkuje do nowego URL, ścieżkę cookie, wyciekły link w Twoim CMS, lub po prostu zgadując popularne slugi.
• Zastąpienia silnych haseł lub uwierzytelniania dwuskładnikowego. URL logowania to warstwa przed faktycznym uwierzytelnianiem. Prawdziwą obroną jest nadal to, co jest na formularzu, nie gdzie formularz stoi.
• Ochrony przed podatnościami na poziomie aplikacji. Jeśli wtyczka ma błąd zdalnego wykonania kodu, URL logowania jest nieistotny.

Pragmatyczne ujęcie: zmiana URL logowania jest zmianą o wysokim zwrocie i niskim wysiłku, która adresuje jedną konkretną klasę ataków (nieukierunkowane automatyczne brute-forcing). Dobrze pasuje do silnych haseł, 2FA i rate limitera, ale nie zastępuje żadnego z nich.

Zalecany sposób: WPS Hide Login (lub odpowiednik)

Dla 95% witryn najczystszym rozwiązaniem jest darmowa wtyczka WPS Hide Login. Jest mała (poniżej 100KB), aktywnie utrzymywana od lat, ma ponad milion aktywnych instalacji i robi dokładnie jedną rzecz: zmienia slug URL logowania. Brak upsellów, brak panelu ustawień wypchanego nieistotnymi funkcjami.

Konfiguracja zajmuje minutę:

1. Zainstaluj WPS Hide Login z katalogu wtyczek.
2. Aktywuj.
3. Przejdź do Ustawienia, WPS Hide Login.
4. Wprowadź swój nowy slug w polu "URL logowania". Przykłady: moje-tajne-logowanie, backstage, access-2347. Unikaj oczywistych wyborów takich jak admin, secret, login, Twoja nazwa domeny z dodanym numerem itp.
5. Opcjonalnie ustaw "URL przekierowania" dla wizyt na starym /wp-login.php. Domyślne zachowanie zwraca 404, co jest tym, czego chcesz przeciwko skanerom. Niestandardowe przekierowanie na stronę główną też jest w porządku.
6. Zapisz.

Od tego momentu https://twojadomena.pl/wp-login.php zwraca 404 dla osób z zewnątrz, a Ty logujesz się przez https://twojadomena.pl/moje-tajne-logowanie. Dodaj nowy URL do zakładek natychmiast. Wtyczka nie przechowuje sluga w miejscu widocznym z zewnątrz, więc jeśli zapomnisz URL i nie masz dostępu FTP, masz problem (chociaż jest ścieżka odzyskiwania opisana poniżej).

Alternatywa: niestandardowy slug bez wtyczki

Jeśli wolisz nie dodawać dodatkowej wtyczki, możesz zaimplementować ten sam efekt w kodzie. Umieść to we wtyczce must-use pod wp-content/mu-plugins/custom-login-url.php:

<?php
/**
 * Plugin Name: Custom Login URL
 * Description: Hides /wp-login.php behind a custom slug.
 */

if (!defined('ABSPATH')) {
    exit;
}

const CUSTOM_LOGIN_SLUG = 'my-secret-login';

add_action('init', function () {
    $requestUri = isset($_SERVER['REQUEST_URI']) ? (string) $_SERVER['REQUEST_URI'] : ';
    $path = parse_url($requestUri, PHP_URL_PATH) ?? ';
    $path = trim($path, '/');

    // Allow access via the custom slug by serving wp-login.php
    if ($path === CUSTOM_LOGIN_SLUG) {
        require_once ABSPATH . 'wp-login.php';
        exit;
    }

    // Block direct access to the default login URL
    if (preg_match('#(^|/)wp-login\.php$#', $path)) {
        status_header(404);
        nocache_headers();
        include get_404_template();
        exit;
    }
});

// Rewrite the URL in emails and login redirects
add_filter('site_url', function ($url, $path) {
    if (str_contains((string) $path, 'wp-login.php')) {
        return str_replace('wp-login.php', CUSTOM_LOGIN_SLUG, $url);
    }
    return $url;
}, 10, 2);

add_filter('wp_redirect', function ($location) {
    return str_replace('wp-login.php', CUSTOM_LOGIN_SLUG, $location);
});

Zaletą tego podejścia jest pełna kontrola i zero zależności wtyczek. Wadą jest, że musisz to utrzymywać sam, a przypadki brzegowe (multisite, niestandardowe przepływy rejestracji, niektóre pagebuildery używające formularza logowania) potrzebują dodatkowej obsługi. Dla większości witryn WPS Hide Login jest naprawdę bardziej praktyczną odpowiedzią.

Wybór dobrego sluga

Slug musi tylko nie być oczywisty, nie kryptograficznie tajny. Kilka praktycznych reguł:

• Unikaj popularnych wariantów "login", "admin" lub "wp". Skanery, które idą dalej niż /wp-login.php, zwykle mają listę: /login, /admin, /secure-login, /wp-secret, /backend, /dashboard. Wybierz coś, czego nie ma na tej liście.
• Wybierz coś łatwego do zapamiętania dla Ciebie, nie losowego. Slug, który możesz wpisać z pamięci, jest w porządku. moj-kot-tofu jest znacznie lepszy niż k7Hg2P, ponieważ ten drugi zapisujesz w menedżerze haseł, a tego pierwszego nie zapominasz.
• Nie używaj domeny lub nazwy firmy. example-login na example.com to pierwsza rzecz, którą próbuje ukierunkowany atakujący.
• Małe litery, brak znaków specjalnych. URL-e są technicznie wrażliwe na wielkość liter, ale prawdziwi użytkownicy stale błędnie wpisują wielkie litery. Slug z małymi literami zapobiega całej tej klasie ticketów "nie mogę się zalogować".

Częste pułapki i przypadki brzegowe

Garść rzeczy psuje się lub zachowuje nieoczekiwanie, gdy przenosisz URL logowania. Warto wiedzieć z wyprzedzeniem.

• Strona "Moje konto" WooCommerce. Logowanie klienta na /moje-konto/ to osobny przepływ i nie jest dotknięte zmianą. Ukrywasz tylko logowanie admina. Klienci WooCommerce logują się normalnie.
• Wtyczki uwierzytelniania dwuskładnikowego. Większość głównych wtyczek 2FA (Wordfence, WP 2FA, miniOrange itd.) działa dobrze z WPS Hide Login. Haczykują w proces logowania na warstwie poniżej URL i nie obchodzi ich, gdzie formularz stoi. Przetestuj po aktywacji.
• REST API i XML RPC. Zmiana URL logowania nie wpływa na /wp-json/ ani /xmlrpc.php. Jeśli masz aplikacje uwierzytelniające się przeciwko tym endpointom, nadal działają jak wcześniej. Jeśli nie używasz aktywnie XML RPC, to dobry moment, aby go całkowicie wyłączyć (osobny przewodnik w naszej bazie wiedzy).
• Wtyczki cache. Niektóre agresywne cache stron (LiteSpeed Cache z edge caching, Cloudflare APO) mogą cache'ować nowy URL logowania lub, gorzej, cache'ować zalogowaną odpowiedź administratora i serwować ją niezalogowanym odwiedzającym. Po zmianie odwiedź nowy URL w prywatnym oknie. Jeśli widzisz zalogowany widok administratora, cache jest zepsuty; opróżnij go i dodaj slug do listy wykluczeń cache.
• E-maile resetu hasła. Zarówno WPS Hide Login, jak i powyższy fragment kodu automatycznie przepisują URL resetu hasła, ale niestandardowe wtyczki e-mail lub integracje e-maili transakcyjnych czasami zakodowują wp-login.php w swoich szablonach. Po zmianie wyślij testowy reset hasła do siebie.
• Instalacje w podkatalogu i multisite. Oba działają, ale uważaj, czy slug jest dodany do niewłaściwego URL bazowego. Jeśli WordPress jest w /blog/, nowy URL to https://twojadomena.pl/blog/moje-tajne-logowanie, nie https://twojadomena.pl/moje-tajne-logowanie.

Odzyskiwanie: co zrobić, jeśli zablokujesz sobie dostęp

To się zdarza. Ustawiasz slug, wylogowujesz się, zamykasz kartę, a tydzień później nie pamiętasz, czy użyłeś myślników, podkreśleń ani co było trzecim słowem. Nie utknąłeś, ale ścieżka odzyskiwania zależy od użytej metody.

Jeśli użyłeś WPS Hide Login: dezaktywuj wtyczkę przez SFTP. Przemianuj folder wp-content/plugins/wps-hide-login na wps-hide-login.disabled, lub usuń go całkowicie. Domyślny URL /wp-login.php natychmiast wraca. Zaloguj się, znajdź swój slug w ustawieniach wtyczki, następnie ponownie aktywuj wtyczkę. Lub alternatywnie, spójrz bezpośrednio do bazy danych WordPress: slug jest przechowywany w tabeli wp_options pod kluczem whl_page.

Jeśli użyłeś niestandardowego kodu: SFTP do wp-content/mu-plugins/, otwórz plik, odczytaj slug ze stałej CUSTOM_LOGIN_SLUG. Lub tymczasowo przemianuj plik, aby go wyłączyć, zaloguj się, następnie przywróć go z powrotem.

W obu przypadkach zapisz URL gdzieś trwale, gdy tylko go ustawisz. Menedżer haseł, dokumentacja projektu, cokolwiek przeżyje utratę zakładki przeglądarki.

Jak zweryfikować, że zmiana jest aktywna

1. Otwórz https://twojadomena.pl/wp-login.php w prywatnym oknie. Oczekiwany rezultat: strona 404.
2. Ta sama kontrola dla https://twojadomena.pl/wp-admin/. Powinno również przekierować na 404, nie na formularz logowania.
3. Otwórz nowy URL https://twojadomena.pl/moje-tajne-logowanie. Powinien pokazać standardowy formularz logowania WordPress.
4. Zaloguj się normalnie, wyloguj, kliknij link "Wyloguj". Przekierowanie powinno wylądować na nowym URL, nie na /wp-login.php.
5. Wyzwól reset hasła dla siebie. Link w e-mailu powinien wskazywać na nowy URL.
6. Uruchom nowy skan InspectWP. Kontrole dotyczące URL logowania powinny odzwierciedlać nowy stan.

Po zweryfikowaniu jedyne ciągłe utrzymanie to upewnienie się, że wtyczka (lub Twój niestandardowy kod) nadal działa poprzez aktualizacje core WordPress, co powinno. Jeśli duża aktualizacja kiedykolwiek zmieni sposób, w jaki przepływ logowania działa wewnętrznie, WPS Hide Login jest jedną z pierwszych wtyczek, która wydaje łatkę, zwykle w ciągu dni.

Cała zmiana to pół godziny pracy dla trwałego zmniejszenia powierzchni ataku i zauważalnego spadku obciążenia serwera. Nie ma dobrego powodu, aby pozostawić logowanie WordPress w domyślnej lokalizacji na witrynie produkcyjnej.