-
Notifications
You must be signed in to change notification settings - Fork 282
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
Question about conflicting modsecurity_rules/modsecurity_rules_file precedence #280
Comments
Hi @mac-chaffee , I'd have to take a more in-depth look to provide a definitive answer, but a similar-sounding question arose at least once before ( #183 ). The hypothesis in that case was that using two different nginx directives (i.e. both 'modsecurity_rules' and 'modsecurity_rules_file') may result in the precedence of those directives being dominant. Based on that earlier issue, if you were to use either 'modsecurity_rules' or 'modsecurity_rules_file' in both of those cases, that would likely give you the 'last wins' behaviour that you are expecting. |
'modsecurity_rules' and 'modsecurity_rules_file' have precedence of their own outside of just the order in which they're listed in nginx.conf? Just skimming the code, it looks like those directives both just edit the same RulesSet struct: Which calls these functions: |
Oh I do see they are changing EDIT: oh that's just a counter, nvm I should stop guessing haha |
it will just merge. |
Anything more on this? |
Yes, sounds like we haven't identified exactly what should take precedence over what. It would be good to document this somewhere because the prevailing wisdom is incorrect: that last writer always wins and they will "just merge". In my experiments, it seems that We'd need a firm answer on how rule precedence works in modsecurity-nginx before documenting anything I think. |
So your issue is resolved? -- perhaps by using either of those directives both times and not mixing? |
If mixing I'd be happy to contribute documentation and inform the ingress-nginx folks (they mix directives too), just not sure what to tell them. |
Hi @mac-chaffee , I didn't say it isn't supported. I was only suggesting:
At the moment, I cannot really devote time to investigating a more in-depth answer. I did hope, however, to help you deal with your immediate issue. |
Any new info here? What's the expected behaviour with both "modsecurity_rules" and "modsecurity_rules_file" options in use, as that's what you easily end up with when using k8s ingress-nginx modsecurity features and config options.. |
This question is in relation to some troubles the downstream ingress-nginx project has with modsecurity: kubernetes/ingress-nginx#8388
When conflicting modsecurity rules/settings are loaded, how is that conflict resolved? Is it always "last write wins"? Seems that's not always the case.
For example, say I have the following config:
If "last write wins", I would expect that
modsecurity_rules 'SecRuleEngine On';
would do nothing; the subsequent line would override that and set the mode to DetectionOnly. But for me, the mode stays "On" with the above config and requests get blocked instead of just logged. However other users have reported the opposite behavior as well: kubernetes/ingress-nginx#8021Looking at the source code, I would expect that "last write wins" is the intended behavior: https://github.com/SpiderLabs/ModSecurity/blob/5519f6cfae45a47d8dc3ac1b084319611a9b386b/headers/modsecurity/rules_set_properties.h#L45-L48
But are there situations where "last write wins" doesn't hold?
The text was updated successfully, but these errors were encountered: