403 Forbidden: причины, решения и блокировки ботов, обманывающие мониторинг

403 против 401

RFC 9110 проводит границу четко. Код 401 Unauthorized означает, что нужна аутентификация или что предъявленные учетные данные не приняты, и ответ обязан нести заголовок WWW-Authenticate с описанием способа аутентификации. Код 403 Forbidden означает, что сервер отказывается авторизовать запрос, и повторный вход не поможет.

Спецификация также разрешает серверу отвечать 404 вместо 403, если он не хочет раскрывать даже существование ресурса. Поэтому URL, про который вы точно знаете, что он есть, с усиленно настроенного сервера может вернуться как «не найдено». Разбирая 403, помните, что обратный случай тоже бывает.

Что порождает 403

• Права в файловой системе. Процесс веб-сервера не может прочитать файл или войти в каталог. Классика после ручного копирования файлов или восстановления, сменившего владельца.
• Выключенный листинг каталога. Запрос папки без индексного файла возвращает 403 на серверах, настроенных не показывать содержимое. Поведение верное, ошибка сбивающая с толку.
• Правила авторизации в приложении. Пользователь вошел, но у него нет роли, тарифа или членства в организации, которых требует ресурс.
• Списки разрешенных и запрещенных IP. Административный путь, ограниченный офисными адресами, возвращает 403 всем остальным, включая любого, кто проверяет из дома или из мобильной сети.
• Правила межсетевого экрана уровня приложений. WAF блокирует запрос, у которого URL, заголовки или тело совпали с сигнатурой. Часто такой запрос выглядит для вас совершенно невинно.
• Географическая блокировка. Трафик из некоторых стран или регионов отклоняется на краевых серверах, и сайт работает с одного континента и запрещен с другого.
• Защита от хотлинка. Правило, отклоняющее запросы к картинкам и медиа, у которых заголовок Referer отсутствует или указывает на другой домен. Запросы вообще без реферера попадают под него случайно.
• Фильтрация ботов и user agent. Запрос блокируют за то, кем клиент себя называет, а не за то, что он просит. Именно этот случай ловит мониторинг.

Случай «403 для мониторов, 200 для людей»

Это самая частая ложная тревога в мониторинге доступности, и это не ошибка мониторинга. Сайт действительно возвращает 403, просто не браузерам.

Управление ботами на CDN или WAF оценивает каждый запрос по user agent, отпечатку TLS, порядку заголовков, репутации IP и по тому, проходит ли клиент JavaScript-испытание или интерактивную проверку. Автоматическая проверка HTTP по своей природе является автоматическим клиентом: она не выполняет JavaScript-испытания и честно себя называет. Поэтому ее блокируют или отправляют на проверку, пока ваш браузер проходит без задержки, и получается сайт, который шлет оповещение о недоступности, тогда как все люди подтверждают, что он работает.

Опознать это помогают два признака: 403 приходит мгновенно, а не после задержки, что исключает перегрузку, и он стабильно воспроизводится для автоматического клиента и никогда для браузера в той же сети.

Как добавить сервис мониторинга в белый список

1. Убедитесь, что блокировка привязана к личности клиента. Повторите запрос обычным HTTP-клиентом, а затем со строкой user agent от браузера, и сравните:

   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/

   Если коды разные, работает правило по user agent.
2. Найдите сработавшее правило. Панели WAF и CDN логируют заблокированные запросы вместе с идентификатором совпавшего правила. Это быстрее и безопаснее, чем гадать, какое правило ослабить.
3. Разрешайте по IP-адресу, если можете. Провайдеры мониторинга публикуют адреса своих точек проверки. Правило-исключение по ним точное и ничего не ослабляет для остальных.
4. Или разрешайте по user agent. Настройте проверку на отправку узнаваемого user agent и добавьте правило-исключение для него. Поддерживать это проще, чем список адресов, но относитесь к нему как к удобству, а не как к границе безопасности: user agent может скопировать кто угодно.
5. Предпочитайте исключение отключению защиты. Выведите путь или клиента мониторинга из-под конкретного правила, оставив остальной набор в силе.
6. Проверьте заново из нескольких регионов. Правило может применяться неравномерно по краевым площадкам, поэтому подтвердите починку больше чем из одного места, прежде чем закрывать задачу.

Как чинить 403, не связанный с ботами

1. Проверьте, должен ли этот URL быть публичным вообще. Половина разбирательств с 403 заканчивается выводом, что блокировка верна.
2. Проверьте владельца и права на самом пути и на каждом родительском каталоге. Процессу сервера нужно право на выполнение для каталогов, а не только право на чтение файла.
3. Поищите индексный файл, если URL это каталог, или осознанно включите листинг, если он нужен.
4. Прочитайте конфигурацию сервера на предмет правил запрета, ограничений по IP и проверок реферера для этого пути, а затем слой авторизации приложения.
5. Проверьте край раньше источника. Обратитесь к источнику напрямую. Код 403, исчезающий в обход CDN, это правило на крае, а не проблема приложения.

Как увидеть блокировку не из своей сети

Код 403, появившийся после обновления WAF или смены прав, изнутри не похож на сбой: ваша сессия аутентифицирована, ваш адрес в белом списке, а страницы, которые вы проверяете, как раз работают. Проверка HTTP по расписанию сверяет ожидаемый код на важных для вас адресах и делает это снаружи вашей сети, поэтому внезапно запрещенная страница поднимает оповещение сразу. Географические блокировки и краевые правила различаются по регионам, поэтому число точек обзора имеет значение: HostTracker проверяет из более чем 300 точек проверки в 158 городах, и это превращает «запрещено в некоторых странах» в видимую разницу между локациями. Если отказ временный и связан с объемом запросов, а не с личностью клиента, кодом обычно будет 429, о нем есть руководство по 429 Too Many Requests, а более широкое семейство разобрано в обзоре 4xx.