Przejdź do treści głównej

Poradniki / Napraw to: poradniki na błędy, które naprawdę się zdarzają

Access denied on this server: przyczyny i naprawa

"Access denied on this server" oznacza, że serwer otrzymał Twoje żądanie, zrozumiał je i odmówił jego obsłużenia. Strona istnieje, a maszyna działa. Coś między żądaniem a plikiem zdecydowało, że nie wolno Ci go dostać, i prawie zawsze towarzyszy temu status HTTP 403.

Co oznacza ten błąd

Ten tekst nie jest częścią żadnego standardu, dlatego pojawia się w tylu różnych wersjach. Apache wypisuje go na podstawie reguły katalogu. ModSecurity i panele hostingowe wypisują go, gdy zadziała reguła. CDN albo WAF wypisuje własną markową wersję z numerem referencyjnym. AWS zwraca go jako krótki dokument XML z S3 lub CloudFront. Wszystkie one mówią na poziomie HTTP to samo: 403, odmowa, i żadnego zaproszenia, żeby spróbować ponownie z danymi logowania.

Ta ostatnia cecha odróżnia go od błędów, z którymi bywa mylony. 401 prosi o uwierzytelnienie i oczekuje ponowienia próby. 404 mówi, że zasobu nie ma. 403 mówi, że zasób jest, ale go nie dostaniesz, a powtórzenie niezmienionego żądania da ten sam wynik. Samemu statusowi poświęcony jest artykuł 403 Forbidden; ten przewodnik dotyczy ustalenia, która warstwa odmówiła.

Zacznij od ustalenia, czy problem dotyczy tylko Ciebie, czy wszystkich, bo rozwiązania nie mają ze sobą nic wspólnego. Jeśli kolega w innej sieci wczytuje stronę bez problemu, to Ty jesteś zablokowany. Jeśli nikt nie może jej wczytać, strona jest źle skonfigurowana.

Dlaczego tak się dzieje

  • Twój adres IP jest zablokowany. Reguła zapory sieciowej lub WAF dodana po nieudanych próbach logowania, scraper w Twojej sieci albo ręczna blokada, której nikt nie usunął.
  • Ograniczenie liczby żądań (rate limiting). Zbyt wiele żądań w krótkim oknie czasowym, co łatwo wywołać intensywnym odświeżaniem podczas debugowania albo współdzielonym łączem biurowym.
  • Ograniczenia geograficzne. Strony ograniczone do jednego kraju albo blokujące cały region po nadużyciach z niego pochodzących.
  • Współdzielony adres IP lub adres z zapisem reputacji. Węzły wyjściowe VPN, NAT operatorów mobilnych i tanie zakresy hostingowe są często blokowane jako grupa za to, co zrobili inni użytkownicy.
  • Reguły antybotowe czytające Twojego user agenta. Narzędzia wiersza poleceń, przeglądarki headless i nietypowe ciągi user agenta są odrzucane tam, gdzie zwykła przeglądarka ma dostęp.
  • Przestarzałe ciasteczka lub zepsuta sesja. Wygasły token sesji może wywołać odmowę zamiast przekierowania na stronę logowania.
  • Rozszerzenie przeglądarki usuwające lub dodające nagłówki, albo firmowe proxy przepisujące żądanie.
  • Uprawnienia plików i katalogów. Użytkownik serwera WWW nie może odczytać pliku ani przejść przez katalog nadrzędny.
  • Brak pliku indeksu przy wyłączonym listowaniu. Żądanie katalogu, gdy nie ma czego serwować, a w mocy jest Options -Indexes, zwraca 403 zamiast pustej strony.
  • Jawna reguła odmowy. Require all denied w konfiguracji Apache albo pozostawiony po oknie serwisowym plik .htaccess.
  • Fałszywy alarm WAF. ModSecurity i podobne zestawy reguł odrzucają prawidłowe żądania zawierające coś przypominającego próbę wstrzyknięcia, często w polu formularza lub ciągu zapytania.
  • Uprawnienia magazynu w chmurze. Polityka bucketu S3 albo ustawienie dostępu źródła CloudFront, które nie pozwala odczytać obiektu.

Jeśli jesteś odwiedzającym

  1. Potwierdź kod statusu zamiast ufać tekstowi strony. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page pokaże, czy to naprawdę 403, czy 401 albo 429 przebrane za podobny komunikat.
  2. Otwórz stronę w oknie prywatnym. To jednym ruchem usuwa ciasteczka i większość rozszerzeń. Sukces w takim oknie oznacza, że problem leży po stronie Twojego profilu, nie strony.
  3. Wyczyść ciasteczka konkretnie dla tej strony zamiast czyścić wszystko, a potem odśwież.
  4. Wyłącz VPN lub proxy i spróbuj ponownie. Jeśli wtedy zadziała, to adres węzła wyjściowego był odrzucany, a przełączenie na inny region zwykle to rozwiązuje.
  5. Wypróbuj inną sieć, najłatwiej telefon na danych mobilnych. To najszybszy sposób, żeby udowodnić, że blokowany jest Twój adres.
  6. Wyłączaj rozszerzenia po jednym, zaczynając od blokerów reklam, narzędzi prywatności i wszystkiego, co edytuje nagłówki.
  7. Sprawdź, czy blokada jest regionalna, pytając kogoś w innym kraju albo szukając na stronie blokady wzmianki o Twojej lokalizacji.
  8. Skontaktuj się ze stroną, podając numer referencyjny, jeśli strona blokady go pokazuje. Strony WAF zwykle wypisują identyfikator incydentu, dzięki któremu operator w kilka sekund znajdzie konkretną regułę, która zadziałała.

