Igal,
On 3/8/23 14:36, Igal Sapir wrote:
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.
Counter-point: an attacker can make requests to non-existent contexts
and avoid your Filter. You could put the Filter on the ROOT application
as well, but (a) nobody will remember to do that and (b) it won't share
data with the primary web application.
Honestly, it should pretty easy to write a general rate-limiter and then
wrap a Filter and/or Valve around it.
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.
+1
3) Filters are part of the Servlet spec, and therefore more users are
familiar with them and know how to configure them.
+1
A Filter is also portable to other containers. Speaking of which... has
this wheel already been invented? I would be surprised if Spring
Security doesn't already have this kind of thing.
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.
+1
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.
Avoid regular expressions. For IP range matching, search the archives
for references to CIDR. I think there was a discussion some years ago
about that. In fact, I there should be a CIDR evaluator/matcher
somewhere in the Tomcat source code already.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
