Acceso denegado en este servidor: causas y soluciones

Qué significa el error

El texto no forma parte de ningún estándar, y por eso aparece con tantas formas distintas. Apache lo muestra a partir de una regla de directorio. ModSecurity y los paneles de control de hosting lo muestran cuando salta una regla. Una CDN o un WAF muestra su propia versión con logotipo y un número de referencia. AWS lo devuelve como un documento XML corto desde S3 o CloudFront. Todos dicen lo mismo a nivel HTTP: 403, denegado, y sin invitación a reintentar con credenciales.

Esa última parte lo separa de los errores con los que se confunde. Un 401 te pide autenticarte y espera un reintento. Un 404 dice que el recurso no está. Un 403 dice que el recurso está y que no lo vas a conseguir, y repetir la petición sin cambios producirá la misma respuesta. El estado en sí está tratado en 403 Forbidden; esta guía trata de averiguar qué capa dijo que no.

Empieza por saber si es cosa tuya o de todo el mundo, porque las soluciones no se parecen en nada. Si un compañero en otra red carga la página sin problema, quien está bloqueado eres tú. Si no puede cargarla nadie, el sitio está mal configurado.

Por qué ocurre

• Tu dirección IP está bloqueada. Una regla de cortafuegos o de WAF añadida tras varios inicios de sesión fallidos, un rastreador en tu red, o un bloqueo manual que nadie retiró.
• Límite de peticiones. Demasiadas peticiones en poco tiempo, algo fácil de provocar con una sesión de depuración a base de recargas o con una conexión de oficina compartida.
• Restricciones geográficas. Sitios limitados a un país, o que bloquean una región entera después de recibir abusos desde ella.
• Una IP compartida o con mala reputación. Los nodos de salida de VPN, el NAT de los operadores móviles y los rangos de hosting barato se bloquean a menudo en bloque por lo que hicieron otros usuarios.
• Reglas antibots que leen tu user agent. Las herramientas de línea de comandos, los navegadores sin interfaz y las cadenas de user agent poco habituales reciben una negativa donde un navegador normal pasa.
• Cookies obsoletas o una sesión rota. Un token de sesión caducado puede producir una negativa en lugar de una redirección a la página de inicio de sesión.
• Una extensión del navegador que quita o añade cabeceras, o un proxy corporativo que reescribe la petición.
• Permisos de archivos y directorios. El usuario del servidor web no puede leer el archivo ni atravesar un directorio superior.
• Sin archivo de índice y con el listado desactivado. Una petición a un directorio sin nada que servir y con Options -Indexes en vigor devuelve 403 en lugar de una página vacía.
• Una regla de denegación explícita. Un Require all denied en la configuración de Apache o un .htaccess olvidado de una ventana de mantenimiento.
• Un falso positivo del WAF. ModSecurity y conjuntos de reglas parecidos rechazan peticiones legítimas que contienen algo que se parece a un intento de inyección, a menudo en un campo de formulario o en una cadena de consulta.
• Permisos de almacenamiento en la nube. Una política de bucket de S3 o una configuración de acceso al origen en CloudFront que no permite leer el objeto.

Si eres el visitante

1. Confirma el código de estado en lugar de fiarte del texto de la página. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page te dice si esto es de verdad un 403 o un 401 o un 429 disfrazado con un mensaje parecido.
2. Abre la página en una ventana privada. Eso descarta las cookies y casi todas las extensiones de una sola vez. Que allí funcione significa que la solución está en tu perfil, no en el sitio.
3. Borra las cookies de ese sitio en concreto en lugar de borrarlo todo, y recarga.
4. Desactiva la VPN o el proxy y vuelve a intentarlo. Si entonces funciona, lo que se rechazó fue la dirección del nodo de salida, y cambiar a otra región suele resolverlo.
5. Prueba desde otra red, lo más fácil un teléfono con datos móviles. Es la forma más rápida de demostrar que lo bloqueado es tu dirección.
6. Desactiva las extensiones de una en una, empezando por los bloqueadores de anuncios, las herramientas de privacidad y todo lo que edite cabeceras.
7. Comprueba si el bloqueo es regional preguntando a alguien de otro país, o leyendo la página de bloqueo por si menciona tu ubicación.
8. Escribe al sitio con el número de referencia si la página de bloqueo lo muestra. Las páginas de WAF suelen imprimir un identificador de incidente que le permite al operador encontrar en segundos la regla exacta que saltó.

