Unblocking an IP when using Dalli (memcached)

[chrisedington]

Hi there,

I have a fairly simple question but I cant seem to find a concrete answer. I would like to go live with the below configuration, however I need to be able to unblock an IP incase one of our customers is blocked in error.

I'm using the Dalli Memcached store, and by the looks of it you cant narrow down a specific key and remove it.

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

This article was very informative, however it doesn't look like it's going to work with Dalli.

Any recommendations how I can unblock an IP in the event of a erroneous block?

#config/environments/production.rb

config.cache_store = :dalli_store, {:expires_in => 1.hour, :compress => true }

#config/initializers/rack_attack.rb

ActiveSupport::Notifications.subscribe('rack.attack') do |name, start, finish, request_id, req|
  Raven.capture_message(
    'IpRateLimit',
    logger: 'ip_rate_limit',
    level: 'warning',
    extra: {
      error_message: "#{req.ip} has been rate limited for url #{req.url}",
    }
  )
end
class Rack::Attack

  ### Configure Cache ###
  BANNED_PATHS = %w(
    wp-admin
    wp_admin
    wp-login
    wp_login
    /../
    /etc/passwd
    phpmyadmin
  ).freeze

  Rack::Attack.safelist('allow from localhost') do |req|
  # Requests are allowed if the return value is truthy
    '127.0.0.1' == req.ip || '::1' == req.ip || 'xxxxxx' == req.ip || 'yyyyy' == req.ip || 'xxxxx' == req.ip || 'yyyy' == req.ip || 'xxxx'  == req.ip
  end

  # If you don't want to use Rails.cache (Rack::Attack's default), then
  # configure it here.
  #
  # Note: The store is only used for throttling (not blocklisting and
  # safelisting). It must implement .increment and .write like
  # ActiveSupport::Cache::Store

  # Rack::Attack.cache.store = ActiveSupport::Cache::MemoryStore.new 
  Rack::Attack.throttled_response_retry_after_header = true
  ### Throttle Spammy Clients ###

  # If any single client IP is making tons of requests, then they're
  # probably malicious or a poorly-configured scraper. Either way, they
  # don't deserve to hog all of the app server's CPU. Cut them off!
  #
  # Note: If you're serving assets through rack, those requests may be
  # counted by rack-attack and this throttle may be activated too
  # quickly. If so, enable the condition to exclude them from tracking.

  # Throttle all requests by IP (60rpm)
  #
  # Key: "rack::attack:#{Time.now.to_i/:period}:req/ip:#{req.ip}"
  throttle('req/ip', limit: 300, period: 5.minutes) do |req|
    req.ip unless req.path.start_with?('/assets')
  end

  ### Prevent Brute-Force Login Attacks ###

  # The most common brute-force login attack is a brute-force password
  # attack where an attacker simply tries a large number of emails and
  # passwords to see if any credentials match.
  #
  # Another common method of attack is to use a swarm of computers with
  # different IPs to try brute-forcing a password for a specific account.

  # Throttle POST requests to /login by IP address
  #
  # Key: "rack::attack:#{Time.now.to_i/:period}:sign_ups/ip:#{req.ip}"
  throttle('sign_ups/ip', limit: 5, period: 20.seconds) do |req|
    if req.path == '/users/sign_up' && req.post?
      req.ip
    end
  end

  throttle('supplier_sign_ups/ip', limit: 5, period: 20.seconds) do |req|
    if req.path == '/supplier/sign_up' && req.post?
      req.ip
    end
  end

  Rack::Attack.blocklist('fail2ban pentesters') do |req|
    # ::filter returns truthy value if request fails, or
    # if it's from a previously banned IP so the request is blocked
    Rack::Attack::Fail2Ban.filter("pentesters-#{req.ip}", maxretry: 1, findtime: 10.minutes, bantime: 1.day) do
      # The count for the IP is incremented if the return value is truthy
        CGI.unescape(req.query_string) =~ %r{/etc/passwd} || BANNED_PATHS.any? { |banned_path| req.path.include? banned_path }
    end
  end

  Rack::Attack.blocklist('bad-robots-php') do |req|
    req.ip if /\S+\.php/.match?(req.path)
  end

  Rack::Attack.blocklist('bad-robots-asp') do |req|
    req.ip if /\S+\.asp/.match?(req.path)
  end

  # Throttle POST requests to /login by email param
  #
  # Key: "rack::attack:#{Time.now.to_i/:period}:logins/email:#{normalized_email}"
  #
  # Note: This creates a problem where a malicious user could intentionally
  # throttle logins for another user and force their login requests to be
  # denied, but that's not very common and shouldn't happen to you. (Knock
  # on wood!)
  throttle('logins/email', limit: 5, period: 20.seconds) do |req|
    if req.path == '/users/sign_in' && req.post?
      # Normalize the email, using the same logic as your authentication process, to
      # protect against rate limit bypasses. Return the normalized email if present, nil otherwise.
      req.params['email'].to_s.downcase.gsub(/\s+/, "").presence
    end
  end

  ### Custom Throttle Response ###

  # By default, Rack::Attack returns an HTTP 429 for throttled responses,
  # which is just fine.
  #
  # If you want to return 503 so that the attacker might be fooled into
  # believing that they've successfully broken your app (or you just want to
  # customize the response), then uncomment these lines.
  self.throttled_response = lambda do |env|
    match_data = env['rack.attack.match_data']
    now = match_data[:epoch_time]

    headers = {
      'RateLimit-Limit' => match_data[:limit].to_s,
      'RateLimit-Remaining' => '0',
      'RateLimit-Reset' => (now + (match_data[:period] - now % match_data[:period])).to_s
    }

    [ 503, headers, ['You have been automatically blocked from the system for too many requests in a short space of time. This is to prevent bad bots from causing trouble. If you feel this is in error, please let us know on support@xxxyyy.co.za.']]
  end
end

[houstonheat]

@chrisedington Hello! Did you manage to find and implement a way to unlock it?

[chrisedington]

I don't believe I did unfortunately but I don't remember searching too hard or too long for a solution.

[matiasmasca]

With Redis is easier to handle the unblock:Rack::Attack.cache.store.delete(ip)

[jacobluanjohnston]

I’m using Redis and I’m facing the same issue as you.

I’ve built three or four different methods, including finding three different ways to clear the Redis cache and even a Rack::Attack dashboard, but they all end up functioning the same. There’s some persistent or residual data involving permanent bans — deleting them only takes their ban and their counter off the cache, allowing them to visit the website, but all requests made to that url are forever banned and cannot be unbanned. I’ve scoured every guide out there. Will update if I find anything.