Permite ver o estado atual de todos os aceleradores e proibições. Exclua chaves/proibições existentes. Adicione proibições manualmente.
Inspirado em: https://www.backerkit.com/blog/building-a-rackattack-dashboard/
Adicione esta linha ao Gemfile
da sua aplicação:
gem 'rack_attack_admin'
Adicione esta linha ao config/routes.rb
do seu aplicativo:
mount RackAttackAdmin :: Engine , at : '/admin/rack_attack'
Vá para http://localhost:3000/admin/rack_attack no seu navegador!
Você também pode usar o comando de linha de comando somente leitura fornecido, rake rack_attack_admin:watch
em vez da interface da web:
+-------------------------------+--------------------+
| 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'):[email protected] | 1 | |
| throttle('req/ip'):127.0.0.1 | 2 | 1 |
+----------------------------------------------------------------------------------+---------------+--------------------+
Para permitir que suas regras Fail2Ban/Allow2Ban sejam examinadas por este aplicativo, você deve defini-las de maneira um pouco diferente da documentação upstream do Rack::Attack que diz para você defini-las:
Se você tiver um filtro Allow2Ban em uma lista de bloqueio como esta:
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
, você pode alterá-lo para esta definição equivalente:
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
salva sua configuração em um hash (por nome, sem discriminador), da mesma forma que throttle
.
Os métodos fail2ban
/ allow2ban
são simplesmente wrappers para Rack::Attack::Allow2Ban.filter
que procuram e usam as opções da definição (que corresponde ao nome fornecido).
Isto tem as seguintes vantagens:
throttle
: # 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
limit
e period
em vez das opções maxretry
e findtime
, respectivamente.Fail2Ban.filter
padrão. Isso é totalmente opcional. Se você optar por não defini-los desta forma, ainda mostrará as chaves e o valor do contador fail2ban; ele simplesmente não será capaz de encontrar a regra correspondente e, portanto, não será capaz de mostrar qual é o limite ou intervalo de tempo para essa chave de contador. Então, em vez de mostrar o limite para allow2ban('login')
como mostra a imagem acima, ele voltará a mostrar apenas o pouco que pode mostrar sobre essa chave:
Isso foi testado com Rack::Attack.cache.store
definido como uma instância de:
Redis::Store
da fantástica joia da redis-store. (Que é usado pelo ActiveSupport::Cache::RedisStore
(das gemas redis-activesupport/redis-rails))ActiveSupport::Cache::RedisCacheStore
(fornecido por Rails 5.2+) Relatórios de bugs e solicitações pull são bem-vindos no GitHub em https://github.com/TylerRick/rack_attack_admin.