ModSecurity [uri "/is-dynamic-lb-initialized"] Host header is a numeric IP address

[julianxhokaxhiu]

What happened:

Enabling ModSecurity with OWASP CRS brings this warning log over and over again:

ModSecurity: Warning. Matched "Operator `Rx' with parameter `^[\d.:]+$' against variable `REQUEST_HEADERS:Host' (Value: `127.0.0.1:10246' ) [file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "718"] [id "920350"] [rev ""] [msg "Host header is a numeric IP address"] [data "127.0.0.1:10246"] [severity "4"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/is-dynamic-lb-initialized"] [unique_id "1660057088"] [ref "o0,15v46,15"]

The responsible piece of code triggering it seems to be this one: https://github.com/kubernetes/ingress-nginx/blob/main/internal/nginx/main.go#L62-L78

What you expected to happen:

The warning log should not be there.

NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):

$ export POD_NAMESPACE=ingress-nginx
$ export POD_NAME=$(kubectl get pods -n $POD_NAMESPACE -l app.kubernetes.io/name=ingress-nginx --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}')
$ kubectl exec -it $POD_NAME -n $POD_NAMESPACE -- /nginx-ingress-controller --version 
-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:       v1.3.0
  Build:         2b7b74854d90ad9b4b96a5011b9e8b67d20bfb8f
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.19.10

-------------------------------------------------------------------------------

Kubernetes version (use kubectl version):

$ kubectl version
Server Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.10-eks-84b4fe6", GitCommit:"cc6a1b4915a99f49f5510ef0667f94b9ca832a8a", GitTreeState:"clean", BuildDate:"2022-06-09T18:24:04Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}

How was the ingress-nginx-controller installed:

$ helm ls -A | grep -i ingress
ingress-nginx                   ingress-nginx           8               2022-08-18 11:58:41.0436789 +0200 CEST  deployeingress-nginx-4.2.0                      1.3.0

How to reproduce this issue:

Just deploy the latest Ingress via Helm and override the values with these ones:

controller:
  config:
    enable-modsecurity: "true"
    enable-owasp-modsecurity-crs: "true" # See https://coreruleset.org/

Anything else we need to know:

N/A

[k8s-ci-robot]

@julianxhokaxhiu: This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[julianxhokaxhiu]

I'm interested in seeing this fixed. Please do not close it.

[longwuyuan]

/help
/remove-lifecycle stale

[k8s-ci-robot]

@longwuyuan:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help
/remove-lifecycle stale

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[burhanuguz]

Hi @julianxhokaxhiu ,
I also had the same problem. ModSecurity with ModSecurity with OWASP CRS has the following rule. It basically catches whether the host header is IP address or not. Probably ingress-nginx controller inside the container always checks the /is-dynamic-lb-initialized path, and since it is inside the container, it always tries that with 127.0.0.1

SecRule REQUEST_HEADERS:Host "@rx ^[\d.:]+$" \
    "id:920350,\
    phase:2,\
    block,\
    t:none,\
    msg:'Host header is a numeric IP address',\
    logdata:'%{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-protocol',\
    tag:'paranoia-level/1',\
    tag:'OWASP_CRS',\
    tag:'capec/1000/210/272',\
    tag:'PCI/6.5.10',\
    ver:'OWASP_CRS/3.3.2',\
    severity:'WARNING',\
    setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'"

I just added a new security with the helm value like in the one below, and it stopped giving errors like that. It just makes an exception for the requests that start with ^127.0.0.1 and does not log.

Here is the configuration I use

  --set controller.config.enable-modsecurity='true' \
  --set controller.config.enable-owasp-modsecurity-crs='true' \
  --set controller.config.modsecurity-snippet='Include /etc/nginx/modsecurity/modsecurity.conf
SecRuleEngine On
SecAuditLogFormat JSON
SecAuditLog /dev/stdout
SecRule REQUEST_HEADERS:Host "@rx ^127.0.0.1" "id:100\,phase:1\,allow\,nolog"'

Hope it helps

[tbondarchuk]

well, SecRule REQUEST_HEADERS:Host "@rx ^127.0.0.1" "id:100,phase:1,allow,nolog" didn't work for me, so I've used instead:

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:87,phase:1,pass,nolog,ctl:ruleEngine=Off"

from #8388

which, I suspect, was based on following

P.S. also, some good customizations can be found here

[Vedrillan]

Same issue. I do not fully understand that rule so I can't even tell what would be the right solution.

In any case it is really flooding the logs, as a result I simply disabled this specific rule:

SecRuleRemoveById 920350

However it is not ideal to bypass a rule so I hope somebody can jump in and found out what to do to fix this.

[longwuyuan]

I just now tried to enable mosecurity and look at the logs. I dont see the error message

There is no activity on this issue for a long time. There is no reproduce success. The code has changed a lot. There is also a new PR to bump the CRS to v4.4.0. And this issue is just adding to the open issues tally without offering any action-item or trackable problem. So I will close this for now. Please feel free to re-open after posting detailed data from a reproduce attempt on a kind of minikube cluster, using the latest release of the controller. thanks

/close

[k8s-ci-robot]

@longwuyuan: Closing this issue.

In response to this:

I just now tried to enable mosecurity and look at the logs. I dont see the error message

There is no activity on this issue for a long time. There is no reproduce success. The code has changed a lot. There is also a new PR to bump the CRS to v4.4.0. And this issue is just adding to the open issues tally without offering any action-item or trackable problem. So I will close this for now. Please feel free to re-open after posting detailed data from a reproduce attempt on a kind of minikube cluster, using the latest release of the controller. thanks

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.