-
Notifications
You must be signed in to change notification settings - Fork 1.7k
High CPU usage when processing certain rules #1341
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
Comments
@anderpups what's the complete SecRule/Action associated with that logging you shared?
|
@bostrt thanks for the response. After more digging, we have figured out rule 973302 is causing this condition. I also realized that it can also be replicated with "SecRuleEngine On" so please disregard any reference to the different modes. There was some uniqueness to to the requests that I hadn't taken into consideration at first. I still think this may be a bug since mod_security doesn't actually do any blocking of that rule, but the CPU pegs to 100% while inspecting the traffic when this rule is enabled. Please let me know if you still need the SecRule/Action config. Thanks
|
@anderpups just noticed you ModSecurity version is almost 4 years old (v2.7.3). Can you reproduce on the latest 2.9.1? |
@anderpups this is a function of the regular expression used in that rule, not the ModSecurity engine itself. That regular expression is really very poorly formed, and will undergo some very significant backtracking when comparing against a target of that size. It looks like you're using the old OWASP CRS v2; consider upgrading to v3 (https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0/master), which was redesigned to avoid ugly expressions like this. |
When mod_security is in SecRuleEngine DetectionOnly mode certain POSTs cause high CPU usage and a long delay on the return. This does not happen when mod_security is in SecRuleEngine On or mod_security is disabled.
I believe this may be the same bug referenced in #890
Below in the strace, you can see the gap in the times:
mod_sec_debug log:
Apache error_log:
System version and whatnot:
Thanks
The text was updated successfully, but these errors were encountered: