Access denied on this server: причини та виправлення

Що означає ця помилка

Це формулювання не частина жодного стандарту, тому воно з'являється в такій кількості різних форм. Apache друкує його з правила директорії. ModSecurity і хостингові панелі керування друкують його, коли спрацьовує правило. CDN чи WAF друкує власну брендовану версію з номером звернення. AWS повертає його як короткий XML-документ від S3 чи CloudFront. Усі вони кажуть одне й те саме на рівні HTTP: 403, відмовлено, і жодної пропозиції спробувати ще раз із обліковими даними.

Саме ця остання деталь відрізняє його від помилок, з якими його плутають. 401 просить автентифікуватися і очікує на повторну спробу. 404 каже, що ресурсу немає. 403 каже, що ресурс є, але ви його не отримаєте, і повторення того самого запиту дасть ту саму відповідь. Сам статус описано в посібнику 403 Forbidden; цей посібник про те, як з'ясувати, який саме рівень сказав "ні".

Почніть із того, щоб з'ясувати, чи це стосується лише вас, чи всіх, бо способи виправлення не мають нічого спільного. Якщо колега з іншої мережі відкриває сторінку нормально, заблоковані саме ви. Якщо не може ніхто, сайт неправильно налаштований.

Чому це трапляється

• Вашу IP-адресу заблоковано. Правило фаєрвола чи WAF, додане після невдалих спроб входу, скрейпер у вашій мережі, або ручне блокування, яке ніхто не зняв.
• Обмеження частоти запитів. Забагато запитів за короткий проміжок часу, що легко спричинити сесією налагодження з частими перезавантаженнями або спільним офісним з'єднанням.
• Географічні обмеження. Сайти, обмежені однією країною, або блокування цілого регіону після зловживань із нього.
• Спільна чи позначена "поганою репутацією" IP-адреса. Вихідні вузли VPN, NAT мобільного оператора й дешеві хостингові діапазони часто блокують групою за дії інших користувачів.
• Правила проти ботів, що читають ваш user agent. Інструменти командного рядка, headless-браузери й незвичні рядки user agent отримують відмову там, де звичайний браузер пропускають.
• Застарілі кукі чи зламана сесія. Прострочений токен сесії може дати відмову замість перенаправлення на сторінку входу.
• Розширення браузера, що прибирає чи додає заголовки, або корпоративний проксі, що переписує запит.
• Права доступу до файлів і директорій. Користувач вебсервера не може прочитати файл чи пройти через батьківську директорію.
• Немає індексного файлу, а лістинг вимкнено. Запит до директорії, коли нема чого віддавати, і діє Options -Indexes, повертає 403 замість порожньої сторінки.
• Явне правило заборони. Require all denied у конфігурації Apache або забутий .htaccess після вікна обслуговування.
• Хибне спрацювання WAF. ModSecurity й подібні набори правил відмовляють у легітимних запитах, що містять щось схоже на спробу ін'єкції, часто в полі форми чи в рядку запиту.
• Права доступу хмарного сховища. Політика бакета S3 чи налаштування доступу до origin у 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. Пошукайте правило заборони у vhost і в кожному .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 перевірте політику бакета й конфігурацію доступу до origin. Тіло XML називає операцію, у якій відмовлено, що й указує на конкретний потрібний дозвіл.

Перевірте ззовні

Відмова, спрямована на одну адресу, виглядає точнісінько як загальносайтовий збій із цієї адреси, і з машини, якій відмовляють, відрізнити ці два випадки неможливо. Запитайте звідкись іще.

Заголовки відповіді зазвичай називають рівень, що відповів. Погляньте на Server і на заголовки постачальників, як-от CF-Ray чи X-Amz-Cf-Id, які показують, чи відмова прийшла від вашого origin, чи від краю мережі, який до нього навіть не дістався:

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 містах, ловить той день, коли якийсь регіон починає отримувати відмови, і сповіщає електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами. Інші посібники тут зібрані в розділі виправлень, а код статусу за цим повідомленням має власний довідник у 403 Forbidden.