-
Notifications
You must be signed in to change notification settings - Fork 300
Allow enabling modsecurity per request #303
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
Allow enabling modsecurity per request #303
Conversation
Note: This PR needs tests, and I am working on those.
Also, it's a bit silly that they were left out, but this PR needs updates to the header and body filter as well.
It's also a bit risky for this PR to depend on a variable that might change after ModSecurity begins progressing through the phases, so it probably would make sense to just evaluate modsecurity_enabled once at the beginning of processing and then save that as a constant value that is stable throughout the request.
Hello @brandonpayton ,
I'm not very clear on what you are proposing.
But based on the title and main portion of the description, it sounds like maybe what you want to do is already possible.
The action ctl:ruleEngine can be set to On or Off conditionally based on the rule that it is part of. Have you considered that as an option?
If for some reason you don't think that would address your needs, could you perhaps give a more concrete example of what you're trying to do?
Hi @martinhsv, thank you for your feedback and questions. I will try to clarify.
As a web host, our goal is to dynamically control whether ModSecurity processes each request. For an example, let's say we have an nginx config that is shared across multiple servers, and we want to declaratively enable/disable ModSecurity processing for:
- specific servers
- specific sites on a server with many sites
- arbitrary request details like URI, query param, etc
The action ctl:ruleEngine can be set to On or Off conditionally based on the rule that it is part of. Have you considered that as an option?
As you mentioned, it might be possible to meet our needs by using rules to dynamically disable the rule engine, but this is not ideal for a couple of reasons:
- When disabling ModSecurity for a given request, we prefer that ModSecurity processing does not run at all. If we are having any trouble with ModSecurity, we want to be able to selectively, completely cut it out of the loop per site or per server. So the same nginx server could enable/disable ModSecurity processing entirely depending on which site or other factors.
- We have a large number of existing nginx map declarations that we leverage to control the processing of a request, and for simplicity and maintainability, we would like to continue declaring our intentions via nginx config rather than maintaining a separate set of ModSecurity rules to accomplish the same thing. To accomplish this, we need to be able to set the value of the
modsecuritydirective using an nginx variable rather than a static "on|off" value, and that is the intent of this PR.
Does that make sense?
Hi @brandonpayton,
could you provide a real-life example (with using of mentioned nginx map features)? As I remember I haven't used them yet, and would be fine to understand this feature.
Quality Gate Passed Quality Gate passed
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code
This updates the
modsecuritydirective to allow the use of variables in the directive value.We use it so that ModSecurity-nginx can be enabled or disabled per request based on variables set via nginx map which in turn can look at various aspects of a request to render an "on" or "off" value.