Rack::Attack Admin Dashboard

Lets you see the current state of all throttles and bans. Delete existing keys/bans. Manually add bans.

Inspired by: https://www.backerkit.com/blog/building-a-rackattack-dashboard/

Add this line to your application's Gemfile:

gem 'rack_attack_admin'

Add this line to your application's config/routes.rb:

mount RackAttackAdmin::Engine, at: '/admin/rack_attack'

Go to http://localhost:3000/admin/rack_attack in your browser!

You can also use the provided read-only command-line command, rake rack_attack_admin:watch instead of the web interface:

+-------------------------------+--------------------+
| Banned IP                     | Previous (5 s ago) |
+-------------------------------+--------------------+
| allow2ban:ban:login-127.0.0.1 |                    |
+-------------------------------+--------------------+
+----------------------------------------------------------------------------------+---------------+--------------------+
| Key                                                                              | Current Count | Previous (5 s ago) |
+----------------------------------------------------------------------------------+---------------+--------------------+
| ('allow2ban:count'):login-127.0.0.1                                              | 2             | 1                  |
| throttle('logins/ip'):127.0.0.1                                                  | 1             |                    |
| throttle('logins/email'):me@example.com                                          | 1             |                    |
| throttle('req/ip'):127.0.0.1                                                     | 2             | 1                  |
+----------------------------------------------------------------------------------+---------------+--------------------+

In order to allow your Fail2Ban/Allow2Ban rules to be introspected by this app, you must define them slightly differently than the upstream Rack::Attack documentation tells you to define them:

If you have an Allow2Ban filter in a blocklist like this:

  blocklist('login:allow2ban') do |req|
    Rack::Attack::Allow2Ban.filter("login-#{req.ip}", maxretry: 5, findtime: 1.minute, bantime: 10.minutes) do
      # The count for the IP is incremented if this return value is truthy.
      is_login.(req)
    end
  end

, you can change it to this equivalent definition:

  blocklist('login:allow2ban') do |req|
    def_allow2ban('login', limit: 5, period: 1.minute, bantime: 10.minutes)
    allow2ban(    'login', req.ip) do
      is_login.(req)
    end
  end

def_fail2ban/def_allow2ban save your configuration in a hash (by name, without discriminator in it), much the same as throttle does.

fail2ban/allow2ban methods are simply wrappers for Rack::Attack::Allow2Ban.filter that look up and use the options from the definition (that matches the given name).

This has the following advantages:

• It actually stores your Fail2Ban rule so that we can look it up later
• It provides an API and options that are more similar to and consistent with regular throttle commands:

  # Compare:
  def_allow2ban('login', limit: 5, period: 1.minute, bantime: …)
  allow2ban('login', discriminator) do
    # Return truthy value to increment counter
  end
  # allow2ban returns true if counter reaches limit
  
  throttle('logins/email', limit: 5, period: 1.minute) do |req|
    discriminator.(req)
  end

• You can use the familiar limit and period options instead of maxretry and findtime options, respectively.
• You don't have to interpolate the discriminator into a string like you do with the standard Fail2Ban.filter syntax.

This is completely optional. If you choose not to define them this way, it will still show your fail2ban counter keys and value; it just won't be able to find the matching rule, and therefore won't be able to show what the limit or time bucket is for that counter key. So instead of showing the limit for allow2ban('login') like it shows in the screenshot above, it will fall back to just showing what little it can show about that key:

This has been tested with Rack::Attack.cache.store set to an instance of:

• Redis::Store from the fantastic redis-store gem. (Which is used by the ActiveSupport::Cache::RedisStore (from redis-activesupport/redis-rails gems))
• ActiveSupport::Cache::RedisCacheStore (provided by Rails 5.2+)

Bug reports and pull requests are welcome on GitHub at https://github.com/TylerRick/rack_attack_admin.