Acceso denegado de ModSecurity con código 403 al usar el módulo ngx_http_auth_request_module de nginx.
Estoy tratando de configurar ModSecurity para usarlo en un servidor NGINX que tiene instalado el módulo ngxhttpauthrequest, y estoy recibiendo el siguiente error:
2021/11/30 01:52:58 7#0: *1 ModSecurity: Advertencia. Se ha encontrado "Operador Rx' con el parámetro^0?$' contra la variable REQUEST_HEADERS:Content-Length' (Valor:51') [archivo "/usr/local/coreruleset-3.3.2/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [línea "161"] [id "920170"] [rev ""] [msg "Solicitud GET o HEAD con contenido en el cuerpo"] [data "51"] [severity "2"] [ver "OWASP_CRS/3.3.2"] [madurez "0"] [precisión "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [hostname "172.17.0.6"] [uri "/api/v1/busquedas/criterios"] [unique_id "1638237178"] [ref "o0,3v0,3v96,2"], cliente: 172.17.0.1, servidor: nombredelservidor, solicitud: "POST /api/v1/busquedas/criterios HTTP/1.1", sub-solicitud: "/auth", host: "localhost", referencia: "http://localhost/clientes/busqueda"
2021/11/30 01:52:58 [debug] 7#0: *1 malloc: 000056265DD6F8B0:4096
2021/11/30 01:52:58 [debug] 7#0: *1 malloc: 000056265DD708C0:4096
2021/11/30 01:52:58 [debug] 7#0: *1 free: 000056265DD6F8B0
2021/11/30 01:52:58 [debug] 7#0: *1 free: 000056265DD708C0
2021/11/30 01:52:58 7#0: *1 [cliente 172.17.0.1] ModSecurity: Acceso denegado con código 403 (fase 2). Se ha encontrado "Operador Ge' con el parámetro5' contra la variable TX:ANOMALY_SCORE' (Valor:5') [archivo "/usr/local/coreruleset-3.3.2/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [línea "80"] [id "949110"] [rev ""] [msg "Puntuación de anomalía entrante superada (puntuación total: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.3.2"] [madurez "0"] [precisión "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "172.17.0.6"] [uri "/api/v1/busquedas/criterios"] [unique_id "1638237178"] [ref ""], cliente: 172.17.0.1, servidor: nombredelservidor, solicitud: "POST /api/v1/busquedas/criterios HTTP/1.1", sub-solicitud: "/auth", host: "localhost", referencia: "http://localhost/clientes/busqueda"
2021/11/30 01:52:58 [debug] 7#0: *1 http finalize solicitud: 403, "/auth?" a:1, c:2
2021/11/30 01:52:58 [debug] 7#0: *1 solicitud de autenticación completada s:0
2021/11/30 01:52:58 [debug] 7#0: *1 respuesta especial HTTP: 403, "/auth?"
20
Se supone que ModSecurity ejecuta una SecRule para validar una solicitud POST que mi aplicación web envía al servidor, sin embargo, como se puede ver en la advertencia anterior, está validando una solicitud GET en su lugar.
Después de investigar un poco, descubrí que la SecRule está validando que una solicitud GET no debe tener una cabecera Content-Length con un valor diferente a “””” (cadena vacía), lo cual es lógico. Sin embargo, como también estoy utilizando el módulo ngxhttpauthrequest para generar sub-solicitudes a la siguiente ubicación en mi archivo de configuración de NGINX:
location /auth {
internal;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header access_token $http_access_token;
proxy_pass http://authentication-gwy:8080/cmr-experience-serv-gateway-loggin/v1/auth/token-valid;
}
Entonces, ModSecurity también está tratando de evaluar la sub-solicitud GET, que mantiene la cabecera Content-Length con un valor de 51, aunque la establezco como “””” en la ubicación.
davy.ai
Como experto en tecnologías de la información especializado en nginx, autorización, mod-security y content-length, el mensaje de error indica que hay un problema con la configuración de ModSecurity en un servidor NGINX que tiene instalado el módulo ngx_http_auth_request_module. Parece que ModSecurity está activando una SecRule para validar una solicitud GET en lugar de una solicitud POST, que no tiene un encabezado de Content-Length con un valor distinto de una cadena vacía. El problema radica en la sub-solicitud interna generada por el módulo ngx_http_auth_request_module. En particular, la sub-solicitud mantiene el encabezado de Content-Length con un valor de 51, a pesar de estar configurado como una cadena vacía en la configuración de ubicación principal. Para resolver el problema, el experto en TI debe asegurarse de que el encabezado Content-Length de la sub-solicitud interna se elimine o se configure como una cadena vacía para que coincida con la SecRule.