Unable to troubleshoot mod_security blocked requests

[mattops]

As discussed in this thread https://mojdt.slack.com/archives/C57UPMZLY/p1611057689075100

It seems there was a bug introduced into the the newer version of mod_security which was rolled out with nginx-ingress updates.

helm chart versions:
2.13.0 -> 3.6.0

Includes:
nginx-ingress
0.35.0 -> 0.40.2

Currently it is not possible to troubleshoot why a particular request was blocked. This is potentially a big problem for teams who want to use mod_security. There are hundred of rules and almost limitless ways in which to trigger them.

There is a service we would like to enable mod_security on, however it is unlikely we can practically do it without being able to diagnose any potential blocked requests.

Raising this ticket for visibility in the CP team - and maybe a work around can be found.

[razvan-moj]

waiting for upstream release 1.0.2; release 1.0.0 seems too buggy to revert to
https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/CHANGES#L12

[AntonyBishop]

Still waiting in release 1.0.2

[petergphillips]

Would it be possible to investigate workarounds for this? There haven't been any commits to the repo in the last month or so, nor is there any indication that the issues have been fixed, let alone that a release is imminent. That release note comment was added to the repository 14 months ago - https://github.com/SpiderLabs/ModSecurity-nginx/blame/master/CHANGES#L12.

We are left in the situation at present where, for security reasons, we need modsecurity, but it isn't fit for purpose in that we can't add it to any new projects because we can't then tailor the allowlist etc. to the application.

[AntonyBishop]

Hi @petergphillips will raise a discussion with the team to see what the alternatives might be.

[AntonyBishop]

#2787

[mattops]

Just to reiterate what @petergphillips said - we really need a work around for this. Essentially, we need to somehow be able to see what has been blocked and by which rule. Thanks.

[sldblog]

Our (interventions) current approach is to go live with our service on the public internet with the WAF in front of the service. +1 for us, it'd be good if we could investigate potential reports.

For context, we expect some of our users to be from large external organisations, so any visibility on who's getting blocked and why would be great. (It will be a commercial relationship, so will be sensitive if they cannot work.)

[razvan-moj]

kubernetes/ingress-nginx#7230