When used in conjunction with nginx, requests to the root route are always loaded twice.
pya789 opened this issue · 2 comments
1.nginx config
server {
listen 4466;
listen [::]:4466;
server_name 39.164.146.201;
index index.php index.html index.htm default.php default.html default.htm;
root /xp/www/39.164.146.201_4466/;
# SSL-START SSL配置(请勿删除此注释)
# SSL-END(请勿删除此注释)
# WAF-START(请勿删除此注释)
modsecurity on;
modsecurity_rules_file /xp/panel/vhost/waf/39.164.146.201_4466/modsecurity.conf;
# WAF-END(请勿删除此注释)
# ERROR-PAGE-START 错误页配置
# ERROR-PAGE-END
# REWRITE-START 伪静态配置
include /xp/panel/vhost/rewrite/39.164.146.201_4466.conf;
# REWRITE-END
# 禁止访问的文件或目录
location ~ ^/(\.user.ini|\.htaccess|\.git|\.svn|\.project|LICENSE|README.md|package.json|package-lock.json|\.env) {
return 404;
}
# SSL证书验证目录
location /.well-known/ {
allow all;
}
# 禁止证书验证目录敏感文件
if ( $uri ~ "^/\.well-known/.*\.(php|jsp|py|js|css|lua|ts|go|zip|tar\.gz|rar|7z|sql|bak)$" ) {
return 403;
}
# 缓存多媒体文件
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 30d;
error_log /dev/null;
access_log /dev/null;
}
# 缓存js和css文件
location ~ .*\.(js|css)?$
{
expires 12h;
error_log /dev/null;
access_log /dev/null;
}
access_log /xp/wwwlogs/39.164.146.201_4466.log;
error_log /xp/wwwlogs/39.164.146.201_4466.error.log;
}
2.modsecurity.conf'
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecAuditEngine On
SecAuditLog /xp/panel/vhost/waf/39.164.146.201_4466/audit.log
SecDebugLog /xp/panel/vhost/waf/39.164.146.201_4466/debug.log
SecDebugLogLevel 9
SecRuleScript "/xp/panel/vhost/waf/39.164.146.201_4466/ip.lua" "phase:1,deny"
3.debug.log
[172440088144.734590] [] [4] Initializing transaction
[172440088144.734590] [] [4] Transaction context created.
[172440088144.734590] [] [4] Starting phase CONNECTION. (SecRules 0)
[172440088144.734590] [] [9] This phase consists of 0 rule(s).
[172440088144.734590] [] [4] Starting phase URI. (SecRules 0 + 1/2)
[172440088144.734590] [/] [4] Starting phase REQUEST_HEADERS. (SecRules 1)
[172440088144.734590] [/] [9] This phase consists of 1 rule(s).
[172440088144.734590] [/] [4] Executing script: /xp/panel/vhost/waf/39.164.146.201_4466/ip.lua.
[172440088144.734590] [/] [1]
[172440088144.734590] [/] [1] uid172440088144.734590
[172440088144.734590] [/] [9] Returning from lua script:
[172440088144.734590] [/] [4] Starting phase REQUEST_BODY. (SecRules 2)
[172440088144.734590] [/] [9] This phase consists of 0 rule(s).
[172440088135.982152] [] [4] Initializing transaction
[172440088135.982152] [] [4] Transaction context created.
[172440088135.982152] [] [4] Starting phase CONNECTION. (SecRules 0)
[172440088135.982152] [] [9] This phase consists of 0 rule(s).
[172440088135.982152] [] [4] Starting phase URI. (SecRules 0 + 1/2)
[172440088135.982152] [/] [4] Starting phase REQUEST_HEADERS. (SecRules 1)
[172440088135.982152] [/] [9] This phase consists of 1 rule(s).
[172440088135.982152] [/] [4] Executing script: /xp/panel/vhost/waf/39.164.146.201_4466/ip.lua.
[172440088135.982152] [/] [1]
[172440088135.982152] [/] [1] uid172440088135.982152
[172440088135.982152] [/] [9] Returning from lua script:
[172440088135.982152] [/] [4] Starting phase REQUEST_BODY. (SecRules 2)
[172440088135.982152] [/] [9] This phase consists of 0 rule(s).
[172440088135.982152] [/] [4] Starting phase RESPONSE_HEADERS. (SecRules 3)
[172440088135.982152] [/] [9] This phase consists of 0 rule(s).
[172440088135.982152] [/] [9] Appending response body: 12 bytes. Limit set to: 0.000000
[172440088135.982152] [/] [4] Starting phase RESPONSE_BODY. (SecRules 4)
[172440088135.982152] [/] [4] Response body is disabled, returning... 1
[172440088135.982152] [/] [4] Starting phase LOGGING. (SecRules 5)
[172440088135.982152] [/] [9] This phase consists of 0 rule(s).
[172440088135.982152] [/] [8] Checking if this request is suitable to be saved as an audit log.
[172440088135.982152] [/] [8] Checking if this request is relevant to be part of the audit logs.
[172440088135.982152] [/] [5] Saving this request as part of the audit logs.
[172440088135.982152] [/] [8] Request was relevant to be saved. Parts: 4430
4.audio.log
---In3ko5qI---A--
[23/Aug/2024:16:14:41 +0800] 172440088135.982152 127.0.0.1 47940 127.0.0.1 4466
---In3ko5qI---B--
GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: 127.0.0.1:4466
Accept: */*
---In3ko5qI---F--
HTTP/1.1 200
Server: nginx
Date: Fri, 23 Aug 2024 08:14:41 GMT
Content-Length: 12
Content-Type: text/html
Last-Modified: Thu, 22 Aug 2024 05:52:03 GMT
Connection: keep-alive
ETag: "66c6d203-c"
---In3ko5qI---H--
---In3ko5qI---Z--
5.nginx log
127.0.0.1 - - [23/Aug/2024:16:14:41 +0800] "GET / HTTP/1.1" 200 12 "-" "curl/7.29.0"
nginx version:1.20
modsecurity version:latest version
modsecurity-nginx:latest version
After checking, only "/" the route will exhibit this behavior. All other routes are normal.
The audit logs of ModSecurity and the request logs of Nginx both only record one request. When UNIQUE_ID is set in Nginx, there will still be two requests when accessing "/", but the UNIQUE_ID is the same. If UNIQUE_ID is not set in Nginx and ModSecurity generates it, there will be two requests with inconsistent UNIQUE_ID.
Hi @pya789,
unfortunately based on available information it's very-very hard to tell you what's wrong here.
When the redirect occurs, does it appear in - for eg. - tcpdump?
If yes, could you try to disable Modsecurity and repeat the test again, and check the tcpdump output?
Hi @pya789,
unfortunately based on available information it's very-very hard to tell you what's wrong here.
When the redirect occurs, does it appear in - for eg. - tcpdump?
If yes, could you try to disable Modsecurity and repeat the test again, and check the tcpdump output?
Hello, we have found the reason by checking the nginx debug log, it is because of redirection, thank you for your enthusiasm.