403 Forbidden: przyczyny, naprawy i blokady botów mylące monitoring

403 kontra 401

RFC 9110 jasno wyznacza granicę. 401 Unauthorized oznacza, że wymagane jest uwierzytelnienie albo że podane dane logowania nie zostały zaakceptowane, a odpowiedź musi nieść nagłówek WWW-Authenticate opisujący, jak się uwierzytelnić. 403 Forbidden oznacza, że serwer odmawia autoryzacji żądania, a ponowne uwierzytelnienie nic tu nie pomoże.

Specyfikacja pozwala też serwerowi odpowiedzieć 404 zamiast 403, gdy nie chce ujawniać, że zasób w ogóle istnieje. Dlatego URL, o którym wiesz, że tam jest, może wrócić jako "nie znaleziono" z utwardzonego serwera. Jeśli diagnozujesz 403, pamiętaj, że istnieje też przypadek odwrotny.

Co produkuje 403

• Uprawnienia systemu plików. Proces serwera WWW nie może odczytać pliku ani przejść przez katalog. Klasyczny przypadek po ręcznym skopiowaniu pliku albo przywróceniu, które zmieniło właściciela.
• Wyłączone listowanie katalogów. Żądanie folderu bez pliku indeksu zwraca 403 na serwerach skonfigurowanych, żeby odmawiać listowania. Poprawne zachowanie, mylący błąd.
• Reguły autoryzacji aplikacji. Użytkownik jest zalogowany, ale brakuje mu roli, planu albo przynależności do dzierżawcy wymaganej dla danego zasobu.
• Listy dozwolonych i zabronionych adresów IP. Ścieżka administracyjna ograniczona do adresów biurowych zwraca 403 dla wszystkich pozostałych, w tym każdego testującego z domu albo z sieci mobilnej.
• Reguły zapory aplikacji webowej (WAF). WAF blokuje żądanie, którego URL, nagłówki albo treść pasowały do sygnatury. Często żądanie wygląda dla Ciebie zupełnie niewinnie.
• Geoblokowanie. Ruch z niektórych krajów albo regionów jest odrzucany na brzegu sieci, więc strona działa z jednego kontynentu, a z innego jest zabroniona.
• Ochrona przed hotlinkowaniem. Reguła odrzucająca żądania obrazów albo mediów, których nagłówek Referer jest brakujący albo wskazuje na inną domenę. Żądania bez referrera bywają łapane przez przypadek.
• Filtrowanie botów i user agentów. Żądanie jest blokowane ze względu na to, za kogo podaje się klient, nie o co prosił. To ten przypadek, który łapie monitoring.

Przypadek "403 dla monitorów, 200 dla ludzi"

To najczęstszy fałszywy alarm w monitoringu uptime, i nie jest to błąd monitoringu. Strona naprawdę zwraca 403, tylko nie przeglądarkom.

Zarządzanie botami na CDN albo WAF ocenia każde żądanie na podstawie user agenta, odcisku palca TLS, kolejności nagłówków, reputacji IP i tego, czy rozwiązuje wyzwanie JavaScript albo interaktywne. Zautomatyzowana kontrola HTTP jest z założenia zautomatyzowanym klientem: nie uruchamia wyzwań JavaScript i uczciwie się identyfikuje. Więc dostaje wyzwanie albo blokadę, podczas gdy Twoja przeglądarka przechodzi bez problemu, a wynik to strona, która alertuje jako niedziałająca, podczas gdy każdy człowiek potwierdza, że działa.

Dwa znaki szybko to identyfikują: 403 przychodzi natychmiast, a nie po opóźnieniu, co wyklucza przeciążenie, i jest konsekwentne dla zautomatyzowanego klienta, a nigdy nie do odtworzenia w przeglądarce w tej samej sieci.

Jak dodać usługę monitoringu do listy dozwolonych

1. Potwierdź, że blokada jest oparta na tożsamości. Powtórz żądanie jako zwykły klient HTTP, a potem z ciągiem user agenta przeglądarki, i porównaj:

   curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
   curl -sS -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://example.com/

   Jeśli kody się różnią, robi to reguła user agenta.
2. Znajdź regułę, która zadziałała. Panele WAF i CDN logują zablokowane żądania wraz z identyfikatorem pasującej reguły. To szybsze i bezpieczniejsze niż zgadywanie, którą regułę poluzować.
3. Dodaj do listy dozwolonych po adresie IP tam, gdzie możesz. Dostawcy monitoringu publikują adresy, których używają ich punkty kontrolne. Dodanie ich jako reguły pomijającej jest precyzyjne i nie osłabia ochrony dla nikogo innego.
4. Albo dodaj do listy dozwolonych po user agencie. Skonfiguruj kontrolę, żeby wysyłała charakterystyczny user agent, i dodaj regułę, która go zwalnia. To łatwiejsze w utrzymaniu niż lista IP, ale traktuj to jako wygodę, a nie granicę bezpieczeństwa, bo user agenta może skopiować każdy.
5. Wybieraj regułę pomijającą zamiast wyłączania ochrony. Zwolnij ścieżkę albo klienta monitoringu z konkretnej reguły i pozostaw resztę zestawu reguł w mocy.
6. Przetestuj ponownie z kilku regionów. Reguła może być stosowana nierówno na różnych lokalizacjach brzegowych, więc zweryfikuj naprawę z więcej niż jednego miejsca, zanim zamkniesz zgłoszenie.

Naprawa 403, które nie dotyczy botów

1. Sprawdź, czy URL w ogóle powinien być publiczny. Połowa dochodzeń w sprawie 403 kończy się odpowiedzią, że blokada jest poprawna.
2. Zweryfikuj właściciela pliku i uprawnienia na ścieżce i każdym katalogu nadrzędnym. Proces serwera potrzebuje uprawnienia wykonania na katalogach, nie tylko odczytu na pliku.
3. Poszukaj pliku indeksu, jeśli URL to katalog, albo celowo włącz listowanie, jeśli jest pożądane.
4. Przeczytaj konfigurację serwera pod kątem reguł odmowy, ograniczeń IP i sprawdzania referrera na tej ścieżce, a potem warstwę autoryzacji aplikacji.
5. Sprawdź brzeg sieci przed źródłem. Zażądaj bezpośrednio od serwera źródłowego. 403, które znika, gdy ominiesz CDN, to reguła brzegowa, nie problem aplikacji.

Zobaczenie blokady spoza własnej sieci

403 wprowadzone przez aktualizację WAF albo zmianę uprawnień nie wygląda jak awaria od wewnątrz: Twoja sesja jest uwierzytelniona, Twój adres jest na liście dozwolonych, a strony, które sprawdzasz, to te, które działają. Zaplanowana kontrola HTTP asertuje oczekiwany kod na URL-ach, na których Ci zależy, spoza Twojej sieci, więc nowo zabroniona strona natychmiast wywołuje alert. Geoblokady i reguły brzegowe różnią się w zależności od regionu, więc liczba punktów obserwacji ma znaczenie: HostTracker sprawdza z ponad 300 punktów kontrolnych w 158 miastach, co zamienia "zabronione w niektórych krajach" w widoczną różnicę między lokalizacjami. Jeśli odmowa jest tymczasowa i związana z ilością żądań, a nie z tożsamością, kod zwykle będzie 429 zamiast tego, co opisuje przewodnik po 429 Too Many Requests, a szerszą rodzinę znajdziesz w przeglądzie 4xx.