Quote:
Our experience is everything contributes to performance and applying something to the front end of the web server will definitely effect performance. When you discount performance off-hand,
I think it is great you emphasize the importance of performance but continuing to put emphasis on it begs the question why you did not see fit to address it in your OP (original post)?
Quote:
I can only assume you do not operate a web server with thousands of concurrent users and millions of PVs a month.
By introducing this argument you imply that
you do. Besides, you know what assumptions make.
Quote:
mod_security performance quotes
Mod_security can have an impact performance-wise. I don't disagree with that (as I've stated already). But the fact that you counter by just quoting two or more year old articles (one of which used ModSecurity v1 rules instead of ModSecurity v2) and neglect to seize the offered opportunity to back up your claim by presenting numbers (like
this?) doesn't help me address this part of the discussion.
Quote:
I think you may be arguing for the sake of argument.
* BTW, comments like this, just like your previous "hand waving" comment, are utterly unnecessary as they do not help discussion and understanding. Perception-wise they tell readers more about
you than they do about me.
Quote:
Everything effects performance.
OK. Let's see if I can help you address some shortcomings that will impact performance:
0. I did not present a huge list of filters to use, not even the OWASP CRS, but the idea of using a single rule like 'SecRule REQUEST_URI "/w00tw00t"'. So while your emphasis on performance may have been justified in general it does not directly address my suggestion.
1. Grepping logs for "w00tw00t" after means your rules will always be out of date and incomplete (as opposed to say using a single raw table --hex-string "|2f 77 30 30 74|"?).
2. You're offering a list (novirusthanks dot org) that
seems unvetted, evidenced by the fact that none of the major Linux security websites point to it. The dangers of using such lists, just like using unmaintained, uncontrolled or subjective RBL's, I don't need to point out.
3. Blocking IP addresses based on a single request makes it easy to deny clients access to the service. What's more is that since you block a /24 one only needs one address inside the subnet.
4. Blocking IP addresses based on a single request makes it easy to exhaust memory allocated for rules.
5. Your OP does not present any rule management. Without pointing that out rules, including obsoletes, will just be added which impacts performance.
6. Since linear filtering is in effect all rules must be traversed until a match is found. So dumping all your rules in the INPUT chain (conntrack?) will impact performance. (How about using the raw table, ipset, nf-hipac?).
Granted, you did ask for "Anyone care to combine all this into one great script?" and finding your precious post is getting commented on may hurt a bit, but you implying to "operate a web server with thousands of concurrent users and millions of PVs a month" makes me wonder if the script you wrote in your OP would have ever made it onto such a high-performance web server and if it did how long it would last before being ripped out because of aforementioned shotcomings. Then again you may safely dismiss all of the above as I am no security expert, just an average GNU/Linux user with a grain of common sense...
Good luck with fixing your script!