Misleading & clumsy ModSecurity doc #8388

damienleger · 2022-03-24T17:26:30Z

hello,

I'm on nginx 1.1.1 and I've been struggling with the ModSecurity documentation. I wanted to explain why since usually the doc is clean, but for ModSecurity it isn't really.

Atm on the website there are:

[1] https://kubernetes.github.io/ingress-nginx/user-guide/third-party-addons/modsecurity/ -> entry doc for the modsecurity feature
[2] https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#modsecurity -> focus on ingress implem
[3] https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/ -> focus on controller wide implem

[1] is kinda ok but miss a critical point imho: telling that there is both possible implementation: per ingress or controller wide, something that you conclude yourself by checking [2] and [3]

[2] is full of clumsy phrasing imho and mistakes, I will elaborate below

[3] there are no examples of modsecurity configmap parameters, those must be derived from their ingress annotations counterpart in [2] this is really weird. It seems like this feature is beta or something 🤨

particularly the configmap equivalent of

nginx.ingress.kubernetes.io/modsecurity-transaction-id: "$request_id"

is a bit tricky and would be interesting to detail (found how to do there

http-snippet: |- 
  modsecurity_transaction_id "$request_id";

About [2],

So if I'm rephrasing, enabling modsecurity in configmap enables it for every ingress per default except if you disable it specifically. Yet the configuration show how to enable modsecurity on ingress instead of disabling 🤨

This one is true, yet if you do that on controller level you have a ton of spam from 127.0.0.1. This tweak might be either documented or implemented by default imho.

This one I mentioned above

So I've made a lot of test to understand this one

default=y, crs=n, snippet=n

# configmap
enable-modsecurity: "true"

# /etc/nginx/nginx.conf
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;

OK

default=y, crs=y, snippet=n

# configmap
enable-modsecurity: "true"
enable-owasp-modsecurity-crs: "true"

# /etc/nginx/nginx.conf
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;
modsecurity_rules_file /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf;

OK

default=y, crs=y, snippet=y

# configmap
enable-modsecurity: "true"
enable-owasp-modsecurity-crs: "true"
modsecurity-snippet: SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:87,phase:1,pass,nolog,ctl:ruleEngine=Off"

# /etc/nginx/nginx.conf
modsecurity on;
modsecurity_rules '
        SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:87,phase:1,pass,nolog,ctl:ruleEngine=Off"
        ';
modsecurity_rules_file /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf;

KO! both snippet and crs are here, and doc said snippet only takes effect in that case
which clearly not the case because when trying this

# configmap
enable-modsecurity: "true"
enable-owasp-modsecurity-crs: "true"
modsecurity-snippet:-
  SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:87,phase:1,pass,nolog,ctl:ruleEngine=Off"
  Include /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf

the pod doesn't even start saying this error [emerg] 931#931: "modsecurity_rules_file" directive Rule id: 901001 is duplicated which clearly means both snippet and modsecurity_rules_file take effect here

And this last part I don't really get, the 0.24.1 instructions seem wrong since the crs doc specifically says that default conf must be loaded BEFORE crs but it's done after 🤨

And for the 0.25.0 and above if doing this and keep enable-owasp-modsecurity-crs: "true" your pod doesn't even start

What worked for me eventually is this btw.

enable-modsecurity: "true"
http-snippet: |- 
  modsecurity_transaction_id "$request_id";
modsecurity-snippet: |-
  SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:87,phase:1,pass,nolog,ctl:ruleEngine=Off"
  Include /etc/nginx/modsecurity/modsecurity.conf
  Include /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf

(btw I don't really get #8021 because I'm supposed to have this "bug" in 1.1.1, meaning I should load twice /etc/nginx/modsecurity/modsecurity.conf in the code above but it's not since pods are starting 🤨 )

What do you want to happen?

To have a better doc for the community. So that people not struggle as I did with the doc.

Is there currently another issue associated with this?

I feel like this problem of snippet/default/crs has been seen there but not entirely #8021

Does it require a particular kubernetes version?

I don't think so. I'm on EKS 1.21 (last one atm)

/kind documentation
/remove-kind feature

The text was updated successfully, but these errors were encountered:

k8s-ci-robot · 2022-03-24T17:26:36Z

@damienleger: 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.

xianzheTM · 2022-03-31T06:24:38Z

The document really confuses me.

I want to block the request with' class' in the URL. But this writing didn't take effect. So I began to wonder if I should configure every ingress.
----update----
I set each ingress and it worked. I don't understand why it can't be set in the configmap and it works for every ingress.
----update----
I saw #8021 , maybe that's why.

arthurk · 2022-04-13T04:12:31Z

Thanks @damienleger your comment helped me out a lot. I updated to the latest nginx-ingress helm chart version (from 4.0.9 to 4.0.19) and modescurity stopped working, using your solution made it work again.

In 4.0.9 I was using this, which worked fine:

      enable-modsecurity: true
      enable-owasp-modsecurity-crs: true
      modsecurity-snippet: |
        SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:87,phase:1,pass,nolog,ctl:ruleEngine=Off"

It stopped working with 4.0.19. Now I have to use:

      enable-modsecurity: true
      modsecurity-snippet: |
        SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:87,phase:1,pass,nolog,ctl:ruleEngine=Off"
        Include /etc/nginx/modsecurity/modsecurity.conf
        Include /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf

mac-chaffee · 2022-04-13T14:07:56Z

Apparently there's also inconsistency in which modsecurity settings take precedence when there are conflicts (owasp-modsecurity/ModSecurity-nginx#280), which undermines a lot of the assumptions of #8021. In fact, that PR broke my modsecurity settings.

To anyone else finding this thread, my advice is to just not use any of the built-in modsecurity settings. It's pretty easy to configure 100% manually:

main-snippet: "load_module /etc/nginx/modules/ngx_http_modsecurity_module.so;"
http-snippet: |
  modsecurity on;
  modsecurity_rules '
    # Yes, this does somehow take precedence over the modsecurity_rules_file below
    SecRuleEngine On
    # Put custom rules here...
  ';
  modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;
  modsecurity_rules_file /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf;

vijay-veeranki · 2022-05-23T20:43:50Z

Hi @damienleger @arthurk

We upgraded the chart from 4.0.19 to 4.1.1, and this configuration stopped working.

      enable-modsecurity: true
      modsecurity-snippet: |
        Include /etc/nginx/modsecurity/modsecurity.conf
        Include /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf

Did you try upgrading to the latest version of the chart, and see a similar issue I am facing now?

damienleger · 2022-05-23T21:21:26Z

Hi @vijay-veeranki . I'm afraid I cannot help you or anybody else, I decided not to use ModSecurity soon after writing this GIthub issue. I was running a PoC by then actually. Good luck with the issue you are facing.

macmiranda · 2022-06-02T14:04:45Z

I've tried gazillions of combinations between configMap and ingress annotations. Nothing in that documentation makes sense to me.
I get that the snippet has precedence over the owasp setting but how do you override the settings in /etc/nginx/modsecurity/modsecurity.conf?

  enable-modsecurity: "true"
  enable-owasp-modsecurity-crs: "false"
  modsecurity-snippet: |-
    SecRuleEngine On
    SecAuditEngine On
    SecAuditLogParts ABIJDEFHZ
    SecAuditLogFormat JSON
    SecAuditLogType Serial
    SecAuditLog /dev/stdout

According to the documentation I should get Audit logs in JSON format sent to the STDOUT but I keep getting same ol' /var/log/modsec_audit.log and not JSON-formated.

mac-chaffee · 2022-06-02T15:01:08Z

One possibility for the confusion is that updates to the modsecurity settings roll out slowly as the nginx workers restart. If there are long-lived connections keeping old nginx workers from restarting, then it can seem like changes to the modsecurity settings aren't doing anything.

But also based on this thread it sounds like there is a complex/buggy interaction between inline modsecurity settings (modsecurity-snippet) and the files (/etc/nginx/modsecurity/modsecurity.conf). I think someone has to just go look at the modsecurity-nginx source code and find out for sure what's happening.

k8s-triage-robot · 2022-08-31T15:54:15Z

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

vijay-veeranki · 2022-09-09T14:23:54Z

Please keep this issue open

arthurk · 2022-09-10T03:34:26Z

/remove-lifecycle stale

k8s-triage-robot · 2022-12-09T03:53:20Z

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

macmiranda · 2022-12-09T06:58:38Z

/remove-lifecycle stale

tbondarchuk · 2023-03-21T18:18:28Z

The following seems to work for me on chart 4.5.2, controller 1.6.4:

    enable-modsecurity: true
    enable-owasp-modsecurity-crs: true
    modsecurity-snippet: |
      SecRuleEngine On
      SecStatusEngine Off
      SecAuditLog /dev/stdout
      SecAuditLogFormat JSON
      SecAuditEngine RelevantOnly
      SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:87,phase:1,pass,nolog,ctl:ruleEngine=Off"
      SecAction "id:900200,phase:1,nolog,pass,t:none,setvar:tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE"

damienleger added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 24, 2022

k8s-ci-robot added kind/documentation Categorizes issue or PR as related to documentation. and removed kind/feature Categorizes issue or PR as related to a new feature. labels Mar 24, 2022

k8s-ci-robot added needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority labels Mar 24, 2022

mac-chaffee mentioned this issue Apr 11, 2022

Question about conflicting modsecurity_rules/modsecurity_rules_file precedence owasp-modsecurity/ModSecurity-nginx#280

Open

vijay-veeranki mentioned this issue May 19, 2022

Investigate duplicate rule error when switching modsec ingress controller ministryofjustice/cloud-platform#3807

Closed

5 tasks

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 31, 2022

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 10, 2022

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 9, 2022

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 9, 2022

tbondarchuk mentioned this issue Mar 21, 2023

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

Closed

konmedia-devops mentioned this issue Jul 2, 2024

modsecurity: Including custom rules file throws error #11531

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Misleading & clumsy ModSecurity doc #8388

Misleading & clumsy ModSecurity doc #8388

damienleger commented Mar 24, 2022

k8s-ci-robot commented Mar 24, 2022

xianzheTM commented Mar 31, 2022 •

edited

Loading

arthurk commented Apr 13, 2022 •

edited

Loading

mac-chaffee commented Apr 13, 2022 •

edited

Loading

vijay-veeranki commented May 23, 2022

damienleger commented May 23, 2022

macmiranda commented Jun 2, 2022

mac-chaffee commented Jun 2, 2022

k8s-triage-robot commented Aug 31, 2022

vijay-veeranki commented Sep 9, 2022

arthurk commented Sep 10, 2022

k8s-triage-robot commented Dec 9, 2022

macmiranda commented Dec 9, 2022

tbondarchuk commented Mar 21, 2023

Misleading & clumsy ModSecurity doc #8388

Misleading & clumsy ModSecurity doc #8388

Comments

damienleger commented Mar 24, 2022

default=y, crs=n, snippet=n

default=y, crs=y, snippet=n

default=y, crs=y, snippet=y

k8s-ci-robot commented Mar 24, 2022

xianzheTM commented Mar 31, 2022 • edited Loading

arthurk commented Apr 13, 2022 • edited Loading

mac-chaffee commented Apr 13, 2022 • edited Loading

vijay-veeranki commented May 23, 2022

damienleger commented May 23, 2022

macmiranda commented Jun 2, 2022

mac-chaffee commented Jun 2, 2022

k8s-triage-robot commented Aug 31, 2022

vijay-veeranki commented Sep 9, 2022

arthurk commented Sep 10, 2022

k8s-triage-robot commented Dec 9, 2022

macmiranda commented Dec 9, 2022

tbondarchuk commented Mar 21, 2023

xianzheTM commented Mar 31, 2022 •

edited

Loading

arthurk commented Apr 13, 2022 •

edited

Loading

mac-chaffee commented Apr 13, 2022 •

edited

Loading