Rack-атака и фильтрация Allow2Ban в рельсах 4

Question

Я реализую Rack-атаку Kickstarter в своем приложении rails.

Фильтрация белого / черного списков работает нормально, но у меня возникают проблемы с использованием Allow2Ban для блокировки IP-адресов, которые забивают мою страницу sign_in (Devise). Примечание: я проверяю это локально и удалил localhost из белого списка.

# Lockout IP addresses that are hammering your login page.
# After 3 requests in 1 minute, block all requests from that IP for 1 hour.
Rack::Attack.blacklist('allow2ban login scrapers') do |req|
  # `filter` returns false value if request is to your login page (but still
  # increments the count) so request below the limit are not blocked until
  # they hit the limit.  At that point, filter will return true and block.
  Rack::Attack::Allow2Ban.filter(req.ip, :maxretry => 3, :findtime => 1.minute, :bantime => 1.hour) do
    # The count for the IP is incremented if the return value is truthy.
    req.path == '/sign_in' and req.post?
  end
end

В документации по Rack-атакам четко указано, что для функциональности регулирования требуется кэширование, а именно:

Rack::Attack.throttle('req/ip', :limit => 5, :period => 1.second) do |req| )

, но это не заявляет это для Allow2Ban. Кто-нибудь знает, требуется ли кеш для Allow2Ban, или я неправильно внедряю с кодом выше на странице входа Devise

Answer 1

Да, Allow2Ban и Fail2Ban определенно нуждаются в сцеплении (в https://github.com/kickstarter/rack-attack/blob/master/lib/rack/attack/fail2ban.rb вы можете увидеть, как и почему). Btw. Я предлагаю использовать Redis в качестве кэша, поскольку он гарантирует, что ваше приложение блокирует IP-адрес, даже если вы используете более одного узла приложения. Если вы используете кеш Rails в сценарии с несколькими приложениями, ваши фильтры будут управляться для каждого экземпляра, а это не то, что вы хотели бы предположить.