Błąd 403 po wejściu do kokpitu WordPressa. Gdzie szukać blokady?

Adres kokpitu wpisany jak zawsze, a zamiast ekranu logowania pojawia się krótki komunikat „403 Forbidden” albo „Brak dostępu”. Strona dla klientów często działa przy tym bez zarzutu, co tylko utrudnia sprawę: nie da się dodać wpisu, zmienić ceny ani odebrać zamówienia. Kod 403 oznacza, że serwer zrozumiał żądanie, ale świadomie odmówił jego wykonania. Coś po drodze uznało, że tej osobie nie wolno wejść pod ten adres.

Ten tekst jest dla właścicieli firm i osób, które same opiekują się stroną na WordPressie i mają dostęp do panelu hostingu. Blokada może siedzieć w pięciu miejscach: we wtyczce bezpieczeństwa, w pliku .htaccess, w uprawnieniach plików, w zaporze serwera lub usługi pośredniczącej albo w samym WordPressie. Każde z nich sprawdza się inaczej i w innej kolejności.

Po lekturze czytelnik będzie umiał rozpoznać, które miejsce odpowiada za odmowę, zdjąć blokadę bez utraty danych i upewnić się, że kokpit został otwarty na stałe, a nie do następnego logowania.

Co oznacza błąd 403 i po czym poznać, kto go wysłał?

Błąd 403 różni się od pozostałych awarii WordPressa tym, że nic się nie zepsuło. Serwer działa, pliki są na miejscu, baza danych odpowiada. Odmowa jest decyzją: jakaś reguła, ustawienie albo zabezpieczenie stwierdziło, że dostęp się nie należy. Dlatego szukanie przyczyny polega na znalezieniu tej reguły, a nie na naprawianiu kodu strony.

Pierwszą wskazówką jest wygląd samej strony z błędem. Ten sam kod 403 wysyłają różne warstwy i każda robi to po swojemu.

• Surowa, biała strona z napisem „Forbidden” i zdaniem „You don’t have permission to access this resource” pochodzi od serwera WWW. Winny jest zwykle plik .htaccess, uprawnienia plików albo zapora serwera.
• Strona z logo i nazwą wtyczki bezpieczeństwa, często z informacją o zablokowanym adresie IP i czasie blokady, pochodzi od tej wtyczki.
• Strona z nazwą usługi pośredniczącej, na przykład sieci dostarczania treści z zaporą, oznacza, że żądanie w ogóle nie dotarło do serwera ze stroną.
• Szara ramka w stylu WordPressa z informacją o braku uprawnień do wyświetlenia strony pojawia się dopiero po zalogowaniu i dotyczy roli użytkownika, a nie serwera.
• Strona z logo firmy hostingowej oznacza zabezpieczenie włączone w panelu hostingu albo zaporę działającą po stronie dostawcy.

Druga wskazówka to zasięg blokady. Jeśli 403 pojawia się pod każdym adresem witryny, przyczyna leży zwykle w katalogu głównym: w pliku .htaccess, w uprawnieniach albo w braku pliku index.php. Jeśli dotyczy tylko adresów /wp-admin/ i /wp-login.php, najczęściej działa zabezpieczenie panelu logowania. Jeśli pojawia się wyłącznie przy jednej czynności, na przykład przy zapisie wpisu albo wgrywaniu pliku, prawie zawsze odpowiada za to zapora analizująca treść żądania.

Co sprawdzić w pierwszych pięciu minutach, zanim zacznie się zmieniać pliki?

Zanim ktokolwiek otworzy pliki na serwerze, należy wykluczyć przyczyny, które nie wymagają żadnej naprawy. Blokady adresu IP i blokady czasowe znikają same albo dotyczą tylko jednego komputera. Te kilka prób pozwala też zawęzić poszukiwania do jednej warstwy.

