Modsec phases and Nginx phases pratice

[Rockybilly]

I am trying to create an nginx server, that uses modsecurity-nginx. But has only this specific purpose.

---

Return 403 if modsec applies the distruptive action 'deny', return 200 every other time, no body.

---

This has these two solutions (open to other suggestions).

• Solution 1:

location / {
        modsecurity on;
        modsecurity_rules '';
        return 200;
}

• Solution 2:

location @return200  {
        return 200;
}

location / {
        modsecurity on;
        modsecurity_rules '';
        try_files FAKE_NON_EXISTENT @return200;
}

The difference between the two is, return immediately, is a REWRITE phase directive, would this skip some of the ModSec phases?
try_files is PreContent phase, so more time given to the request before it ends? How do these correspond to ModSec processing phases?

[martinhsv]

Hello @Rockybilly ,

I don't really follow what you are trying to do.

But a redirect to a different location block where ModSecurity is not active can result in less processing of the request by ModSecurity in the original location block. One way to see what is happening is to enable the ModSecurity debug log (at the highest level of 9).

[Rockybilly]

Okay it wasn't about moving to a different location that does not include modsecurity, so my example was a bit wrong.

I guess this is more clear.

modsecurity on;
modsecurity_rules '';

location @return200  {
        return 200;
}

location / {
        try_files FAKE_NON_EXISTENT @return200;
}

But let's say I have some modsec rules that does body checking. try_files directive is after the content phase, return is in the rewrite phase(before content). Would this prevent the body checking from happening (because of early finish of the request)?

[martinhsv]

Have you tried it to see what happens?

I have never used the nginx try_files directive before and so cannot speak directly to that.

There are at least some expected behaviours in nginx that can result in a redirected POST request being transformed into a GET request ... which could, of course, affect body processing in that subsequent block. See, for example: #152 (comment)