The unexpected behavior is the server doesn't send the response headers to client. It can reproduced with this minimal rule set:
include /etc/nginx/modsec/modsecurity.conf
SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"
SecAction "id:900101,phase:1,nolog,pass,t:none,setvar:tx.trigger_phase1=1"
SecAction "id:900103,phase:1,nolog,pass,t:none,setvar:tx.trigger_phase3=1"
SecAction "id:900105,phase:1,nolog,pass,t:none,setvar:tx.trigger_phase5=1"
SecRule TX:TRIGGER_PHASE1 "@eq 1" "id:901111,phase:1,t:none,deny,log"
SecRule REQUEST_BODY "@rx attack" "id:901121,phase:2,t:none,deny,log"
SecRule TX:TRIGGER_PHASE3 "@eq 1" "id:901131,phase:3,t:none,deny,log"
SecRule RESPONSE_BODY "@rx ok" "id:901141,phase:4,t:none,deny,log"
SecRule TX:TRIGGER_PHASE5 "@eq 1" "id:901151,phase:5,t:none,pass,log,msg:'This is the phase 5.'"
The request can be anything, the set contains 3 rules which will triggered always in phase 1, 3 and 5.
As we discussed in ModSecurity issue #2465, the nginx connector tries to do all the processing as early as possible.
The unexpected behavior is the server doesn't send the response headers to client. It can reproduced with this minimal rule set:
The request can be anything, the set contains 3 rules which will triggered always in phase 1, 3 and 5.
The disrputive action of these rules are
denywhich means the rule wants to terminate the process, but Nginx continues.