From a6bbbdc779f875b035c8a40464488df8256f2d06 Mon Sep 17 00:00:00 2001 From: Nate Berkopec Date: Fri, 16 Dec 2022 15:22:34 +0900 Subject: [PATCH] Add note about cache stores and in-memory caches. This was part of the "lessons learned" from Bannerbear's DDoS attack: https://www.bannerbear.com/blog/how-to-survive-a-ddos-attack/ --- README.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index fb8aa21..545003c 100644 --- a/README.md +++ b/README.md @@ -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