概要
原著者の許諾を得て翻訳・公開いたします。
- 英語記事: Ignore PHP bots with Rack::Attack - Andy Croll
- 原文公開日: 2018/06/24
- 著者: Andy Croll
Rails: Rack::Attackで対PHPボットを防ぐ（翻訳）
長く運営しているサイトや人気の出始めたサイトで、大量の404エラーがログ出力されることがあります。
そうしたページエラーが/wp_login.phpなどのPHPファイルから発生していることがあります。この種のエラーが出力されていたら、自動化ボットがWordPressベースのサイトのセキュリティ脆弱性がないかインターネットをスキャンしているかもしれません。
こうしたボットは標的を無差別に探しているので、RailsアプリにPHPファイルがあるかどうかまで探そうとします。
次の事態を避けること
ログが引っ掻き回され、自動化ボットによってアプリの速度が潜在的に落ちる。
次のようにすること
ボットからのリクエストをRack::Attackではじき、攻撃元のIPアドレスを遮断する。
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 Rail.env.production?
そうすべき理由
世界中にあるWordPressを長年に渡って使っているWebサイトの割合は膨大です。しかしWordPressによる長年の一極支配は、自動化攻撃の格好の標的となります。セキュリティの既知の弱点を含んだままアップデートされていないWordPressインストールが多数あります。
アプリがやられる前にそうしたリクエストをはじいてボットのIPアドレスを無効にすることで、パフォーマンスの低下を防ぎ、ログのノイズを削減して例外の発生を抑えます。
Railsの場合、Rack::Attackはリクエストやブロックリストの情報の保存にデフォルトでRails.cacheを用います。デフォルトではメモリストアが使われますが、production環境ではRedisなどで弾力性の高いキャッシュを使いたくなるでしょう。
この方法はRack::Attackが提供するアクセス制御のユースケースの1つに過ぎません。Rack::Attackはアプリを保護する頼もしいツールです。
そうすべきでない理由があるとすれば
Rack::Attackを追加してキャッシュへの依存性が1つ増えると、アプリやインフラの複雑さがその分増加します。
ボットによるエラーが発生しないうちからこの保護を予防的に追加する意味は必ずしもあるとは限りません。
理論上は正当なユーザーをブロックすればこの問題は解決しますが、こんなことをする人はまずいないでしょう。