Si el sitio es tuyo

1. Lee primero el registro de errores. Nombra la causa de forma directa, y sin él todos los pasos siguientes son adivinar:

   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 registra un problema de permisos como "client denied by server configuration" o "Permission denied". nginx registra "directory index of ... is forbidden" o "open() ... failed (13: Permission denied)". Esos tres mensajes cubren la mayoría de los casos.
2. Comprueba los permisos de toda la ruta, incluido cada directorio superior. Un directorio en el que el servidor web no puede entrar deniega todo lo que hay debajo, por muy correcto que parezca el archivo en sí:

   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. Busca una regla de denegación en el vhost y en cada .htaccess bajo la raíz del documento. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html las encuentra todas de una pasada.
4. Añade un archivo de índice o activa el listado si la petición es a un directorio. Servir un 403 para un directorio a secas es el comportamiento por defecto, no un fallo.
5. Comprueba SELinux en los sistemas de la familia Red Hat, donde unos permisos de Unix correctos todavía no bastan: ls -Z /var/www/html y después sudo restorecon -Rv /var/www/html.
6. Encuentra la regla del WAF que saltó y corrige la petición o añade una excepción estrecha para esa regla y esa ruta. Apagar el conjunto de reglas entero para que el error desaparezca cambia un problema por otro peor.
7. Revisa la lista de bloqueos por si hay rangos añadidos durante un incidente. Los bloqueos temporales a los que nunca se les puso caducidad son una causa habitual de quejas semanas después.
8. Para S3 o CloudFront, revisa la política del bucket y la configuración de acceso al origen. El cuerpo XML nombra la operación que se denegó, lo que apunta al permiso concreto que hay que conceder.

Verifícalo desde fuera

Una negativa dirigida a una sola dirección se parece exactamente a una caída general del sitio vista desde esa dirección, y no puedes distinguirlas desde la máquina a la que se está denegando el acceso. Pregunta desde otro sitio.

Las cabeceras de respuesta suelen nombrar la capa que contestó. Mira Server y las cabeceras de proveedor como CF-Ray o X-Amz-Cf-Id, que te dicen si la negativa vino de tu origen o de un nodo de borde que nunca llegó a él:

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

Si el segundo comando devuelve 200 donde el primero devolvió 403, el bloqueo está en el user agent y tus permisos no tienen nada de malo. Después ejecuta la verificación HTTP contra la misma URL desde puntos de verificación de varios países a la vez. Un 403 desde todas las ubicaciones es un problema de configuración del sitio. Un 403 desde dos países y un 200 desde el resto es una regla geográfica o una lista de bloqueo regional, y a esa conclusión no llegas con un solo curl desde un escritorio.

Detectar un 403 que no querías

Las reglas de acceso se rompen de formas que no producen ningún error en tu lado. Se actualiza un conjunto de reglas de WAF, un script de renovación de certificados reescribe una configuración, se olvida un bloqueo temporal, y el sitio te sigue devolviendo 200 a ti mientras rechaza a una parte de los visitantes reales. Nada en tus propios registros parece alarmante, porque para el servidor un 403 es una negativa normal y correcta. Una verificación programada que lea el código de estado desde más de 300 puntos de verificación en 158 ciudades detecta el día en que una región empieza a recibir negativas, y avisa por correo electrónico, SMS, llamada de voz, Slack, Telegram y otros canales. Las demás guías están en el grupo de soluciones, y el código de estado que hay detrás de este mensaje tiene su propia referencia en 403 Forbidden.