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 deniedw 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
- Potwierdź kod statusu zamiast ufać tekstowi strony.
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/pagepokaże, czy to naprawdę 403, czy 401 albo 429 przebrane za podobny komunikat. - 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.
- Wyczyść ciasteczka konkretnie dla tej strony zamiast czyścić wszystko, a potem odśwież.
- 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.
- Wypróbuj inną sieć, najłatwiej telefon na danych mobilnych. To najszybszy sposób, żeby udowodnić, że blokowany jest Twój adres.
- Wyłączaj rozszerzenia po jednym, zaczynając od blokerów reklam, narzędzi prywatności i wszystkiego, co edytuje nagłówki.
- Sprawdź, czy blokada jest regionalna, pytając kogoś w innym kraju albo szukając na stronie blokady wzmianki o Twojej lokalizacji.
- 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
- Najpierw przeczytaj log błędów. Wskazuje przyczynę wprost, a każdy kolejny krok bez niego to zgadywanie:
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.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 - 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 - Poszukaj reguły odmowy w vhoście i w każdym pliku
.htaccesspod katalogiem głównym dokumentów.sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/htmlznajdzie je za jednym razem. - Dodaj plik indeksu albo włącz listowanie, jeśli żądanie dotyczy katalogu. Zwracanie 403 dla samego katalogu to zachowanie domyślne, nie błąd.
- Sprawdź SELinux w systemach z rodziny Red Hat, gdzie same poprawne uprawnienia unixowe wciąż nie wystarczą:
ls -Z /var/www/html, a następniesudo restorecon -Rv /var/www/html. - 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.
- 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.
- 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.