1. Otwarcie adresu kokpitu w oknie prywatnym przeglądarki. Jeśli tam ekran logowania się pojawia, problem dotyczy plików cookie lub pamięci przeglądarki i wystarczy je wyczyścić dla tej jednej witryny.
2. Wyłączenie na chwilę połączenia VPN i dodatków do przeglądarki, które zmieniają adres IP lub blokują skrypty. Zapory często odrzucają ruch z adresów używanych przez popularne usługi VPN.
3. Otwarcie kokpitu w telefonie z wyłączonym Wi-Fi, czyli przez sieć komórkową. Telefon ma wtedy inny adres IP niż komputer w biurze. Jeśli z telefonu kokpit się otwiera, zablokowany jest adres IP biura, a nie cała witryna.
4. Zanotowanie własnego adresu IP z komputera, na którym występuje błąd. Wyświetla go dowolna strona typu „jakie jest moje IP”, a często także sama strona z komunikatem o blokadzie.
5. Sprawdzenie, czy 403 występuje także na stronie głównej oraz pod adresem /wp-login.php, i zapisanie dokładnej godziny każdej próby.
6. Przypomnienie sobie, co zmieniło się tuż przed awarią: instalacja lub aktualizacja wtyczki, zmiana ustawień bezpieczeństwa, przeniesienie strony, wgranie plików przez FTP, zmiana w panelu hostingu.

Wynik tych prób od razu wskazuje kierunek. Kokpit dostępny z telefonu i niedostępny z biura to blokada adresu IP, czyli wtyczka bezpieczeństwa albo zapora. Kokpit niedostępny z każdego urządzenia to reguła w pliku .htaccess, uprawnienia plików albo zabezpieczenie włączone w panelu hostingu. Kilka nieudanych prób logowania przed awarią to zwykle blokada czasowa, która po kilkunastu lub kilkudziesięciu minutach wygasa sama.

Jak odczytać dziennik błędów serwera i co w nim znaleźć?

Każda odmowa dostępu zostawia ślad w dzienniku błędów serwera. To jedyne miejsce, w którym serwer mówi wprost, dlaczego odmówił. Dziennik znajduje się w panelu hostingu, zwykle w dziale o nazwie zbliżonej do „Logi”, „Dzienniki” albo „Statystyki i logi”. U części dostawców trzeba go najpierw włączyć, a u niektórych udostępnia go wyłącznie pomoc techniczna.

W dzienniku należy odszukać wiersze z godziną zanotowaną podczas prób i z własnym adresem IP. Treść wpisu zwykle jednoznacznie wskazuje warstwę, która odmówiła.

• Wpis zawierający słowa client denied by server configuration oznacza regułę w pliku .htaccess albo w konfiguracji serwera, która zabrania dostępu do katalogu lub pliku.
• Wpis zaczynający się od ModSecurity: Access denied with code 403 oznacza zaporę serwera. W dalszej części wiersza znajduje się numer reguły w polu id, który trzeba przekazać pomocy technicznej hostingu.
• Wpis ze słowami Permission denied oznacza złe uprawnienia albo złego właściciela pliku lub katalogu wymienionego w tym samym wierszu.
• Wpis informujący, że nie można wyświetlić zawartości katalogu, bo brakuje pliku startowego, oznacza brak pliku index.php w katalogu wskazanym we wpisie.

Brak jakiegokolwiek wpisu z tej godziny też jest informacją. Oznacza, że żądanie zostało zatrzymane, zanim dotarło do serwera WWW, czyli przez usługę pośredniczącą, albo że odmowy udzielił kod wtyczki działającej wewnątrz WordPressa. W obu przypadkach serwer niczego nie zapisuje, bo z jego punktu widzenia nic złego się nie stało.

Czy kokpit blokuje wtyczka bezpieczeństwa i jak ją bezpiecznie wyłączyć?

Wtyczki bezpieczeństwa to najczęstsze źródło błędu 403 w kokpicie, bo ochrona panelu logowania jest ich głównym zadaniem. Blokują adres IP po kilku błędnych hasłach, ograniczają logowanie do wybranych krajów, ukrywają adres logowania pod inną nazwą albo odrzucają żądania, które wyglądają podejrzanie. Wystarczy pomyłka w haśle powtórzona kilka razy, zmiana adresu IP w biurze albo zbyt surowe ustawienie po aktualizacji.

