Access denied on this server: причины и решения

Что означает эта ошибка

Сама формулировка не описана ни в одном стандарте, поэтому она и встречается в стольких видах. Apache печатает ее из правила для каталога. ModSecurity и хостинговые панели печатают ее при срабатывании правила. CDN или WAF печатает свою фирменную версию с номером обращения. AWS возвращает ее коротким XML-документом из S3 или CloudFront. На уровне HTTP все они говорят одно и то же: 403, отказано, и никакого приглашения повторить запрос с учетными данными.

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

Начните с вопроса, отказано вам одному или всем, потому что решения у этих случаев не совпадают. Если у коллеги из другой сети страница открывается, заблокированы вы. Если не открывается ни у кого, сайт настроен неверно.

Почему это происходит

• Ваш IP-адрес заблокирован. Правило брандмауэра или WAF, добавленное после неудачных попыток входа, скрапер в вашей сети или ручная блокировка, которую никто не снял.
• Ограничение частоты запросов. Слишком много запросов за короткое окно, что легко получить при отладке с постоянными перезагрузками или на общем офисном канале.
• Географические ограничения. Сайты, доступные только в одной стране, или блокировка целого региона после злоупотреблений оттуда.
• Общий адрес или адрес с плохой репутацией. Выходные узлы VPN, NAT мобильных операторов и дешевые хостинговые диапазоны часто блокируют целиком за то, что делали другие их пользователи.
• Правила против ботов, читающие user agent. Консольные утилиты, headless-браузеры и необычные строки user agent получают отказ там, где обычный браузер проходит.
• Устаревшие куки или сломанная сессия. Просроченный токен сессии может дать отказ вместо редиректа на страницу входа.
• Расширение браузера, которое вырезает или добавляет заголовки, либо корпоративный прокси, переписывающий запрос.
• Права на файлы и каталоги. Пользователь веб-сервера не может прочитать файл или войти в один из родительских каталогов.
• Нет индексного файла при выключенном листинге. Запрос каталога, в котором нечего отдать, при действующем Options -Indexes возвращает 403, а не пустую страницу.
• Явное правило запрета. Require all denied в конфигурации Apache или забытый .htaccess со времен технических работ.
• Ложное срабатывание WAF. ModSecurity и похожие наборы правил отказывают легитимным запросам, в которых есть что-то похожее на попытку инъекции, чаще всего в поле формы или в строке запроса.
• Права в облачном хранилище. Политика бакета S3 или настройка доступа CloudFront к источнику, которая не разрешает читать объект.

Если вы посетитель

1. Подтвердите код состояния, а не верьте тексту страницы. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page покажет, действительно ли это 403, а не 401 или 429 с похожим сообщением.
2. Откройте страницу в приватном окне. Это одним движением убирает куки и почти все расширения. Успех там означает, что чинить надо профиль, а не сайт.
3. Удалите куки именно этого сайта, а не все подряд, и перезагрузите страницу.
4. Выключите VPN или прокси и попробуйте снова. Если после этого заработало, отказ получал адрес выходного узла, и переключение на другой регион обычно решает вопрос.
5. Попробуйте другую сеть, проще всего телефон в мобильной сети. Это самый быстрый способ доказать, что блокируют именно ваш адрес.
6. Отключайте расширения по одному, начиная с блокировщиков рекламы, приватных надстроек и всего, что правит заголовки.
7. Проверьте, не региональная ли это блокировка, спросив кого-то в другой стране или поискав упоминание вашей локации на странице блокировки.
8. Напишите владельцам сайта с номером обращения, если он есть на странице блокировки. Страницы WAF обычно печатают идентификатор инцидента, по которому оператор за секунды найдет сработавшее правило.

Если сайт ваш

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

   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 пишет о проблеме с правами как "client denied by server configuration" или "Permission denied". nginx пишет "directory index of ... is forbidden" или "open() ... failed (13: Permission denied)". Эти три сообщения покрывают большинство случаев.
2. Проверьте права по всему пути, включая каждый родительский каталог. Каталог, в который веб-сервер не может войти, закрывает все, что лежит ниже, каким бы правильным ни выглядел сам файл:

   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. Поищите правило запрета в конфигурации виртуального хоста и в каждом .htaccess под корнем документов. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html находит их все за один проход.
4. Добавьте индексный файл или включите листинг, если запрашивают каталог. Отдавать 403 на голый каталог это поведение по умолчанию, а не поломка.
5. Проверьте SELinux в системах семейства Red Hat, где правильных прав Unix все равно недостаточно: ls -Z /var/www/html, затем sudo restorecon -Rv /var/www/html.
6. Найдите сработавшее правило WAF и либо исправьте запрос, либо добавьте узкое исключение для этого правила и этого пути. Отключение всего набора правил ради исчезновения ошибки меняет одну проблему на худшую.
7. Пересмотрите список блокировок на предмет диапазонов, добавленных во время инцидента. Временные блокировки, которым не поставили срок, это частая причина жалоб, приходящих неделями позже.
8. Для S3 или CloudFront проверьте политику бакета и настройку доступа к источнику. В теле XML названа отклоненная операция, и она указывает на конкретное право, которое надо выдать.

Проверка снаружи

Отказ, нацеленный на один адрес, с этого адреса выглядит ровно как общий сбой сайта, и с той машины, которой отказывают, эти два случая не различить. Спросите откуда-нибудь еще.

Заголовки ответа обычно называют слой, который ответил. Смотрите на Server и на заголовки вендоров вроде CF-Ray или X-Amz-Cf-Id: по ним видно, отказал ваш источник или краевой сервер, который до источника даже не дошел:

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

Если вторая команда возвращает 200 там, где первая вернула 403, блокировка привязана к user agent и с правами у вас все в порядке. Затем запустите проверку HTTP по тому же URL из точек проверки сразу в нескольких странах. Код 403 отовсюду это проблема конфигурации сайта. Код 403 из двух стран при 200 из остальных это географическое правило или региональный список блокировок, и к такому выводу нельзя прийти одним curl с одного рабочего места.

Как поймать 403, которого вы не планировали

Правила доступа ломаются так, что на вашей стороне никакой ошибки не видно. Обновился набор правил WAF, скрипт продления сертификата переписал конфигурацию, временную блокировку забыли снять, и сайт продолжает отвечать вам кодом 200, отказывая при этом части реальных посетителей. В ваших журналах ничего тревожного нет, потому что для сервера 403 это нормальный, успешно отданный отказ. Проверка по расписанию, читающая код состояния из более чем 300 точек проверки в 158 городах, ловит день, когда региону начали отказывать, и присылает оповещение по email, SMS, голосовым звонком, в Slack, Telegram и другими способами. Остальные руководства собраны в кластере починки, а у кода, стоящего за этим сообщением, есть свой справочник: 403 Forbidden.