On Wed, Mar 8, 2023 at 8:37 PM Igal Sapir <isa...@apache.org> wrote: > > All, > > I would like to add a Rate Limiter Filter or Valve which will help mitigate > DoS and Brute Force attacks, and want to get feedback from the community > and the PMC. The checks will run before the request reaches the servlet > and will be dropped if too many requests arrive from the same IP address > within a certain time window. > > It has been suggested that a Valve might be the better choice because it > can be set up on a Host or Engine level, but in my opinion a Filter is a > good choice for the following reasons: > > 1) While in the past it was common to reuse the same server for different > applications due to costs and challenges in setting up servers, nowadays it > is more common to set up a single application per server, many times in a > containerized environment, so setting up a Rate Limiter on a Host or Engine > does not offer much benefit over setting it up on the Context level. > > 2) Different applications have different requirements In fact, different > URIs of the same application could have different requirements: a Login / > Authentication script expects far less requests from a single IP address > compared to a Dashboard page, for example. Filter mapping allows us to map > different URIs to different configurations. > > 3) Filters are part of the Servlet spec, and therefore more users are > familiar with them and know how to configure them. > > Either way it is implemented, I propose the following requirements for the > Rate Limiter itself (with the possibility of adding some of the features > later): > > A) Low overhead - The checks will take place with every request so the > implementation must be efficient and make good utilization of resources. > > B) Close approximation is good enough - If a URI is configured to allow 300 > requests per minute and instead it allows 300 requests per 1:05 minute > before dropping the requests then that should be good enough, if that > allows the implementation to be more efficient with computation time and > memory consumption. The approximation can offer leniency but not > strictness, meaning that it's ok if it allows more requests than the > configured value, but not less. > > C) Drop excessive requests - Requests from an IP that exceeds the allowed > limit will be dropped and "429 Too Many Requests" will be returned to the > client. > > D) Tag only mode - If configured as such, then rather than dropping the > request with a 429 error code, a Request Attribute will be set and that > would allow the Servlet to determine what to do next, e.g. it might allow > authenticated clients more requests than it would to unauthenticated > clients. > > E) Allow list of URI patterns - Static resources have very little overhead, > so requests for "*.jpg" or "*.png" should not be counted by the Rate > Limiter. > > F) Allow list of IP addresses - Known IP addresses that are used by your > organization, or 3rd party partners, should not be blocked. > > G) Block list of IP addresses - Repeat offenders can be added automatically > to the block list for 4 hours, for example, preventing them from hitting > the server each minute and contributing to a DDoS attack. > > H) Logging > > Please offer your thoughts and ideas.
That's a good feature idea overall. Of course, no matter what you do, it's going to be better if done on a front end server, and any serious setup will do it like that. As for filter or valve, well, it's your choice ;) Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