Dokumentacja WordPressa rozróżnia dwa rodzaje takich wtyczek. Jedne filtrują ruch w trakcie ładowania WordPressa, inne dopisują własne reguły do pliku .htaccess, żeby zatrzymać żądanie jeszcze przed uruchomieniem strony. Ta różnica ma praktyczne znaczenie: w drugim przypadku samo wyłączenie wtyczki nie wystarczy, bo jej reguły zostają w pliku.

Najpierw drogi, które nie wymagają wyłączania ochrony

Jeśli strona z błędem podaje czas blokady, najprościej jest go przeczekać i zalogować się poprawnym hasłem. Część wtyczek wysyła też na adres e-mail administratora wiadomość z odnośnikiem odblokowującym, dlatego należy przejrzeć skrzynkę razem z folderem ze spamem. Jeśli wtyczka zmieniła adres logowania, standardowy adres /wp-admin/ celowo zwraca odmowę i trzeba użyć adresu ustawionego w jej opcjach.

Wyłączenie wtyczek przez pliki, gdy kokpit jest niedostępny

Gdy te sposoby zawodzą, wtyczkę wyłącza się z poziomu plików. Potrzebny jest program do połączeń FTP albo „Menedżer plików” w panelu hostingu. Metoda opisana w oficjalnej dokumentacji WordPressa polega na zmianie nazwy katalogu z wtyczkami. Niczego nie usuwa i zachowuje ustawienia wtyczek.

1. Po połączeniu z serwerem należy przejść do katalogu, w którym zainstalowano WordPressa, a następnie do katalogu wp-content.
2. Jeśli wiadomo, która wtyczka odpowiada za ochronę, wystarczy wejść do katalogu plugins i zmienić nazwę tylko jej katalogu, dopisując na końcu na przykład .hold.
3. Jeśli nie wiadomo, zmienia się nazwę całego katalogu plugins na plugins.hold. Wyłącza to wszystkie wtyczki naraz.
4. Następnie trzeba otworzyć w przeglądarce adres witryny zakończony na /wp-admin/plugins.php i zalogować się. WordPress wyświetli informację, że nie znalazł plików wtyczek, i oznaczy je jako wyłączone.
5. Po zalogowaniu należy przywrócić katalogowi pierwotną nazwę plugins. Wtyczki wrócą na listę, ale pozostaną wyłączone.
6. W kokpicie, w menu „Wtyczki”, włącza się je po jednej przyciskiem „Włącz”, a po każdej otwiera kokpit w oknie prywatnym. Wtyczka, po której wraca błąd 403, jest źródłem blokady.

Trzeba mieć świadomość skutków. Przez czas trwania próby witryna działa bez wtyczek, więc klienci mogą zobaczyć stronę bez formularzy, bez koszyka albo w zmienionym układzie. Radzę przeprowadzać tę operację poza godzinami największego ruchu i nie zostawiać witryny w takim stanie dłużej niż kilka minut.

Jeśli po wyłączeniu wszystkich wtyczek błąd 403 nadal występuje, wtyczka mogła zostawić reguły w pliku .htaccess albo przyczyna leży zupełnie gdzie indziej. Po odzyskaniu dostępu nie należy zostawiać strony bez ochrony. Wtyczkę włącza się ponownie i poprawia ustawienie, które zadziałało zbyt surowo: usuwa własny adres IP z listy zablokowanych, wydłuża limit prób logowania albo wyłącza ograniczenie krajów.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a ja przejmę sprawę: ustalę, która warstwa odmawia dostępu do kokpitu, zdejmę blokadę i ustawię zabezpieczenia tak, żeby nie zamykały drogi właścicielowi.

Jak sprawdzić, czy dostęp blokuje plik .htaccess?

