sjs/rack-attack
1
0
Fork 0
mirror of https://github.com/samsonjs/rack-attack.git synced 2026-03-25 09:25:49 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add note about cache stores and in-memory caches.

Browse source 
This was part of the "lessons learned" from Bannerbear's DDoS attack: https://www.bannerbear.com/blog/how-to-survive-a-ddos-attack/
This commit is contained in:
Nate Berkopec 2022-12-16 15:22:34 +09:00 committed by GitHub
parent 4d201f7e42
commit a6bbbdc779
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
README.md
View file

@ -305,10 +305,15 @@ end
Throttle, allow2ban and fail2ban state is stored in a configurable cache (which defaults to `Rails.cache` if present), presumably backed by memcached or redis ([at least gem v3.0.0](https://rubygems.org/gems/redis)).
```ruby
Rack::Attack.cache.store = ActiveSupport::Cache::MemoryStore.new # defaults to Rails.cache
# This is the default
Rack::Attack.cache.store = Rails.cache
# It is recommended to use a separate database for throttling/allow2ban/fail2ban.
Rack::Attack.cache.store = ActiveSupport::Cache::RedisCacheStore.new(url: "...")
```
Note that `Rack::Attack.cache` is only used for throttling, allow2ban and fail2ban filtering; not blocklisting and safelisting. Your cache store must implement `increment` and `write` like [ActiveSupport::Cache::Store](http://api.rubyonrails.org/classes/ActiveSupport/Cache/Store.html).
Most applications should use a new, separate database used only for `rack-attack`. During an actual attack or periods of heavy load, this database will come under heavy load. Keeping it on a separate database instance will give you additional resilience and make sure that other functions (like caching for your application) don't go down.
Note that `Rack::Attack.cache` is only used for throttling, allow2ban and fail2ban filtering; not blocklisting and safelisting. Your cache store must implement `increment` and `write` like [ActiveSupport::Cache::Store](http://api.rubyonrails.org/classes/ActiveSupport/Cache/Store.html). This means that other cache stores which inherit from ActiveSupport::Cache::Store are also compatible. In-memory stores which are not backed by an external database, such as `ActiveSupport::Cache::MemoryStore.new`, will be mostly ineffective because each Ruby process in your deployment will have it's own state, effectively multiplying the number of requests each client can make by the number of Ruby processes you have deployed.
## Customizing responses