On Thu, Mar 9, 2023 at 12:27 AM Rémy Maucherat <r...@apache.org> wrote:
> 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. > True, and in most Prod deployments I do that on the reverse proxy server, but it'd be nice to have a simple solution that can be used without having to configure another server. > > As for filter or valve, well, it's your choice ;) > Sounds good. I think that I will start with a Filter implementation but the core logic will be in reusable classes so it will be very easy to add a Valve if others think that it's beneficial. Igal > > Rémy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