Jeśli jesteś właścicielem strony

  1. Najpierw przeczytaj log błędów. Wskazuje przyczynę wprost, a każdy kolejny krok bez niego to zgadywanie:
    sudo tail -50 /var/log/apache2/error.log
    sudo tail -50 /var/log/nginx/error.log
    sudo grep -i modsecurity /var/log/apache2/error.log | tail -20
    Apache loguje problem z uprawnieniami jako "client denied by server configuration" albo "Permission denied". nginx loguje "directory index of ... is forbidden" albo "open() ... failed (13: Permission denied)". Te trzy komunikaty pokrywają większość przypadków.
  2. Sprawdź uprawnienia na całej ścieżce, włącznie z każdym katalogiem nadrzędnym. Katalog, do którego serwer WWW nie może wejść, odmawia dostępu do wszystkiego poniżej, choćby sam plik wyglądał poprawnie:
    namei -l /var/www/html/index.html
    sudo chmod 755 /var/www/html
    sudo chmod 644 /var/www/html/index.html
    sudo chown -R www-data:www-data /var/www/html
  3. Poszukaj reguły odmowy w vhoście i w każdym pliku .htaccess pod katalogiem głównym dokumentów. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html znajdzie je za jednym razem.
  4. Dodaj plik indeksu albo włącz listowanie, jeśli żądanie dotyczy katalogu. Zwracanie 403 dla samego katalogu to zachowanie domyślne, nie błąd.
  5. Sprawdź SELinux w systemach z rodziny Red Hat, gdzie same poprawne uprawnienia unixowe wciąż nie wystarczą: ls -Z /var/www/html, a następnie sudo restorecon -Rv /var/www/html.
  6. Znajdź regułę WAF, która zadziałała, i albo popraw żądanie, albo dodaj wąski wyjątek dla tej reguły i tej ścieżki. Wyłączenie całego zestawu reguł, żeby błąd zniknął, zamienia jeden problem na gorszy.
  7. Przejrzyj listę blokad pod kątem zakresów dodanych podczas incydentu. Tymczasowe blokady, którym nigdy nie ustawiono terminu wygaśnięcia, to częsta przyczyna skarg wiele tygodni później.
  8. Dla S3 lub CloudFront sprawdź politykę bucketu i konfigurację dostępu źródła. Treść XML wskazuje operację, której odmówiono, co naprowadza na konkretne uprawnienie do nadania.

Sprawdź to z zewnątrz

Odmowa skierowana do jednego adresu wygląda dokładnie jak awaria całej strony widziana z tego adresu, a z maszyny, której odmawiają, nie da się tych dwóch sytuacji odróżnić. Zapytaj skądinąd.

Nagłówki odpowiedzi zwykle wskazują warstwę, która odpowiedziała. Spójrz na Server oraz nagłówki dostawców, takie jak CF-Ray czy X-Amz-Cf-Id, które mówią, czy odmowa przyszła z Twojego serwera źródłowego, czy z brzegu sieci, który do niego nawet nie dotarł:

curl -sS -D - -o /dev/null https://example.com/page
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.com/page

Jeśli drugie polecenie zwróci 200 tam, gdzie pierwsze zwróciło 403, blokada dotyczy user agenta i z Twoimi uprawnieniami wszystko jest w porządku. Następnie uruchom kontrolę HTTP na tym samym adresie URL jednocześnie z punktów kontrolnych w kilku krajach. 403 z każdej lokalizacji to problem konfiguracyjny strony. 403 z dwóch krajów i 200 z pozostałych to reguła geograficzna albo regionalna lista blokad - wniosek, do którego nie dojdziesz jednym curl z jednego biurka.

Wyłapanie 403, którego nie planowałeś

Reguły dostępu psują się w sposób, który po Twojej stronie nie daje żadnego błędu. Zestaw reguł WAF się aktualizuje, skrypt odnowienia certyfikatu przepisuje konfigurację, tymczasowa blokada zostaje zapomniana, a strona wciąż zwraca Tobie 200, jednocześnie odmawiając części prawdziwych odwiedzających. Nic w Twoich własnych logach nie wygląda alarmująco, bo z punktu widzenia serwera 403 to normalna, udana odmowa. Zaplanowana kontrola odczytująca kod statusu z ponad 300 punktów kontrolnych w 158 miastach wyłapie dzień, w którym region zacznie dostawać odmowy, i zaalarmuje e-mailem, SMS-em, telefonicznie, przez Slack, Telegram i więcej. Pozostałe przewodniki znajdziesz w klastrze napraw, a status HTTP stojący za tym komunikatem ma własny opis w artykule 403 Forbidden.

Sprawdź teraz

Uruchom darmowe sprawdzenie na swojej stronie - bez zakładania konta.

HTTP check

Monitoruj to na stałe

Otrzymasz powiadomienie w chwili awarii: HostTracker sprawdza z ponad 300 lokalizacji i powiadamia e-mailem, SMS-em, przez Slack, Telegram i nie tylko.

Funkcje HostTracker

Więcej w tej sekcji: Napraw to: poradniki na błędy, które naprawdę się zdarzają