Plik .htaccess to plik konfiguracyjny serwera Apache, który działa w katalogu, w którym leży, i we wszystkich jego podkatalogach. WordPress używa go do obsługi przyjaznych adresów, a wtyczki bezpieczeństwa, wtyczki pamięci podręcznej i panele hostingu dopisują do niego własne reguły. Jedna błędna linijka potrafi odciąć dostęp do całej witryny, co opisałem szerzej w tekście o tym, jak działa przekierowanie 301 w pliku .htaccess.

W przypadku błędu 403 w kokpicie do sprawdzenia są dwa pliki: główny, leżący w katalogu z WordPressem obok pliku wp-config.php, oraz ewentualny drugi w katalogu wp-admin. Ten drugi nie występuje w czystej instalacji. Jeśli tam jest, utworzyła go wtyczka, panel hostingu albo osoba, która kiedyś zabezpieczała kokpit.

Nazwa pliku zaczyna się od kropki, więc wiele programów domyślnie go ukrywa. W menedżerze plików w panelu hostingu trzeba włączyć pokazywanie ukrytych plików, a w programie FileZilla służy do tego opcja wymuszenia wyświetlania ukrytych plików w menu „Serwer”.

Próba z wyłączeniem pliku

1. Pobranie pliku .htaccess z katalogu głównego na dysk komputera jako kopii, do której zawsze można wrócić.
2. Zmiana nazwy pliku na serwerze na .htaccess_stary. Serwer przestaje go wtedy czytać.
3. Otwarcie kokpitu w oknie prywatnym. Jeśli ekran logowania się pojawił, przyczyna jest w tym pliku.
4. Jeśli błąd nadal występuje, należy przywrócić plikowi nazwę i powtórzyć tę samą próbę z plikiem .htaccess w katalogu wp-admin, o ile istnieje.
5. Po zalogowaniu trzeba przejść w kokpicie do menu „Ustawienia”, potem „Bezpośrednie odnośniki”, i bez zmieniania czegokolwiek kliknąć „Zapisz zmiany”. WordPress utworzy nowy, czysty plik .htaccess ze swoimi regułami.
6. Sprawdzenie kilku podstron witryny, bo bez pliku .htaccess mogły przez chwilę zwracać błąd 404.

Jeśli WordPress nie może sam utworzyć pliku, tworzy się go ręcznie. Podstawowa zawartość dla pojedynczej witryny, podana w dokumentacji WordPressa, wygląda tak:

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Ten wzór dotyczy witryny zainstalowanej w katalogu głównym domeny. Instalacja w podkatalogu oraz sieć witryn mają inne reguły, dlatego w takich przypadkach bezpieczniej jest pozwolić WordPressowi wygenerować plik przez zapisanie bezpośrednich odnośników.

Które wiersze w starym pliku odcinają dostęp?

Nowy plik przywraca dostęp, ale stary zawierał też rzeczy potrzebne: przekierowania, reguły pamięci podręcznej, wymuszenie połączenia szyfrowanego. Trzeba je przenieść, pomijając tylko wiersze odpowiedzialne za odmowę. Stary plik otwiera się w zwykłym edytorze tekstu i szuka następujących zapisów:

• Require all denied oraz starsza postać Deny from all – zakaz dostępu dla wszystkich,
• Require ip oraz starsza postać Allow from z adresem IP – dostęp tylko z wymienionych adresów, zwykle z dawnego adresu biura,
• wiersze RewriteRule zakończone znacznikiem [F] lub [F,L] – reguły, które na wskazane adresy odpowiadają kodem 403,
• bloki Files lub FilesMatch obejmujące plik wp-login.php,
• wiersze AuthType i AuthUserFile – dodatkowe hasło do katalogu, które przy błędnej ścieżce do pliku z hasłami kończy się odmową.

Najczęstszy przypadek to ograniczenie dostępu do kokpitu do jednego adresu IP, ustawione kiedyś celowo. Dostawca internetu zmienił adres biura i właściciel sam znalazł się za drzwiami. Wystarczy wtedy wpisać w tym wierszu aktualny adres IP albo usunąć całe ograniczenie i zastąpić je ochroną, która nie zależy od adresu, na przykład weryfikacją dwuetapową przy logowaniu.

