You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, rate-limiting in aw is required to be implemented at the application-level. It assumes that the application has the best information about per-message rate limits, and to him to apply them. While this remains true, it is still worth implementing a basic rate-limiter.
The rate-limit should be implemented using a standard rate-per-second with temporary burst. If the rate-limit is violated, then the offending IP address is blacklisted. This drops the existing connection, and refuses connections from this IP address until the end of blacklist timeout. If the IP address attempts connections during this blacklisted period, then the period is extended by the back-off factor (multiplying the current time left by the back-off factor).
Add an option for the blacklist timeout (default: 30 seconds)
Add an option for the blacklist timeout back-off (default: 1.6)
Violation of the rate-limit drops the connection and blacklists the IP address
Recent offenders should be stored in-memory, but also saved on-disk in the case of an unexpected reboot. Assuming all IP addresses are 128 bits, an in-memory limit of 1MB would allow for 65,536 offenders before the server begins to drop attackers. In the case that this limit is reached, the least recent offender will be dropped from the list (implying that the offender is forgiven).
Store offenders in-memory (default: 65,536 addresses)
Save offenders on-disk and load them at boot
Forgive least recent offenders when in-memory limit is reched
The text was updated successfully, but these errors were encountered:
loongy
changed the title
Rate-limiting with eventual blacklisting
Rate-limiting with exponential blacklisting
Apr 7, 2020
Currently, rate-limiting in
aw
is required to be implemented at the application-level. It assumes that the application has the best information about per-message rate limits, and to him to apply them. While this remains true, it is still worth implementing a basic rate-limiter.The rate-limit should be implemented using a standard rate-per-second with temporary burst. If the rate-limit is violated, then the offending IP address is blacklisted. This drops the existing connection, and refuses connections from this IP address until the end of blacklist timeout. If the IP address attempts connections during this blacklisted period, then the period is extended by the back-off factor (multiplying the current time left by the back-off factor).
Recent offenders should be stored in-memory, but also saved on-disk in the case of an unexpected reboot. Assuming all IP addresses are 128 bits, an in-memory limit of 1MB would allow for 65,536 offenders before the server begins to drop attackers. In the case that this limit is reached, the least recent offender will be dropped from the list (implying that the offender is forgiven).
The text was updated successfully, but these errors were encountered: