Access denied on this server: causas e correções

O que o erro significa

O texto não faz parte de nenhum padrão, e é por isso que ele aparece em tantos formatos diferentes. O Apache o imprime a partir de uma regra de diretório. O ModSecurity e os painéis de hospedagem o imprimem quando uma regra dispara. Uma CDN ou um WAF imprime a própria versão, com a marca deles e um número de referência. A AWS devolve o erro como um pequeno documento XML vindo do S3 ou do CloudFront. Todos dizem a mesma coisa no nível do HTTP: 403, recusado, e sem convite para tentar de novo com credenciais.

Essa última parte separa esse erro daqueles com que ele é confundido. Um 401 pede que você se autentique e espera uma nova tentativa. Um 404 diz que o recurso não está lá. Um 403 diz que o recurso está lá e você não vai recebê-lo, e repetir a requisição sem mudanças vai produzir a mesma resposta. O status em si é tratado em 403 Forbidden; este guia trata de descobrir qual camada disse não.

Comece descobrindo se é só com você ou com todo mundo, porque as soluções não têm nada em comum. Se um colega em outra rede carrega a página normalmente, o bloqueado é você. Se ninguém consegue carregar, o site está mal configurado.

Por que acontece

• O seu endereço IP está bloqueado. Uma regra de firewall ou WAF criada depois de logins que falharam, um raspador na sua rede ou um bloqueio manual que ninguém removeu.
• Limitação de taxa. Requisições demais em uma janela curta, o que é fácil de disparar em uma sessão de depuração cheia de recarregamentos ou numa conexão de escritório compartilhada.
• Restrições geográficas. Sites limitados a um país, ou bloqueando uma região inteira depois de abusos vindos de lá.
• Um IP compartilhado ou com má reputação. Nós de saída de VPN, NAT de operadoras móveis e faixas de hospedagem barata costumam ser bloqueados em bloco pelo que outros usuários fizeram.
• Regras antibô lendo o seu user agent. Ferramentas de linha de comando, navegadores headless e strings de user agent incomuns são recusadas onde um navegador normal passa.
• Cookies antigos ou uma sessão quebrada. Um token de sessão vencido pode gerar uma recusa em vez de um redirecionamento para a página de login.
• Uma extensão do navegador removendo ou adicionando cabeçalhos, ou um proxy corporativo reescrevendo a requisição.
• Permissões de arquivo e diretório. O usuário do servidor web não consegue ler o arquivo ou atravessar um diretório pai.
• Nenhum arquivo de índice, com listagem desligada. Uma requisição a um diretório sem nada para servir e com Options -Indexes em vigor devolve 403 em vez de uma página vazia.
• Uma regra explícita de negação. Um Require all denied na configuração do Apache ou um .htaccess esquecido de uma janela de manutenção.
• Um falso positivo do WAF. O ModSecurity e conjuntos de regras parecidos recusam requisições legítimas que contêm algo parecido com uma tentativa de injeção, muitas vezes em um campo de formulário ou em uma query string.
• Permissões de armazenamento em nuvem. Uma política de bucket do S3 ou uma configuração de acesso de origem do CloudFront que não permite a leitura do objeto.

Se você é o visitante

1. Confirme o código de status em vez de confiar no texto da página. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page diz se isso é mesmo um 403 ou um 401 ou 429 vestido com uma mensagem parecida.
2. Abra a página em uma janela anônima. Isso descarta cookies e a maioria das extensões de uma vez só. Se funcionar, a correção está no seu perfil, não no site.
3. Limpe os cookies só daquele site em vez de limpar tudo, e recarregue.
4. Desligue a VPN ou o proxy e tente de novo. Se funcionar, o endereço do nó de saída era o recusado, e trocar para outra região normalmente resolve.
5. Tente outra rede, o mais fácil sendo um celular na rede móvel. Esse é o jeito mais rápido de provar que o bloqueado é o seu endereço.
6. Desative as extensões uma a uma, começando por bloqueadores de anúncios, ferramentas de privacidade e qualquer coisa que edite cabeçalhos.
7. Veja se o bloqueio é regional perguntando a alguém em outro país, ou procurando uma menção à sua localização na página de bloqueio.
8. Fale com o site informando o número de referência, se a página de bloqueio mostrar um. Páginas de WAF normalmente imprimem um ID de incidente que permite ao operador achar em segundos a regra exata que disparou.

Se o site é seu

1. Leia o log de erros primeiro. Ele nomeia a causa diretamente, e todo passo depois deste é chute sem ele:

   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

   O Apache registra um problema de permissão como "client denied by server configuration" ou "Permission denied". O nginx registra "directory index of ... is forbidden" ou "open() ... failed (13: Permission denied)". Essas três mensagens cobrem a maioria dos casos.
2. Confira as permissões ao longo de todo o caminho, incluindo cada diretório pai. Um diretório em que o servidor web não consegue entrar recusa tudo que está abaixo dele, por mais correto que o arquivo em si pareça:

   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. Procure uma regra de negação no vhost e em cada .htaccess abaixo da raiz do documento. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html encontra todas de uma vez.
4. Adicione um arquivo de índice ou habilite a listagem se a requisição for para um diretório. Servir 403 para um diretório sem índice é o comportamento padrão, não um defeito.
5. Verifique o SELinux em sistemas da família Red Hat, onde permissões Unix corretas ainda não bastam: ls -Z /var/www/html, depois sudo restorecon -Rv /var/www/html.
6. Encontre a regra do WAF que disparou e então conserte a requisição ou adicione uma exceção estreita para aquela regra e aquele caminho. Desligar o conjunto de regras inteiro para o erro sumir troca um problema por outro pior.
7. Revise a lista de bloqueios em busca de faixas adicionadas durante um incidente. Bloqueios temporários que nunca receberam prazo de expiração são causa comum de reclamações semanas depois.
8. No S3 ou no CloudFront, confira a política do bucket e a configuração de acesso de origem. O corpo XML nomeia a operação recusada, o que aponta para a permissão específica a conceder.

Verifique de fora

Uma recusa dirigida a um único endereço parece exatamente uma queda geral do site quando vista desse endereço, e você não consegue distinguir as duas a partir da máquina que está sendo recusada. Pergunte de outro lugar.

Os cabeçalhos de resposta normalmente nomeiam a camada que respondeu. Olhe o Server e os cabeçalhos de fornecedores como CF-Ray ou X-Amz-Cf-Id, que dizem se a recusa veio da sua origem ou de uma borda que nunca chegou até ela:

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

Se o segundo comando devolve 200 onde o primeiro devolveu 403, o bloqueio é sobre o user agent e não há nada errado com as suas permissões. Depois rode a verificação HTTP contra a mesma URL a partir de pontos de verificação em vários países ao mesmo tempo. Um 403 de todas as localizações é um problema de configuração no site. Um 403 de dois países e 200 do resto é uma regra geográfica ou uma lista de bloqueio regional, conclusão a que você não chega com um curl só, de uma única mesa.

Detectar um 403 que você não quis

Regras de acesso quebram de formas que não geram erro nenhum do seu lado. Um conjunto de regras do WAF é atualizado, um script de renovação de certificado reescreve uma configuração, um bloqueio temporário é esquecido, e o site continua devolvendo 200 para você enquanto recusa uma fatia dos visitantes reais. Nada nos seus próprios logs parece alarmante, porque um 403 é uma recusa normal e bem-sucedida do ponto de vista do servidor. Uma verificação programada que lê o código de status a partir de mais de 300 pontos de verificação em 158 cidades detecta o dia em que uma região começa a ser recusada, e alerta por e-mail, SMS, chamada de voz, Slack, Telegram e outros canais. Os outros guias daqui estão no grupo de correções, e o código de status por trás desta mensagem tem sua própria referência em 403 Forbidden.