Today, I did detailed testing of the the Rate rules in edg.io v7
Issue 1 below is a significant flaw in Rate rules, and I think it is important as a determined DDoS attacker will definitely easily break through it, so I consider it something that needs to be fixed.
Suggestion 2 and 3 below are reasonable suggestions, but I am realistic and I don’t think system changes are easily, so I consider them suggestions.
Issue 1)
If you refer to the manual at Rate Rules | Edgio Documentation,
There’s a well-explained good example titled “Sample Scenario 1: Rate Limiting All Requests”,
According to the explanation of this example, a separate rate limit is applied to each page address.
That is, index.html, styles.css, logo.png have different rate limits.
This also matches actual tests results.
A significant advantage is that it can reduce false positives compared to many security companies that rate limit the number of requests for all URLs, as including all urls has the problem of including css/js/image files too. I know people who dislike Cloudflare’s rate limit because seperate rate limit for different urls is not implemented.
However, since there is no rate limit on the number of requests for all URLs in edg.io and there is no automatic function to block the entire IP, the following is possible:
If https://www.testdomain.com/test.php is rate limited,
You can bypass the block immediately and access it through https://www.testdomain.com/test.php?1 then if that is blocked https://www.testdomain.com/test.php?2 will again bypass the rate limit.
Also, if you change the address randomly during a DDoS attack, it will not be blocked.
I can’t find any way to solve this signficant issue using edg.io rules and I suspect any determined DDoS attacker would quickly test and change blocked url requests and furthermore randomize the request urls to basically bypass edg.io Rate rules.
Suggestion 2)
What I think is an appropriate method is
to add a combined rate limit for all URLs during rate limiting (which is generally the standard rate limit strategy for other security services),
and if you hit each rate limit setting, let the site operator choose a certain period to block that IP across the entire hostname and allow the site operator to use a captcha or JS browser challenge so that the user can unblock the IP and access it using an authentication cookie, etc.
Suggestion 3)
It would be nice if there were a “Rate limit analysis” like the one at Find an appropriate rate limit · Cloudflare Web Application Firewall (WAF) docs in edg.io, but since the operating principle of the edg.io rate limit is different, I would think it would be much more difficult to implement on the edg.io side.
However, after reading the explanation at Rate Rules | Edgio Documentation, “Security does not perform further evaluation of a request once enforcement is triggered.” “We recommend that you limit your use of the Alert Only enforcement to the shortest amount of time necessary to validate changes to your configuration.”, I was surprised because setting it to alert will make requests that are alerted and logged pass all the edg.io security filters afterwards and the testing with alert can be quite dangerous depending on the case, and it seems difficult to test for a long time, so a feature to assess rates seems even more necessary.
Hopefully this can be improved.
Thank you.