Rack-attack gem setup to protect Rails and Rack apps from bad clients

Rack middleware for blocking & throttling abusive requests. Protect your Rails and Rack apps from bad clients. Rack::Attack lets you quickly decide when to allow, block, and throttle based on the properties of the request.

Kanani Nirav
3 min readAug 6, 2022

Using this gem you can save your web application from attacks, we can whitelist IPs, Block requests according to requirements, and many more…

Install Rack-attack gem:

# In your Gemfile
gem 'rack-attack'

Plugging into the application

Then tell your ruby web application to use rack-attack as a middleware.

# config/application.rb
# rack attack middleware
config.middleware.use Rack::Attack

Once you’ve done that, you’ll need to configure it. You can do this by creating the file, config/initializers/rack-attack.rband adding the rules to fit your needs.

You can disable it permanently (like for a specific environment) or temporarily (can be helpful for specific test cases) by writing:

Usage

Safe listing

Safelists have the most precedence, so any request matching a safelist would be allowed despite matching any number of blocklists or throttles.

  • safelist_ip(ip_address_string)
Rack::Attack.safelist_ip(“5.6.7.8”)
  • safelist_ip(ip_subnet_string)
Rack::Attack.safelist_ip(“5.6.7.0/24”)
  • safelist(name, &block)

Name your custom safelist and make your ruby-block argument return a truthy value if you want the request to be allowed, and false otherwise.

Blocking

  • blocklist_ip(ip_address_string)
Rack::Attack.blocklist_ip(“1.2.3.4”)
  • blocklist_ip(ip_subnet_string)
Rack::Attack.blocklist_ip(“1.2.0.0/16”)
  • blocklist(name, &block)

Name your custom blocklist and make your ruby-block argument return a truthy value if you want the request to be blocked, and false otherwise.

Throttling

throttle(name, options, &block) ( provide limit and period as options)

Throttle state is stored in a configurable cache (which defaults to Rails.cache if present).

Name your custom throttle, provide limit and period as options, and make your ruby-block argument return the discriminator. This discriminator is how you tell rack-attack whether you’re limiting per IP address, per user email, or any other.

  1. For example, if we want to restrict requests other than defined routes and display a custom error page.

Error page:

Error Page

2. If we want to restrict requests/IP and if the request limit increases then send a reminder mail.

For Example, we want to allow only 300 requests per 30 seconds after that will restrict requests from this IP till the next 30-second interval starting.

Get error mail if the limit is extended.

Performance

The overhead of running Rack::Attack is typically negligible (a few milliseconds per request), but it depends on how many checks you’ve configured, and how long they take. Throttles usually require a network roundtrip to your cache server(s), so try to keep the number of throttle checks per request low.

If a request is blocklisted or throttled, the response is a very simple Rack response. A single typical ruby web server thread can block several hundred requests per second.

Sample rack-attack.rb file

For more information: https://github.com/rack/rack-attack

Thank you for reading, and I hope you enjoyed it. also don’t forget to clap (up to 50 times) if you like it.

Stay updated with my latest and most interesting articles by following me.

If this guide has been helpful to you and your team please share it with others!

--

--