-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Feature request: Limit the number of rules processed per request #3112
Comments
Hi @no-sec-marko, thanks for shared your idea. I have had a very similar idea: monitoring a preset TX (or any custom) variable, and if it reaches the threshold, then terminate the transaction. If you want to look up the number of triggered rules, then it's a bit problematic this way, because you must provide a method how to count the triggered rules (eg. I assume if you use CRS, you don't want to count the rules from But may be this idea can help you to reduce the number of unwanted triggering. Please let me figure out how can we implement this, especially what would be the best way to configure these limits. If anyone has an idea related to this feature, please share that here. |
I'm not sure that the engine should stop processing rules. In CRS, the rule for blocking based on score is one of the last rules, so stopping to process would essentially skip blocking. However, if post-processing is the issue, then it would suffice to limit the output to audit / error logs. |
I do not really like the monitoring of a preset variable from a conceptual viewpoint. If you want to block when a certain rule is triggered, then issue a If you want to group rules together and block afterwards, then add a rule after the group and issue a I also second what @theseion stated: With a scoring rule set you can not simply stop processing and if you use ModSec to display additional information about a request in the logs in phase 5, then stopping to process a request effectively means you lack that information in the logs when you most need it. I think this is a rules problems and it should be dealt with in the rules. Circling back to the original reporter @no-sec-marko. Yes, this is a conceptual problem of every WAF. Given the WAF logs a ton of information it's like filling the access log of a webserver, but on steroids. You need to anticipate this when building your platform. The rule set could try to protect you, but the rule set is in a bad position to monitor its own execution and any monitoring would slow things down for the very rare case somebody tried to pull this of in the wild (I have never seen this obvious weakness being exploited). |
Description
A request will trigger many rules if it contains many special keywords. Each rule triggered per request is logged in
MODSEC_AUDIT_LOG
andERRORLOG
. As described in the "to reproduce" section, a single short request can trigger 125 rules: (SQLI=30, XSS=25, RFI=0, LFI=15, RCE=45, PHPI=10, HTTP=0, SESS=0, COMBINED_SCORE=141). The "attack string" can be improved and shortened and is only an example.This behavior could lead to a DoS attack depending on the post-processing (e.g. SIEM or monitoring). Therefore, it would be great if it was possible to limit the number of rules processed per request to reduce the possibility of a successful DoS attack.
To Reproduce
Steps to reproduce the behavior:
Use the Docker compose script from OWASP CRS: docker-compose.yml
Run following
curl
command to generate the output from Logs and dumps:Logs and dumps
Output of:
sudo cat tests/logs/modsec2-apache/modsec_audit.log | grep ZgF9vvENo2IGM29MSPNYswAAAJc
modsec_audit.log
Expected behavior
Modsecurity has the ability to limit the rules by using a parameter.
Server (please complete the following information):
image: owasp/modsecurity-crs:apache
Rule Set (please complete the following information):
Following Rule Set was used (commit f2ab9c3063fece423e6a4156aad145f7f7e6ef96) CRS Rules
The text was updated successfully, but these errors were encountered: