ModSecurity-nginx icon indicating copy to clipboard operation
ModSecurity-nginx copied to clipboard

When used in conjunction with nginx, requests to the root route are always loaded twice.

Open pya789 opened this issue 1 year ago • 0 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.

pya789 avatar Aug 23 '24 08:08 pya789