-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable default modsecurity_rules_file if modsecurity-snippet is specified #8021
Conversation
…cifed The default modsecurity_rules_file overwrites the ModSecurity-snippet if it is specified with custom config settings like "SecRuleEngine On". This will not let Modsecurity be in blocking mode even if "SecRuleEngine On" is specified in the ModSecurity-snippet configuration
|
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
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. I understand the commands that are listed here. |
Welcome @besha100! |
Hi @besha100. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/assign @thockin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it strange that you add a commented line that does nothing if modsecurity snippet is speficied and only enable modsecuritx rules file in the else case. IMHO it would be more straight forward if we would have only the if case where we add the rules file if snippet is empty and have no else case at all.
Also I would expect some tests that cover this change.
/triage accepted |
Only have the default Modsecurity conf settings in case Modsecurity configuration snippet is not present and remove unnecessary comments
/test pull-ingress-nginx-test |
/retest-required |
@@ -1781,8 +1781,8 @@ func TestModSecurityForLocation(t *testing.T) { | |||
{"configmap enabled, configmap OWASP enabled, annotation enabled, OWASP disabled", true, true, true, true, false, "", "", ""}, | |||
{"configmap disabled, annotation enabled, OWASP disabled", false, false, true, true, false, "", "", fmt.Sprintf("%v%v", loadModule, modSecCfg)}, | |||
{"configmap disabled, annotation disabled, OWASP disabled", false, false, false, true, false, "", "", ""}, | |||
{"configmap disabled, annotation enabled, OWASP disabled", false, false, true, true, false, testRule, "", fmt.Sprintf("%v%v%v", loadModule, modsecRule, modSecCfg)}, | |||
{"configmap disabled, annotation enabled, OWASP enabled", false, false, true, true, false, testRule, "", fmt.Sprintf("%v%v%v", loadModule, modsecRule, modSecCfg)}, | |||
{"configmap disabled, annotation enabled, OWASP disabled", false, false, true, true, false, testRule, "", fmt.Sprintf("%v%v%v", loadModule, modsecRule)}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I guess this could be a problem. Why did you remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iamNoah1 I removed only modSecCfg which is (modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf) line. Becasue it shouldn't exist with modsecRule which is (modsecurity_rules).
Now, I reverted this change and now you can see the error is changed and now it is
"
=== RUN TestModSecurityForLocation
template_test.go:1805: configmap disabled, annotation enabled, OWASP disabled: expected 'modsecurity on;
modsecurity_rules '
#RULE#
';
modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;
' but returned 'modsecurity on;
modsecurity_rules '
#RULE#
';
'
template_test.go:1805: configmap disabled, annotation enabled, OWASP enabled: expected 'modsecurity on;
modsecurity_rules '
#RULE#
';
modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;
' but returned 'modsecurity on;
modsecurity_rules '
#RULE#
';
'
--- FAIL: TestModSecurityForLocation (0.00s)
"
These are the two tests that I have removed modSecCfg in the existence of modsecRule.
Can you advise on this.
Thank you:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, then probably I was wrong and your initial change was correct. Anyways I am not that familiar with the Code and will try to drag some more experienced devs in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I think I found it:
k8s.io/ingress-nginx/internal/ingress/controller/template internal/ingress/controller/template/template_test.go:1784:109: Sprintf format %v reads arg #3, but call has 2 args internal/ingress/controller/template/template_test.go:1785:108: Sprintf format %v reads arg #3, but call has 2 args
---> seems that your initial change was correct but you forgott to adjust the %v
s.
…late" This reverts commit 9d38eca.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see my last comment
@iamNoah1 MAN, YOU ARE THE BEST. I fixed it and now all tests have passed :) |
@rikatz Can you please review and approve |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
As far as I can say
hey, didn't read everything right now (sorry), but a question: I understand this is a bug, but can this also be a breaking change for folks already relying on modsecurity and this behavior? Thanks! |
@rikatz @iamNoah1 I will clarify who, what and how this will affect the folks who use modsecurity. 1- Default Configuration: Here Modsecurity is enabled by setting "enable-modsecurity: true". With this ModSecurity will run in “Detection-Only” mode using the default configuration. This PR is not affecting this way, as the line (modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;) will exist in the nginx config. 2- OWASP Core Rule Set: Here Modsecurity is enabled by "enable-modsecurity: true" and "enable-owasp-core-rules: true". Here usually modsecurity-snippet is not specified and thus the change will not affect it. But even if it is specified, there is already a logic to include this file "modsecurity_rules_file /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf;" as configuration/rule file, as this file includes some other rule files and a config file (crs-setup.conf). Thus, This PR is also not affecting this way. 3- Snippet: Here modsecurity is enabled by "enable-modsecurity: true" and "modsecurity-snippet: |-". This PR is only affecting this way of implementing Modsecurity. But this way is currently working as the first approach and not as it meant, because the custom settings you specify under "modsecurity-snippet: |-". will be overridden by the default config file. @iamNoah1 you are right:) Here people like these had to mount a volume in the controller container to override the default config in "/etc/nginx/modsecurity/modsecurity.conf". and I agree with you that those who have such workaround solutions won't be affected as they already include custom config/rule files under "modsecurity-snippet: |-". To summarize, This PR affects only approcah 3 and approach 3 is currently not working as expected and rather working like approach 1. Folks who want to use approach 3 need to explicitly write the settings/rules or include files under "modsecurity-snippet: |-" that has the custom settings and rules they need. So, I believe this shouldn't be a breaking change for anyone. |
@rikatz Have you managed to look into this and my answer above? |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: besha100, iamNoah1, rikatz The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…ified (kubernetes#8021) * Disabled default modsecurity_rules_file if modsecurity-snippet is specifed The default modsecurity_rules_file overwrites the ModSecurity-snippet if it is specified with custom config settings like "SecRuleEngine On". This will not let Modsecurity be in blocking mode even if "SecRuleEngine On" is specified in the ModSecurity-snippet configuration * Remove unnecessary comments Only have the default Modsecurity conf settings in case Modsecurity configuration snippet is not present and remove unnecessary comments * Fixed modsecurity default file only if Modsecurity snippet present Fixed if condition Modsecurity snippet present have modsecurity default config file * Added e2e test to disabling modsecurity conf Added e2e in case modsecurity-snippet enabled to disable settings in default modsecurity.conf * Validate writing to a different location Validate also modsecurity to write to a different location instead of the default directory * Fixed the formatting * Fixed if empty ModsecuritySnippet * Fixed ModsecuritySnippet condition * Fixed the condition also in ingress controller template * Removed the default config condition in ingress controller template * Fixed the default config condition in ingress controller template * Fixed pull-ingress-nginx-test * Revert "Fixed the default config condition in ingress controller template" This reverts commit 9d38eca. * Revert template_test * Adjusted the formating %v
The default modsecurity_rules_file (/etc/nginx/modsecurity/modsecurity.conf;) has settings that override the ModSecurity-snippet if it is specified with custom config settings like "SecAuditLog", "SecAuditLogStorageDir" and "SecRuleEngine On".
What this PR does / why we need it:
To disable the default modsecurity_rules_file (/etc/nginx/modsecurity/modsecurity.conf;) if custom modsecurity-snippet is specified
Types of changes
Which issue/s this PR fixes
6307
6438
4640
How Has This Been Tested?
In the values yaml file have the config below
config:
enable-modsecurity: "true"
enable-owasp-modsecurity-crs: "false"
modsecurity-snippet: |-
SecRuleEngine On
SecAuditEngine RelevantOnly
SecAuditLogParts ABIJDEFHZ
SecAuditLogRelevantStatus "^(?:05912300)"
SecAuditLogType Concurrent
SecAuditLog /var/tmp/modsec_audit.log
SecAuditLogStorageDir /var/tmp/
Then deploying the latest nginx controller
helm upgrade --install --values your-values-with-config-above.yaml your-release-name ingress-nginx/ingress-nginx --version 4.0.13
After you deploy, exec into one nginx pod and browse " /etc/nginx/nginx.conf ". You will find after your modsecurity custom config the below line is included
Browsing this file, you will find some settings that conflict with the settings in your "modsecurity-snippet: | " such as:
Verification:
make some suspicious traffic to your nginx ingress such as
curl http://your-url/index.html\?exec\=/bin/bash
Then when you exec into the nginx pod, you will see the logs are in "/var/log/modsec_audit.log" (from the default modsecurity file) instead of the customized configured one "/var/tmp/modsec_audit.log" in the (modsecurity-snippet)
This PR will not have this include file " modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf" in the nginx configuration file. After deploying this PR, all the custom modsecurity-snippet will take effect and not be overridden.
Then if you do suspicious traffic to your nginx ingress like the one above,t he audit log will be /var/tmp/modsec_audit.log , and SecRuleEngine On will be on the blocking mode according to the rules in your modsecurity-snippet
Checklist: