Open no-sec-marko opened 1 month ago
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 crs-setup.conf
, REQUEST-901-INITIALIZATION.conf
, neither from any exclusions config).
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 deny
with the rule.
If you want to group rules together and block afterwards, then add a rule after the group and issue a deny
in this group.
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:
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