|
From: Patrick R. <P.R...@ma...> - 2022-03-11 21:20:40
|
Thanks Andrew for the great reply. I’ll have a think about what you’re saying 😊 The site is a PHP based LMS (Learning Management System) – and it is behind a Paywall (i.e. you need an OAuth2 token). It’s probably what I would call an intermediately sized site. The site is generally very “chatty” – i.e. a single user can legitimately load hundreds/thousands of small artifacts (i.e. javascript, images, various small/inexpensive resources). So there is a large amount of “background noise” to the platform. Where we have run into a problem, is exactly what you have outlined. Recently we had thousands of requests within a short period of time (less than a minute) to an expensive PHP resource. Although it didn’t take the site down, it caused degraded performance in the frontend and an unusual drop in free PostgreSQL DB connections which was concerning. Upstream we actually have a pool of Citrix Netscalers – but when we tried making use of the Citrix recommended DoS features, we found that we ended up hitting up many false positives (just due to the legitimate “background noise” that individual users generated). Perhaps there is a way for the Netscalers to handle URL based rules (with counters), but the Netscalers seem to be more focused on protection against massive DoS style events. Perhaps a combination of the HTTPD frontends protecting “sensitive” PHP resources, and also making use of the Citrix DoS features (for truly “DoS Style” events) would be a good combination. I don’t think the Netscalers are the best way to protect individual resources, though – it appears to be too coarse a tool for this purpose. Thanks, Patrick From: Andrew Howe <and...@lo...> Date: Saturday, 12 March 2022 at 9:05 AM To: mod...@li... <mod...@li...> Subject: Re: [mod-security-users] Rate Limiting Apache: Units associated with "burst_rate_limit" ? Hi Patrick, > Thanks for the reply, but I’m actually just wanting to protect a small portion of the site. Almost all of the site can and should run without restrictions, except for some PHP scripts that (if hit repeatedly) cause performance issues. If your solution is designed to stop *trusted users* from accidentally pushing too hard on expensive PHP scripts then you might get away with using ModSecurity for simple rate limiting. If, on the other hand, you're looking for real denial of service defence against malicious clients then you really don't want to be using Apache+ModSecurity to provide that. In a production environment, when Apache+ModSec DoS rules are put under pressure, you end up seeing truly *staggering* resource usage (namely RAM), blocking can be unreliable, odd error messages appear complaining about accessing the underlying database files, the database files themselves can quickly balloon and consume the file system (they need regular pruning), and the whole thing just crumbles really easily. You mentioned that you only want to rate limit requests to certain URLs, which rules out doing anything clever at the network layer. I'm personally moving all my use of Apache+ModSec DoS rules over to a simple HAProxy instance sitting in front of Apache, which works perfectly (HAProxy has a highly efficient key-value store, "stick tables", which achieves much the same thing as the ModSec DoS rules, but the configuration is simpler and the setup is extremely reliable with only a fraction of the resource use). And there are other options, too, like mod_qos, as mentioned earlier in the thread. Have a good weekend. Thanks, Andrew -- Andrew Howe Loadbalancer.org Ltd. https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.loadbalancer.org%2F&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C62cb2ccddf8940ccbc9808da039a8872%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637826259509989850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LtV3e70Co2LjrpIZe7UQ3IVPRnj7uNUTbWJQ40QWddk%3D&reserved=0 +1 888 867 9504 / +44 (0)330 380 1064 _______________________________________________ mod-security-users mailing list mod...@li... https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fmod-security-users&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C62cb2ccddf8940ccbc9808da039a8872%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637826259509989850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dl2NbKysyCIh8hXoYdXl5B6x5ZbTSehq5dOjutJymLs%3D&reserved=0 Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.modsecurity.org%2Fprojects%2Fcommercial%2Frules%2F&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C62cb2ccddf8940ccbc9808da039a8872%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637826259509989850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0MW1JqV2e7hNdC9gNZzGojovJhVPa33Fcdd56d%2FIREc%3D&reserved=0 https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.modsecurity.org%2Fprojects%2Fcommercial%2Fsupport%2F&data=04%7C01%7CP.Rynhart%40massey.ac.nz%7C62cb2ccddf8940ccbc9808da039a8872%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637826259509989850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ChOvB0BNq86UY7xV4uM1nByAV%2B1cOgn9x1sdJKOpqPM%3D&reserved=0 |