Własne reguły należy umieszczać poza znacznikami # BEGIN WordPress i # END WordPress, bo to, co znajduje się między nimi, WordPress może nadpisać. Podobne pary znaczników zostawiają wtyczki. Jeśli wtyczka jest wyłączona, a jej blok nadal znajduje się w pliku, reguły wciąż działają i to one mogą odpowiadać za odmowę.

Jedna uwaga dotycząca bezpieczeństwa. Jeśli w pliku znajdują się długie, nieczytelne ciągi znaków albo reguły przekierowujące na obce adresy, a nikt z zespołu ich nie dodawał, może to być ślad włamania. Sposób postępowania opisałem w tekście o tym, co robić, gdy strona na WordPressie została zainfekowana.

Jakie uprawnienia powinny mieć pliki i katalogi WordPressa?

Każdy plik i katalog na serwerze ma zapisane, kto może go czytać, zmieniać i uruchamiać. Zapis ma postać trzech cyfr, na przykład 644. Jeśli serwer WWW nie ma prawa odczytać pliku albo wejść do katalogu, odpowiada kodem 403. Uprawnienia zmieniają się najczęściej po przeniesieniu strony na inny serwer, po ręcznym wgraniu plików, po rozpakowaniu archiwum albo po próbie „naprawy” wykonanej według przypadkowej porady z sieci.

Dokumentacja WordPressa podaje dla typowego hostingu współdzielonego następujące wartości:

• katalogi: 755 lub 750,
• pliki: 644 lub 640,
• plik wp-config.php: 440 lub 400, żeby inni użytkownicy serwera nie mogli go odczytać,
• plik .htaccess: 644.

Ta sama dokumentacja stwierdza wprost, że żaden katalog nie powinien mieć uprawnień 777, nawet katalog z przesłanymi plikami. Wartość 777 pozwala każdemu procesowi na serwerze zmieniać zawartość katalogu. Część serwerów z tego właśnie powodu odmawia obsługi plików i katalogów z takimi uprawnieniami, więc ustawienie 777 „na próbę” potrafi samo wywołać błąd, zamiast go usunąć.

Sprawdzenie i poprawienie uprawnień

1. Po połączeniu z serwerem przez FTP lub w menedżerze plików należy odczytać uprawnienia katalogu z WordPressem oraz katalogów wp-admin, wp-includes i wp-content. Wartość widać w kolumnie z uprawnieniami albo we właściwościach elementu.
2. Następnie sprawdza się uprawnienia plików index.php i wp-login.php w katalogu głównym oraz pliku index.php w katalogu wp-admin.
3. Katalog z inną wartością niż 755 lub 750 trzeba poprawić: po kliknięciu prawym przyciskiem myszy wybiera się pozycję dotyczącą uprawnień lub praw pliku i w polu z wartością liczbową wpisuje 755.
4. Plik z inną wartością niż 644 lub 640 poprawia się w ten sam sposób, wpisując 644.
5. Jeśli błędnych elementów jest dużo, korzysta się z opcji stosowania zmiany do podkatalogów, ale osobno dla katalogów i osobno dla plików. Nadanie wszystkim elementom jednej wartości jest błędem.
6. Po zmianie otwiera się kokpit w oknie prywatnym.

Osoby z dostępem do serwera przez SSH mogą wykonać tę samą pracę dwoma poleceniami z dokumentacji WordPressa, wstawiając własną ścieżkę do instalacji:

find /sciezka/do/wordpressa/ -type d -exec chmod 755 {} \;
find /sciezka/do/wordpressa/ -type f -exec chmod 644 {} \;

Po ich wykonaniu trzeba osobno przywrócić ostrzejsze uprawnienia pliku wp-config.php. Polecenia uruchomione w złym katalogu zmienią uprawnienia plików, które nie należą do WordPressa, dlatego ścieżkę należy sprawdzić dwukrotnie.

Właściciel plików i brakujący plik index.php

Bywa, że cyfry są poprawne, a serwer nadal odmawia. Powodem może być właściciel plików. Według dokumentacji WordPressa wszystkie pliki powinny należeć do konta użytkownika hostingu, a nie do procesu serwera WWW ani do innego konta. Zły właściciel pojawia się po przeniesieniu strony albo po wgraniu plików z konta administratora serwera. Przez FTP zwykle nie da się tego zmienić i trzeba poprosić o to pomoc techniczną hostingu.

Druga rzadsza przyczyna to brak pliku startowego. Jeśli w katalogu głównym albo w katalogu wp-admin nie ma pliku index.php, serwer próbuje pokazać listę plików, a ponieważ jest to ze względów bezpieczeństwa wyłączone, odpowiada kodem 403. Zdarza się to po przerwanej aktualizacji lub niepełnym przeniesieniu strony. Brakujące pliki uzupełnia się z paczki instalacyjnej tej samej wersji WordPressa pobranej z oficjalnej strony projektu, wgrywając ponownie katalogi wp-admin i wp-includes. Katalogu wp-content i pliku wp-config.php nie wolno przy tym nadpisywać, bo zawierają treść i ustawienia witryny.

Co zrobić, gdy blokuje zapora serwera albo usługa pośrednicząca?

Wielu dostawców hostingu uruchamia na serwerach zaporę analizującą treść żądań. Najpopularniejszym otwartym rozwiązaniem tego typu jest ModSecurity. Zapora porównuje każde żądanie z zestawem reguł i odrzuca te, które przypominają atak. Czasem myli się i za atak bierze zwykłą pracę w kokpicie: zapis wpisu zawierającego fragment kodu, wklejenie skryptu w ustawieniach motywu, import pliku albo zapis strony w edytorze wizualnym.

Rozpoznanie jest dość proste. Do kokpitu da się zalogować, większość ekranów działa, a 403 pojawia się przy jednej, powtarzalnej czynności. W dzienniku błędów widać wtedy wpis zaczynający się od nazwy zapory. Właściciel strony na hostingu współdzielonym nie ma dostępu do konfiguracji zapory, więc jedyną poprawną drogą jest zgłoszenie do pomocy technicznej. Niektóre panele hostingu pozwalają wyłączyć zaporę dla domeny jednym przełącznikiem, ale radzę traktować to wyłącznie jako krótki test, a nie rozwiązanie.

Zgłoszenie powinno zawierać wszystko, czego technik potrzebuje, żeby znaleźć wpis w dzienniku bez dopytywania. Sprawdza się taka treść:

Dzień dobry, przy pracy w kokpicie WordPressa w domenie [adres domeny] serwer zwraca błąd 403. Dokładny adres, przy którym pojawia się błąd: [adres]. Czynność: [na przykład zapis wpisu]. Data i godzina próby: [godzina co do minuty]. Mój adres IP: [adres IP]. Proszę o sprawdzenie w dzienniku zapory, która reguła odrzuciła to żądanie, podanie jej numeru i wyłączenie tej jednej reguły dla mojej domeny albo odblokowanie mojego adresu IP, jeśli został zablokowany.

Usługa pośrednicząca i zabezpieczenia w panelu hostingu

Jeśli domena korzysta z usługi, która stoi między odwiedzającym a serwerem, czyli z sieci dostarczania treści z własną zaporą, odmowa może zapaść już tam. Strona z błędem nosi wtedy nazwę tej usługi i zwykle zawiera identyfikator zdarzenia. W panelu usługi należy otworzyć dziennik zdarzeń zapory, odszukać wpis z własnym adresem IP i godziną próby, a następnie odczytać, która reguła zadziałała. Najczęściej jest to blokada kraju, reguła chroniąca adres logowania albo ochrona przed automatami.

Na tej samej zasadzie działają zabezpieczenia włączane w panelu hostingu: blokada krajów, blokada adresów IP, ochrona panelu logowania WordPressa czy hasło na katalog. Trzeba przejrzeć w panelu działy związane z bezpieczeństwem i sprawdzić, czy któraś z tych funkcji nie obejmuje katalogu wp-admin. Jeśli kokpit jest niedostępny z zagranicy, a w kraju działa, odpowiedź prawie na pewno znajduje się w ustawieniach blokady krajów.

