Modsecurity V3.0.4 + Nginx: Phase 3/4 Not Blocking

[s-ribeiro]

Hi,

We are having an issue in Phase 3/4 rules which are detected but not blocked.
I found this issue similar with https://github.com/SpiderLabs/ModSecurity/issues/1568, however in my case I'm able to block in phase 1 and phase 2. I used a workaround to redirect to a static page hosted internally.

Tested both with action as redirect, deny, drop, but the result was the same.
SecDefaultAction "phase:4,log,auditlog,redirect:/403.html"
SecDefaultAction "phase:4,log,auditlog,deny,status:403"

As can be seen in the attached logs, multiple disruptive rules with action deny/drop/block are detected in the same transaction.
Example: 953120, 980140

logs.txt

Have anyone faced this issue and any idea how to fix it?

Thanks in advance,

[zimmerle]

Hi @s-ribeiro,

What is the version of ModSecurity?

Notice that if you are using nginx, redirection on phase 3/4 is not feasible. At this point the header already hit the user browser, the only option is to terminate the request abruptly.

[s-ribeiro]

Hi @zimmerle,

Thanks for your feedback. I am running 3.0.4.
I do understand your point regarding phase4, the response headers were already sent, so redirect will not work. My bad... :)
But I have the same problem in phase3 rules as well.
As per your suggestion I've changed SecDefaultAction in phase 3 and 4 to a disruptive one (example: drop) and the result was the same.

SecDefaultAction "phase:1,log,auditlog,redirect:/403.html"
SecDefaultAction "phase:2,log,auditlog,redirect:/403.html"
SecDefaultAction "phase:3,drop"
SecDefaultAction "phase:4,drop"

[159489610275.514024] [/1.html] [4] Running (non-disruptive) action: tag
[159489610275.514024] [/1.html] [4] Running (non-disruptive) action: tag
[159489610275.514024] [/1.html] [4] Running (non-disruptive) action: tag
[159489610275.514024] [/1.html] [4] Running (non-disruptive) action: tag
[159489610275.514024] [/1.html] [4] Running (non-disruptive) action: tag
[159489610275.514024] [/1.html] [4] Running (non-disruptive) action: tag
[159489610275.514024] [/1.html] [4] Running (non-disruptive) action: tag
[159489610275.514024] [/1.html] [4] Running (non-disruptive) action: tag
[159489610275.514024] [/1.html] [4] Running (disruptive) action: block.
[159489610275.514024] [/1.html] [4] Starting phase LOGGING. (SecRules 5)
[159489610275.514024] [/1.html] [4] (Rule: 912110) Executing operator "Eq" with param "0" against TX:dos_burst_time_slice.
[159489610275.514024] [/1.html] [4] Rule returned 0.

Then I've changed in the rule itself the action to drop instead of instead block (inheritance from SecDefaultAction).

[159489653434.461145] [/1.html] [4] Running (non-disruptive) action: tag
[159489653434.461145] [/1.html] [4] Running (non-disruptive) action: tag
[159489653434.461145] [/1.html] [4] Running (non-disruptive) action: tag
[159489653434.461145] [/1.html] [4] Running (non-disruptive) action: tag
[159489653434.461145] [/1.html] [4] Running (non-disruptive) action: tag
[159489653434.461145] [/1.html] [4] Running (non-disruptive) action: tag
[159489653434.461145] [/1.html] [4] Running (disruptive) action: drop.
[159489653434.461145] [/1.html] [4] Starting phase LOGGING. (SecRules 5)

But the connection is either dropped.

[ricferr]

Hello.

I have the exact same problem. Has there been any development on this ?

I'm also using version 3.0.4 with nginx.

Is there some workaround ?

Thanks,
Ricardo Ferreira

[zimmerle]

Hi,

That is a limitation on nginx. At this phase is not possible to redirect the user any longer. The reason for that is the fact that nginx already delivered the response headers to the user. At this stage only drop is possible.