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

#ruby #rails #middleware #security

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.

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.

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

Error page:

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 seconds 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.