Błąd pojawia się dopiero po zalogowaniu. Kiedy blokuje sam WordPress?

Osobną grupą są sytuacje, w których logowanie przebiega poprawnie, a odmowę wyświetla sam WordPress w swojej szarej ramce z informacją o braku uprawnień do strony. Technicznie to także kod 403, ale serwer, zapora i plik .htaccess nie mają z nim nic wspólnego. WordPress uznał, że zalogowany użytkownik nie ma roli pozwalającej wejść na dany ekran.

Przyczyny są zwykle trzy. Pierwsza to zmiana roli konta, na przykład z administratora na redaktora, wykonana przez inną osobę albo wtyczkę do zarządzania rolami. Druga to wtyczka, która ukrywa część kokpitu przed wybranymi kontami. Trzecia to skutek przeniesienia strony ze zmianą przedrostka tabel w bazie danych: WordPress przechowuje role pod nazwami zawierającymi ten przedrostek i po niepełnej zmianie przestaje rozpoznawać administratora.

Najbezpieczniej jest poprosić innego administratora witryny o sprawdzenie roli konta w menu „Użytkownicy”. Jeśli drugiego administratora nie ma, pomaga wyłączenie wtyczek metodą opisaną wyżej. Poprawki w bazie danych wymagają już pewnej wprawy i zawsze powinna je poprzedzać kopia bazy. Gdy rola administratora zmieniła się bez wiedzy właściciela, trzeba to potraktować jako możliwe włamanie, a nie zwykłą usterkę.

Po czym poznać, że naprawa zadziałała na stałe?

Pojawienie się ekranu logowania to dopiero połowa pracy. Blokada, która wróci po godzinie albo przy pierwszym zapisie wpisu, jest gorsza od tej pierwszej, bo trafia na moment, w którym nikt się jej nie spodziewa. Dlatego po zdjęciu blokady należy otworzyć kokpit w oknie prywatnym z komputera, na którym błąd występował, oraz z drugiego urządzenia w innej sieci.

Następnie trzeba wykonać czynności, które zapory blokują najczęściej: zapisać istniejący wpis, wgrać obrazek do biblioteki mediów, zapisać ustawienia jednej z wtyczek. Na koniec należy przejrzeć kilka podstron witryny, formularz kontaktowy i, w sklepie, ścieżkę zamówienia. W dzienniku błędów serwera nie powinny pojawiać się nowe wpisy z odmową dla własnego adresu IP.

Gdy wszystko działa, radzę zapisać w notatkach, co było przyczyną i co zmieniono, a potem wykonać świeżą kopię witryny. Jak zrobić to porządnie, opisałem w tekście o tym, jak przygotować kopię zapasową WordPressa. Jeśli żadna z opisanych prób nie przyniosła skutku, pozostaje zgłoszenie do pomocy technicznej hostingu z kompletem danych: adresem, godziną, adresem IP i listą wykonanych już czynności.

Jakich błędów unikać przy zdejmowaniu blokady?

Najgroźniejszym błędem jest nadanie katalogom uprawnień 777 w nadziei, że „więcej uprawnień” otworzy kokpit. Nie otworzy, a zostawi witrynę podatną na zmianę plików przez obcy proces. Drugim jest usunięcie pliku .htaccess bez pobrania kopii. Razem z blokadą znikają wtedy przekierowania i reguły, których odtworzenie z pamięci bywa niemożliwe.

Trzeci błąd to trwałe wyłączenie wtyczki bezpieczeństwa albo zapory po odzyskaniu dostępu. Zabezpieczenie zadziałało zbyt surowo, ale było potrzebne, więc poprawia się jego ustawienia, a nie usuwa je całe. Czwarty to wykonywanie kilku zmian naraz. Po zmianie uprawnień, pliku .htaccess i wtyczek jednocześnie nie wiadomo, co pomogło, a co wprowadziło nową usterkę.

