あなたの知らない鬱陶しいWebクローラーに立ち向かう方法

  • 82
    いいね
  • 0
    コメント

おことわり

技術側の話は少ないです。
本記事の内容を真に受けた結果発生した損害などの責任は負いませんのでご了承ください。

まえがき. 本記事のターゲット読者について

  1. 継続的治安の悪いWebクローラーから大量にアクセスされていて悩んでいる人
  2. タイトルに釣られて興味本位で見に来た人
  3. 鬱陶しいWebクローラーの開発者

継続的に

不定期ではなく一定のパターンで定期的にアクセスがあることを指します。
毎日、毎時、毎分、毎秒など。

治安の悪い

いわゆるWebクローラー運用の「お作法」から道を外れていることを指します。
robots.txt無視、UA偽装、非常に短い時間でのバーストアクセスなど。

大量に

Webクローラーからアクセスされていることを察知出来るほどのある程度まとまったアクセス量があることを指します。
未知のWebクローラーからWeb上の資源を守るのは非常に困難です。

第1部. 振る舞いから相手を分析する

Webクローラーが稼働されている時、そこには必ず運用者と目的が存在します。
運用者は個人か、法人か。利益目的か、趣味・研究のためか、サービス提供のためか。

それを探るためにもまずは相手がWebサーバに対して残す痕跡を調べましょう。
痕跡の中でも特に注目すべき性質は、

  • 時間帯
  • 頻度
  • クエリパラメータ
  • アクセス元ホスト
  • セッションの維持の有無、リセットのタイミング
  • ヘッドレスブラウザか否か

などが挙げられます。
ここに列挙したものが全てではありませんが、ひとまずの切り口としては十分でしょう。

以下、架空のECサイトを題材に分析と対策ののデモンストレーションを行いながら進めていきます。

あなたは某大手価格比較サイトに接続をする中規模のECサイトを運営しています。
近頃、ECサイトへのアクセスが増えている事が分かっていますが、キャンペーンやセールを打ち出したわけでもなく、流入元が不明でした。

まず、httpdサーバのアクセスログを調べてみると、朝6時から8時の間に集中して膨大なアクセスがあることが分かりました。
クエリパラメータを抽出し分析してみると、特定のカテゴリ配下の商品ページを全てアクセスされていることも分かりました。
商品ページやカテゴリ一覧ページへのアクセスはありますが、画像やcssなどの静的ファイルには一切アクセスがなく、セッションを持たず単発のアクセスを繰り返していることが分かりました。
アクセス元ホストを集計すると1日あたり50個のAWS東京リージョン内ユニークホストから接続されていることも分かりました。

実はこのECサイトでは朝5時から5時半までの間に価格情報と在庫情報をバッチ処理で更新しており、クローラーの運用者はこの挙動を知った上でその日にあなたのECサイト上に掲載される特定カテゴリ商品の最新の情報を入手したいという仮説を立てることにしました。

更に深く分析を行うと、
静的ファイルへのアクセスがないこと、セッションを破棄(Cookieを無視)していることから、wgetやcurlのようなごく単純なツールでアクセスされていることが予想されます。
朝6時から8時の間のみアクセスがあるため、AWS EC2のオンデマンド/スポットインスタンスを利用していると予想されます。
AWS EC2の通常のリージョン毎インスタンス数制限は20台であり制限解除にはやや面倒な手続きを要するため、クローラ運営の主体は個人ではなく法人が行っているということが予想されます。

第2部. Webクローラー対策の勝利とはなにか

これらのWebクローラーに対して対策を行うか行わないかということをECサイト運営チームで検討する事となりました。
ごく短時間の間にアクセスが集中することでレスポンス速度が低下したり、データベースサーバに負荷がかかり異常通知がなされるなど運用サイドから対策をしてほしいとの要望があり、「対策を行う」という決定がなされました。

チームとして実施した対策は非常にシンプルなもので、AWSのIPアドレス帯をhtaccessに登録するというものでした。
設定をした翌朝、クローラーからのアクセスはありましたが全てhttpdサーバ側で拒否され一同は胸を撫で下ろしました。
しかし、htaccess設定から3日後にまた大量のアクセスが襲来、ホストを調べるとAWSではなく別のパブリッククラウドから飛んできているようでした。

上記のように、Webクローラーを防ぐ方法は山程ありますが、防ぐ方法を突破する方法も山程あります。
その後も運営チームは、Webビーコンを仕込む、JavaScriptでヘッドレスブラウザ対策をする、などの数々の対策を行いますが、対策を行った数日後には突破されてしまうというイタチごっこ状態に陥ることとなりました。

一旦立ち返り、Webクローラー防衛側の勝利について考えてみましょう。
Webクローラー防衛側の勝利とは、裏を返すとWebクローラー攻撃側の敗北を意味します。
Webクローラー攻撃側の敗北とは、Webクローラーを稼働させることにより損をしてしまう状態にあるということです。

今までのやり取りから、攻撃側はどうやら対策により数日間情報が取得できない状態に陥ったとしても問題がなく、かつ様々な対策に対して追加開発を行う人件費であったり、インフラ費用を支出するコストを支払うだけの利益をクローラーで取得する情報に見出していることが判明しています。
攻撃側は支払ったコスト以上のもの得ていると考えると話は単純で、支払ったコスト以上のものが得られなければWebクローラーを運用することをやめるという、非常にシンプルなビジネスの話になります。

つまりWebクローラー防衛側が最も検討しなければならないクローラー対策とは技術的対策ではなく、攻撃側のビジネスを分析・予想し、利益を破壊するための方法を考えることなのです。

第3部. 相手の利益を破壊する方法

IPアドレス制限やクローラー対策でももちろん、攻撃側に対しては突破のための何らかの稼働を強いることとなるのでコスト増となりますが、例えばWebクローラーを検知して403を返したりコネクションを切断したりという対策は、相手に対策されていることをわざわざ通知するという観点で下策であると言えます。

ここでは攻撃側の気持ちになって、一番されたら嫌なことを考えましょう。

例えば、一見正常に情報取得できたように見えて実は誤った情報だったら?
その結果、毎日取得したデータを人間の目でサンプル抽出チェックしなければならなかったら?
誤った情報を意図的に表示されたことで、過去取得したデータの整合性が疑わしくなったら?

嫌ですね。僕は嫌です。

この防衛機構の実装にはやや高めのコストを支払うこととなりますが、アリの巣コロリのように攻撃側にとってはボディーブローのように効きます。注意点としては、正常なアクセス(一般ユーザやGooglebotなど)に対してこの機構を作動しないように十分に気をつける必要があります。

結論として攻撃側は相手にクローラーであると認知されないようにするのと同じように、防衛側も相手にクローラー対策をしていることを認知されないように対策をするということが重要です。

あとがき

ここまで書いておいてなんですが、基本的に攻撃側と防衛側が利益無視で双方ともに無限のコストを投入した場合は絶対に攻撃側が勝ちます。
防衛側は負け戦前提で最も効果的に攻撃側のコスト増・プロフィット減を狙うか、そもそも防衛せずにサーバリソースを増強するなどのノーガード戦法を取ることをおすすめします。防衛側はいくらWebクローラー対策を行った所でそこからの利益を生み出せるわけではないということもしっかりと認識しましょう。

ご質問やご意見ありましたらコメント欄にお願いします。