Rails: Rack::Attackで対PHPボットを防ぐ(翻訳)

概要

原著者の許諾を得て翻訳・公開いたします。

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つ増えると、アプリやインフラの複雑さがその分増加します。

ボットによるエラーが発生しないうちからこの保護を予防的に追加する意味は必ずしもあるとは限りません。

理論上は正当なユーザーをブロックすればこの問題は解決しますが、こんなことをする人はまずいないでしょう。

はてブより

Rails: Rack::Attackで対PHPボットを防ぐ(翻訳)

なるほど、確かにwordpress狙っていろいろしてくるね

2018/07/15 11:57

関連記事

[Rails] rack-attack gemでRack middlewareレベルのアクセス制限を実施する

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