Robots

image by Jehyun Sung

Ignore PHP bots with Rack::Attack

If your site has been around for a long time or starts getting popular, you might see a bunch of 404 errors in your logs.

RailsConf 2024

I'm co-chairing RailsConf 2024 in Detroit May 7–9. Come and join us 

Sometimes these errors are for pages like /wp_login.php or other PHP files. If you see these, it’s likely to be automated bots scanning the Internet for security vulnerabilities in WordPress-based sites.

These bots are indiscriminate in their targeting, hence looking for PHP files in our Rails applications!

Instead of…

…your logs becoming cluttered and these automated bots potentially slowing your application.

Use…

Rack::Attack to block their requests and ban the offending IP addresses.

Gemfile

gem 'rack-attack'

config/application.rb

module YourAppName
  class Application < Rails::Application
    config.middleware.use Rack::Attack
  end
end

config/initializers/rack_attack.rb

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

But why?

WordPress powers an enormous proportion of the world’s websites and has done for many years. However, its longevity and ubiquity make it a target for automated attacks. There are a lot of non-updated installations with known security weaknesses.

Rejecting these requests before they even hit your application, then banning the bot’s IP address, leaves you with better performance, less distracting noise in your logs and fewer exceptions raised.

With Rails, Rack::Attack uses Rails.cache by default to store its information about requests and block lists. By default this uses a memory store, but in production you’ll want to use something like Redis to a provide more resilient cache.

This is just one use case for the kind of access control that Rack::Attack provides. It is a terrific tool for protecting your application.

Why not?

Adding Rack::Attack and its cache as another dependency increases the complexity of your application and its infrastructure.

If you’re not seeing these sorts of errors, adding this protection as a pre-emptive measure may not be worth it.

The solution above could, in theory, block legitimate users, but this is highly unlikely.

Brighton Ruby 2024

Still running UK’s friendliest, Ruby event on Friday 28th June. Ice cream + Ruby 


Last updated on June 24th, 2018 by @andycroll

An email newsletter, with one Ruby/Rails technique delivered with a ‘why?’ and a ‘how?’ every two weeks. It’s deliberately brief, focussed & opinionated.