- ライフ
READ MORE
原著者の許諾を得て翻訳・公開いたします。
長く運営しているサイトや人気の出始めたサイトで、大量の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つ増えると、アプリやインフラの複雑さがその分増加します。
ボットによるエラーが発生しないうちからこの保護を予防的に追加する意味は必ずしもあるとは限りません。
理論上は正当なユーザーをブロックすればこの問題は解決しますが、こんなことをする人はまずいないでしょう。
Rails: Rack::Attackで対PHPボットを防ぐ(翻訳)
- [rails]
なるほど、確かにwordpress狙っていろいろしてくるね