Odradzam też wielokrotne próby logowania w czasie trwania blokady. Każda kolejna próba może ją wydłużyć, a część wtyczek po serii prób zamienia blokadę czasową na stałą.

Najczęstsze pytania

Czy błąd 403 w kokpicie oznacza, że strona została zhakowana?

Zwykle nie. W zdecydowanej większości przypadków to skutek działania zabezpieczenia, błędnej reguły albo uprawnień zmienionych przy przenoszeniu plików. O włamaniu mogą świadczyć dopiero dodatkowe objawy: nieznane reguły w pliku .htaccess, obce konta administratorów, zmieniona rola własnego konta albo pliki, których nikt nie wgrywał.

Dlaczego strona dla klientów działa, a kokpit zwraca 403?

Ponieważ większość zabezpieczeń celowo obejmuje tylko adresy /wp-admin/ i /wp-login.php. To one są celem prób odgadnięcia hasła, więc wtyczki, zapory i reguły w pliku .htaccess pilnują właśnie ich. Część publiczna pozostaje otwarta dla każdego.

Czy wyłączenie wtyczek przez zmianę nazwy katalogu usuwa ich ustawienia?

Nie. Według dokumentacji WordPressa ta metoda zachowuje ustawienia wtyczek, a jedynym skutkiem jest konieczność ponownego włączenia każdej z nich w kokpicie.

Ile trwa blokada adresu IP po błędnych logowaniach?

Zależy to od ustawień konkretnej wtyczki lub zapory i nie ma jednej wartości. Blokady czasowe trwają zwykle od kilkunastu minut do kilku godzin, a po powtarzających się próbach mogą zostać zamienione na stałe. Dokładny czas podaje często sama strona z komunikatem albo wiadomość wysłana na adres administratora.

Czy błąd 403 w kokpicie szkodzi pozycjom strony w Google?

Sam kokpit nie jest przeznaczony do indeksowania, więc odmowa dostępu do niego nie ma wpływu na widoczność. Inaczej jest, gdy 403 obejmuje także strony publiczne: robot Google otrzymuje wtedy odmowę i przy dłuższej awarii adresy mogą wypaść z wyników. W takiej sytuacji naprawa jest pilna.

Czy można naprawić błąd 403 bez dostępu do FTP?

Częściowo. Większość paneli hostingu ma menedżer plików, który pozwala zmienić nazwę pliku lub katalogu i poprawić uprawnienia, a także dział z dziennikami i ustawieniami bezpieczeństwa. Bez dostępu do panelu hostingu pozostaje przeczekanie blokady czasowej, próba z innej sieci i kontakt z osobą lub firmą, która ten dostęp ma.

Co zrobić, gdy 403 pojawia się tylko przy zapisie wpisu albo wgrywaniu pliku?

Taki objaw wskazuje na zaporę analizującą treść żądania, po stronie serwera, usługi pośredniczącej albo wtyczki. Należy zanotować godzinę, adres i czynność, odszukać wpis w dzienniku i zgłosić sprawę pomocy technicznej hostingu z prośbą o wyłączenie jednej reguły. Jeśli zamiast odmowy pojawia się pusta strona lub inny kod, pomocny będzie tekst o tym, jak ustalić przyczynę, gdy występuje błąd 500 w WordPressie.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Zablokowany kokpit potrafi zatrzymać pracę firmy na cały dzień, a szukanie przyczyny w plikach serwera nie każdemu sprawia przyjemność. Chętnie zajmę się tym od początku do końca: sprawdzę dziennik błędów, ustalę, czy odmawia wtyczka, plik .htaccess, uprawnienia czy zapora, zdejmę blokadę bez utraty danych, a jeśli trzeba, przeprowadzę rozmowę z pomocą techniczną hostingu. Na koniec ustawię ochronę panelu logowania tak, żeby chroniła przed obcymi, a nie przed właścicielem, i opiszę prostymi słowami, co było przyczyną.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz treść komunikatu, który pojawia się zamiast kokpitu.