In phase:4, Disruptive actions is set to deny,Connection will be reset.

[yeyouli]

Hello,
We are running https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.2 and https://github.com/SpiderLabs/ModSecurity-nginx/releases/tag/v1.0.0 with openresty/1.13.6.2.
I'm attaching the rule set + modsecurity configuration as well.

When I tested the rules, I discovered that in phase:4 I turned the disruptive actions 'pass' to 'deny', the return page was not 403, but the connection was reset.
rule eg:
SecRule RESPONSE_BODY "@pm MySqlClient." phase:4,id:17040000,t:none,t:urlDecodeUni,t:htmlEntityDecode,deny,ctl:auditLogParts=+E,nolog,setvar:tx.sql_error_match=1,tag:'INFORMATION_LEAKAGE/DATABASE_INFO_LEAKAGE'"

furthermore，When using the 'pmf' or 'pmFromFile 'instruction, the value cannot be exactly matched.
rule eg:
SecRule RESPONSE_BODY "@pmf sql-errors.data" phase:4,id:17040000,t:none,t:urlDecodeUni,t:htmlEntityDecode,deny,ctl:auditLogParts=+E,nolog,setvar:tx.sql_error_match=1,tag:'INFORMATION_LEAKAGE/DATABASE_INFO_LEAKAGE'"

This is the modsec_debug.log
[4] (Rule: 17040000) Executing operator "PmFromFile" with param "sql-errors.data" against RESPONSE_BODY. [9] T (0) t:urlDecodeUni: "MySqlClient. " [9] T (1) t:htmlEntityDecode: "MySqlClient. " [9] Target value: "MySqlClient.\x0a" (Variable: RESPONSE_BODY) [4] Rule returned 0.

[p0pr0ck5]

@yeyouli what's in the contents of your Nginx error log?

[yeyouli]

@p0pr0ck5 Thank you for your reply,
Here is the nginx error log in debug mode

2018/05/25 09:52:03 [notice] 49429#49429: ModSecurity-nginx v1.0.0
2018/05/25 09:52:03 [notice] 49429#49429: signal process started
2018/05/25 09:52:10 [notice] 49357#49357: signal 15 (SIGTERM) received from 49429, exiting
2018/05/25 09:52:10 [notice] 49358#49358: exiting
2018/05/25 09:52:10 [notice] 49359#49359: exiting
2018/05/25 09:52:10 [notice] 49360#49360: exiting
2018/05/25 09:52:10 [notice] 49357#49357: signal 14 (SIGALRM) received
2018/05/25 09:52:10 [notice] 49357#49357: signal 14 (SIGALRM) received
2018/05/25 09:52:10 [notice] 49358#49358: exit
2018/05/25 09:52:10 [notice] 49357#49357: signal 17 (SIGCHLD) received from 49358
2018/05/25 09:52:10 [notice] 49357#49357: worker process 49358 exited with code 0
2018/05/25 09:52:10 [notice] 49357#49357: signal 29 (SIGIO) received
2018/05/25 09:52:10 [notice] 49359#49359: exit
2018/05/25 09:52:10 [notice] 49360#49360: exit
2018/05/25 09:52:10 [notice] 49357#49357: signal 17 (SIGCHLD) received from 49360
2018/05/25 09:52:10 [notice] 49357#49357: cache manager process 49360 exited with code 0
2018/05/25 09:52:10 [notice] 49357#49357: signal 29 (SIGIO) received
2018/05/25 09:52:10 [notice] 49357#49357: signal 17 (SIGCHLD) received from 49359
2018/05/25 09:52:10 [notice] 49357#49357: worker process 49359 exited with code 0
2018/05/25 09:52:10 [notice] 49357#49357: exit
2018/05/25 09:52:10 [notice] 49432#49432: ModSecurity-nginx v1.0.0
2018/05/25 09:52:10 [notice] 49432#49432: using the "epoll" event method
2018/05/25 09:52:10 [notice] 49432#49432: openresty/1.13.6.2
2018/05/25 09:52:10 [notice] 49432#49432: built by gcc 4.8.2 20140120 (Red Hat 4.8.2-15) (GCC)
2018/05/25 09:52:10 [notice] 49432#49432: OS: Linux 2.6.32-573.el6.x86_64
2018/05/25 09:52:10 [notice] 49432#49432: getrlimit(RLIMIT_NOFILE): 1024:4096
2018/05/25 09:52:10 [notice] 49433#49433: start worker processes
2018/05/25 09:52:10 [notice] 49433#49433: start worker process 49434
2018/05/25 09:52:10 [notice] 49433#49433: start worker process 49435
2018/05/25 09:52:10 [notice] 49433#49433: start cache manager process 49436
2018/05/25 09:52:10 [notice] 49433#49433: start cache loader process 49437
2018/05/25 09:53:17 [notice] 49437#49437: http file cache: /home/cache/site01 2.750M, bsize: 4096
2018/05/25 09:53:17 [notice] 49433#49433: signal 17 (SIGCHLD) received from 49437
2018/05/25 09:53:17 [notice] 49433#49433: cache loader process 49437 exited with code 0
2018/05/25 09:53:17 [notice] 49433#49433: signal 29 (SIGIO) received

[victorhora]

HI @yeyouli,

This is known issue with Nginx-connector where phase:4 processing still have some rough edges.

I'm not sure if this works for you as a temporary workaround, but setting a 403 for phase:3 is working fine.

Please refer to owasp-modsecurity/ModSecurity-nginx#84 for related issues and proposed changes being evaluated for fixing response body processing, and please follow up on those issues.

Also, the issue you've mentioned with the @pm operator is being addressed at #1167 and #1645. Please follow up with your observations/bug report on those issues.

Thanks!