ingress-nginx: ModSecurity does not block request, only logs, while SecRuleEngine is set to On

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG

NGINX Ingress controller version: 0.25.0 (installed through helm chart nginx-ingress-1.10.1)

Kubernetes version (use kubectl version): v1.12.7

Environment:

Cloud provider or hardware configuration: Azure Kubernetes Service (AKS)
OS (e.g. from /etc/os-release): Ubuntu 16.04.6 LTS
Kernel (e.g. uname -a): 4.15.0-1052-azure
Install tools: -
Others: -

What happened: Request is not blocked by ModSecurity, only logged. Debug log says: [4] Not running disruptive action: pass. SecRuleEngine is not On.

What you expected to happen: Blocked request by returning HTTP 403, because SecRuleEngine is specified as on.

How to reproduce it (as minimally and precisely as possible):

Install nginx-ingress with this content in values.yaml (partial): controller: config: enable-modsecurity: “true” enable-owasp-modsecurity-crs: “true”
Apply ingress with this content (partial): nginx.ingress.kubernetes.io/modsecurity-snippet: | SecRule REQUEST_HEADERS_NAMES “^x-waf-test” “log,deny,id:48,status:403,t:lowercase,msg:WAFWAFWAF” SecRequestBodyAccess On SecDebugLog /tmp/modsec_debug.log SecDebugLogLevel 9 SecRuleEngine On
Send request to ingress-host which should trigger ModSecurity rule(s): HTTP GET to <host>/?test=%271%20OR%201=1&x=%3Cscript%3Ealert%28%27hello%27%29;%3C/script%3E
Check mod-security debug log and see: [156458238464.652956] [/?test=%271%20OR%201=1&x=%3Cscript%3Ealert%28%27hello%27%29;%3C/script%3E] [4] Not running disruptive action: pass. SecRuleEngine is not On.

Anything else we need to know: I check logs with: kubectl -n kube-system exec -it internal-ingresscontroller-nginx-ingress-controller-7f8c6774w84 – tail -f /tmp/modsec_debug.log

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 29 (8 by maintainers)

Most upvoted comments

This issue still seems to persist in 0.26.0 with even more strange behaviour.

I’ve tried with:

Annotations in the configmap for the controller
Annotations in the ingress for a specific URL

Without any success. With 0.26.0 modsecurity dosen’t even log any errors into /var/log/modsec_audit.log and just passes through the request like normal (I.e 404 for something that dosen’t exist).

What’s even more strange is that controller now seems to log everything to /var/log/modsec_audit.log, we can for an example see: 127.0.0.1:10256 127.0.0.1 - [28/Sep/2019:16:27:16 +0000] “GET /nginx_status HTTP/1.1” 200 106 - “Go-http-client/1.1” 15696880369.409824 - /var/log/audit//20190928/20190928-1627/20190928-162716-15696880369.409824 0 1315.000000 md5:2127b3a365aeddf5ae366618a2356bf3

Aanuka on Sep 28, 2019

This still seems to be an issue in 0.26.1 @kwaazaar @aledbf Can anyone of you reopen so we can try and solve this?

Aanuka on Nov 11, 2019

I’ve got it working like this (with 0.27.1):

ConfigMap:

enable-modsecurity: "true"

Ingress Annotation:

    nginx.ingress.kubernetes.io/modsecurity-snippet: |
      SecRuleEngine On
      Include /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf

Now it blocks requests (403 Forbidden) like expected… Hope this helps

pcallewaert on Feb 6, 2020

I ran into this issue. Even with SecRuleEngine ON I only get logs and no blocks (403) when testing. I see the logs correctly catching the attacks but not blocking them.

---
kind: ConfigMap
metadata:
  name: nginx-ingress-controller
apiVersion: v1
data:  
  enable-modsecurity: "true"
  modsecurity-transaction-id: "$request_id"
  modsecurity-snippet: |
    SecRuleEngine On
    SecRequestBodyAccess On
    SecAuditEngine RelevantOnly
    SecAuditLogParts ABIJDEFHZ
    SecAuditLog /var/log/modsec_audit.log
    Include /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf
    Include /etc/nginx/modsecurity/modsecurity.conf

Upon further review, I noticed the /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf still had detection mode only. I created my own file for both this and also crs-setup.conf files. To ensure (a) Engine is ON and (b) secAction is set to block. I then mounted them using extra volumes.

SecRuleEngine On #nginx-modsecurity.conf file
SecDefaultAction "phase:1,log,auditlog,deny,status:403" #crs-setup.conf file
SecDefaultAction "phase:2,log,auditlog,deny,status:403" #crs-setup.conf file

Deploy nginx with the following additional configurations:

    "--set controller.extraVolumes[0].configMap.name=modsecurity-config "
    "--set controller.extraVolumes[0].name=modsecurity-config "
    "--set controller.extraVolumeMounts[0].name=modsecurity-config "
    "--set controller.extraVolumeMounts[0].mountPath=/etc/nginx/modsecurity/modsecurity.conf "
    "--set controller.extraVolumeMounts[0].subPath=modsecurity.conf "
    "--set controller.extraVolumes[1].configMap.name=crs-setup-config "
    "--set controller.extraVolumes[1].name=crs-setup-config "
    "--set controller.extraVolumeMounts[1].name=crs-setup-config "
    "--set controller.extraVolumeMounts[1].mountPath=/etc/nginx/owasp-modsecurity-crs/crs-setup.conf "
    "--set controller.extraVolumeMounts[1].subPath=crs-setup.conf "

Modsecurity is now successfully blocking the requests

$ curl "https://example.com/login?q='1 OR 1=1"
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>openresty</center>
</body>
</html>

celamb4 on Sep 21, 2019

I also have the same issue with nginx 0.25.0. Tried the example in this article:

nginx.ingress.kubernetes.io/modsecurity-snippet: |
      SecRuleEngine On
      SecRequestBodyAccess On
      SecAuditEngine RelevantOnly
      SecAuditLogParts ABIJDEFHZ
      SecAuditLog /var/log/modsec_audit.log
      SecRule REQUEST_HEADERS:User-Agent \"fern-scanner\" \"log,deny,id:107,status:403,msg:\'Fern Scanner Identified\'\"

With curl https://mysite/ -k -H "user-agent: fern-scanner" it only logged to /var/log/modsec_audit.log Editing the ngnix deployment to version 0.24.1 then I received 403 Forbidden as expected.

mhauer71 on Aug 14, 2019

I’am not working like this (with 0.30): https://github.com/kubernetes/ingress-nginx/issues/5343

Hello-Linux on Apr 9, 2020