Un error prohibido 403 ocurre con mayor frecuencia cuando nuestros sistemas de seguridad están protegiendo su sitio. La mayoría de las veces, nuestro firewall de aplicaciones web (llamado Mod Security o modsec) protege su sitio web de intentos de piratería automatizados.
Sin embargo, en algunos casos, las acciones legítimas pueden identificarse incorrectamente como un ataque y su acción será bloqueada. Esto se llama falso positivo. Aquí hay algunos escenarios comunes cuando esto sucede:
- Usando cualquier creador de sitios web, es posible que no se guarden los cambios
- Si usa el generador/tema Divi para WordPress, indicará algo como "Error al guardar la página" y luego proporcionará una lista de posibles causas.
- Al agregar código javascript o PHP a través del panel de administración de su sitio web (y no el Administrador de archivos Plesk o FTP).
Si recibe un error prohibido 403 que no coincide con una de las acciones anteriores, puede consultar primero nuestra guía general para solucionar errores 403.
Esto puede suceder aparentemente de la nada porque nuestras reglas de firewall se actualizan semanalmente; potencialmente agregando nuevas reglas cada semana que podrían afectar el funcionamiento de su sitio. Tenga en cuenta que es más probable que las reglas afecten al envío datos al servidor, como al enviar un formulario o actualizar datos en el backend de su sitio.
Cómo encontrar e interpretar registros de cortafuegos
El primer paso es verificar los registros del servidor para averiguar por qué proporciona ese error. Consulte nuestra guía sobre cómo usar el administrador de archivos Plesk para analizar los registros de su sitio web.
Debido a que nuestro firewall de aplicaciones web ayuda a bloquear ataques comunes, es posible que vea muchas entradas de ModSecurity en el registro . Es importante identificar las entradas de registro que directamente corresponde con la acción que está tomando, de lo contrario, terminará debilitando el firewall y no resolviendo el problema al mismo tiempo.
Los errores relacionados con el cortafuegos tendrán un aspecto similar a este:
ModSecurity: Access denied with code 403 (phase 2).
Pattern match "(asfunction|data|javascript|livescript|mocha|vbscript):" at ARGS:input_5_7_data_canvas.
[file "/etc/httpd/conf/modsecurity.d/rules/comodo/07_XSS_XSS.conf"] [line "227"]
[id "212770"] [rev "4"]
[msg "COMODO WAF: XSS Attack Detected||customerdomain.tld|F|2"]
[data "Matched Data: data: found within ARGS:input_5_7_data_canvas: data:image/png;base64,{{{{snipped}}}}]
[severity "CRITICAL"] [hostname "customerdomain.tld"]
[uri "/specific_uri_requested/"] Nuestra entrada de registro de ejemplo anterior es un falso positivo que ocurrió al enviar un formulario de Gravity Forms con una imagen adjunta.
Recortamos un montón de galimatías y lo reemplazamos con {{{{recortado}}}} para que esto sea un poco más legible. También hemos resaltado ciertas partes en negrita para indicar lo que es más relevante para nosotros.
Al leer las secciones en negrita en orden, este error indica que el firewall encontró:
- Acceso denegado con un error prohibido (código 403 ) (Nota:si no ve 'código 403' o 'Acceso denegado', entonces la entrada de registro de ModSecurity que está viendo no es relevante:pase a la siguiente. Algunas entradas son para depuración o información general, no todos son para bloquear).
- Algún tipo de script (javascript, livescript , etc.)
- Uso del ID de regla 212770
- Que consideró un ataque XSS (Secuencias de comandos entre sitios)
- Cuando estaba enviando una imagen en formato base64 codificado (data:image/png;base64 )
- Con gravedad "CRÍTICA" (Tenga en cuenta que si ve una gravedad de DEPURACIÓN o ADVERTENCIA, es probable que no sean responsables de un error 403 visible)
- En URI /specific_uri_requested/
¡El cortafuegos se está poniendo bastante nervioso por eso! Comprensible:es un script aleatorio con datos de aspecto extraño...
Dado que sabemos que el problema ocurre cuando un usuario legítimo envía un formulario de gravedad y, de hecho, hay una imagen involucrada, es probable que se trate de un caso de uso legítimo y, por lo tanto, el error es un falso positivo.
¡Abra un ticket si necesita ayuda para interpretar! Asegúrese de incluir la entrada de registro para que podamos analizarla rápidamente por usted.
A continuación, encontrará dos formas de evitar estos errores:1) deshabilitar el firewall (solo se recomienda en casos seleccionados) y 2) excluir las reglas particulares que generan el falso positivo.
Solución 1 (temporal):¿En desarrollo? Desactivar cortafuegos
Si actualmente está desarrollando el sitio, es mejor simplemente deshabilitar el firewall por completo, ya que es probable que encuentre una serie de obstáculos al enviar código al servidor a través de HTTP (es decir, guardar un cambio de CSS) dentro de WordPress.
Recuerde volver a habilitar el firewall cuando termine de editar el sitio; de lo contrario, su sitio no estará protegido contra una gran cantidad de ataques comunes.
He aquí cómo desactivarlo:
- En Plesk, vuelva a "Sitios web y dominios" o "Dominios" y haga clic en el dominio.
- Haga clic en "Cortafuegos de aplicaciones web".
- En "Modo de firewall de aplicaciones web", seleccione "Desactivado".
Nota:si elige "Solo detección", nuestro cortafuegos de nivel TCP aún recogerá las entradas de registro e instituirá prohibiciones temporales. Apagado es mejor durante el desarrollo. - Haga clic en Aceptar o Aplicar para guardar.
Cuando haya terminado de desarrollar, vuelva a habilitar el cortafuegos siguiendo los mismos pasos, pero seleccionando "Activado" en lugar de "Desactivado".
Solución 2 (permanente):excluyendo las reglas de ModSec
Si los usuarios de su sitio realizarán la misma acción que usted hizo que activó el 403 de forma regular, ¡entonces deshabilitar el firewall por completo no funcionará!
En cambio, sigamos adelante y excluyamos esta regla del firewall para el dominio. En nuestro ejemplo anterior, identificamos la regla de seguridad ID 212770, pero seguramente la suya será diferente. Examine la entrada de registro hasta que encuentre el ID, se verá así:[id "212770"] entonces…
- En Plesk, vuelva a "Sitios web y dominios"
- Haga clic en "Cortafuegos de aplicaciones web".
- En "Desactivar reglas de seguridad", ingrese el número de identificación que encontró en el registro (generalmente uno por línea, si tiene más de uno).
- Haga clic en Aceptar o Aplicar para guardar.
Ahora intente realizar la acción que causó el problema antes.
Si el problema NO se resuelve y aún recibe un error 403, es probable que la acción haya desencadenado múltiples reglas del cortafuegos. Repita el proceso anterior hasta que haya encontrado y excluido todos los ID de regla que causan problemas. Tenga en cuenta que si hay varios ID de regla que provocan este error, es probable que sean muy similares. así que mire muy de cerca cuando verifique las últimas entradas de registro para asegurarse de que las que está viendo sean ligeramente diferentes de las que ya excluyó.
Lo máximo que hemos tenido que excluir en una sola sesión es 5, por lo que es muy probable que arregles esto en solo 2 o 3 exclusiones.
Resolución de problemas
Si excluye un montón de reglas, llega a un error como este que no tiene una ID asociada:
ModSecurity: Output filter: Response body too large (over limit of 524288, total not specified).
Eso significa que necesitará aumentar esos límites. Si tiene acceso de administrador a Plesk, puede insertar lo siguiente en Herramientas y configuración> ModSecurity> pestaña Configuración> Directivas personalizadas:
SecResponseBodyLimit 546870912SecRequestBodyInMemoryLimit 546870912
Si no tiene acceso de administrador a Plesk y está alojado con nosotros, abra un ticket y nos encargaremos de ello por usted.