大手企業のようにWebスクレイピングをしたいなら (2021)

 (incolumitas.com)
7 ポイント 投稿者 GN⁺ 2024-04-28 | 1件のコメント | WhatsAppで共有
  • AWS LambdaとHeadless ChromeだけでもGoogle SERPを週あたり数百万件収集できたが、強固に保護されたサイトの前ではクラウドベースのボット構成は簡単に限界にぶつかる
  • Lambdaの再呼び出しと複数リージョンの活用により、16リージョン基準で約16 * 250 = 4000の公開IPを同時に使え、これは緩い対象には十分だった
  • DataDome、Akamai、Impervaのようなアンチボット事業者は、ブラウザ設定の不一致、自動化の痕跡、フィンガープリント情報を追跡し、実際の難題は検知そのものより誤検知率を下げることに近い
  • より検知されにくい構成として、Dockerやクラウドサーバーの代わりに実際のAndroid端末とモバイルIPを使う方式を提案しており、4G/5G/LTE IPは大都市の多くの正規ユーザーが共有するため遮断しにくい
  • 実機ファームでは端末購入、都市ごとのスペース賃貸、現地保守、ハードウェア障害を引き受ける必要があり、Androidエミュレーターにもエミュレーション検知のリスクが残る

AWS Lambdaで作った大規模スクレイピング構成

  • 過去にスクレイピングサービスを運営していた当時、Google SERPを週あたり最大で数百万件収集していたが、Brightdata、Packetstream、Oxylabsのようなプロキシ提供業者は使わなかった
    • 同じプロキシ帯域を共有する他の顧客を信頼しにくいと考えていた
    • 公開情報に対する非DoS的なスクレイピングは問題ないが、広告詐欺、ソーシャルメディアスパム、自動SQL injection、XSSのようなWeb攻撃とは一線を画していた
    • プロキシサービスの費用も負担だった
  • 実際の構成は、AWS LambdaにHeadless Chromeを入れ、puppeteer-extraとchrome-aws-lambdaで300秒間ブラウザを実行する関数だった
  • Googleは自社検索エンジンに対してボット遮断をそれほど強くせず、主にIPベースのレート制限を適用しているため、Google SERPだけを見るならcurlでも可能だったかもしれないとしている
  • Lambdaでは関数呼び出し3回の後に新しい公開IPを得られ、1000個の関数を同時に呼び出すと約250個の公開IPに到達したという
    • 16リージョンを使えば同時に約4000個の公開IPを使えたと計算している
    • 共有データセンターIPではあったが、Google SERPを週あたり数百万件収集するには十分だった
  • Google Cloud Platformも試したが、GoogleはAWSトラフィックより自社クラウドインフラのトラフィックをより強く遮断した
  • この経験は2019年および2020年時点のもので、その後状況は変わっている可能性がある

クラウドボットが止められる理由

検知されやすい経済的な構成

  • 大量スクレイピングをしようとするボット開発者は、ブラウザをDockerコンテナに入れ、Docker SwarmやKubernetesでオーケストレーションすることが多い
  • こうしたボットはHetzner、AWS、DigitalOceanのようなクラウド事業者上でホスティングされることが多い
  • この構成は人間ユーザーの環境と大きく異なる
    • 正規ユーザーがHetzner VPSのDockerコンテナの中でInstagramを閲覧している状況は自然ではない
  • 成功するスクレイピングのルールとして2つを挙げている
    • 2番目に重要なルール: ブラウザ設定について嘘をつかないこと
    • 最も重要なルール: バレないときだけブラウザ設定について嘘をつくこと

実際のAndroid端末ファーム

  • 難読化されたアンチボットのフィンガープリント採取ライブラリをリバースエンジニアリングするのは難しいため、実機をスクレイピングに使うアプローチを提案している
  • 想定する構成は、低価格Android端末500台を購入し、フィンガープリントの多様性のために5社程度のメーカーの端末を混在させる方式である
    • 低価格Android端末は1台58ドルから始まる
    • 100台単位で買えば大幅な割引を受けられると見ている
  • 各端末に安価なデータプランを付け、DeviceFarmer/stfで制御する
  • London、Paris、Boston、Frankfurt、Los Angelesのような5つの主要都市にそれぞれ100台ずつ配置し、モバイルセルラーアンテナに近い安価な保管スペースを借りる構想である
  • 端末には軽量なAndroid Goを入れ、不要な要素を取り除いたうえで電源に接続する
  • 5分ごとに機内モードをオン・オフすれば、4G Carrier Grade NATを通じて新しいIPを取得できる
  • モバイルIPアドレスは大都市では最大で数十万人の正規ユーザーが共有するため、実質的に遮断しにくい
    • 例として、Instagramが一部のスパム利用者を理由にLAの20万人を遮断することはないだろうとしている
    • CGNでIPv4アドレスが遮断されると加入者基盤全体に影響しうるというOfcom文書を引用している
  • IPv6はアドレス空間が広すぎるため、ほとんどのアンチボット事業者はIPv6アドレスにIPレピュテーションをほとんど、またはまったく付与していないと見ている

実機構成の検知ポイントと運用負荷

  • 実機を床に一日中置いたままにすると回転や動きのない状態が続くため、deviceorientationとdevicemotionのJavaScriptイベントをカーネルレベルでスプーフィングする必要がある
    • WebサイトはAndroidの回転および加速度データに権限要求なしでアクセスできる
  • この問題を除けば、その構成をボット検知システムがどう遮断できるのか明確ではないとしている
  • 運用負荷は小さくない
    • Android端末500台を購入しなければならない
    • 主要都市で保管スペースを借りる必要があり費用がかかる
    • 5都市で端末ファームの問題を修理する人が必要になる
    • ハードウェアを扱う必要があり、継続的に問題が発生しうる
  • このような構成は大きなプロジェクトになり、保守に数千ドルかかる可能性があるとしている

Androidエミュレーターという代替案

  • 実機のAndroid端末の代わりにAndroidエミュレーターを使うほうが良いと見ている
  • コストは下げられるが、アンチボット事業者がエミュレーション環境を見つけ出せる可能性がある
  • 想定される検知方式はいくつもある
    • ブラウザベースのred pillによって、ブラウザがエミュレーション環境で動作していることを露呈させられる可能性がある
    • ブラウザベースのポートスキャンで、エミュレートされたAndroid端末でのみ動作するポートやadbのようなサービスを見つけられる可能性がある
    • Googleがモバイル端末全体に広告IDを設定でき、このIDが存在しない、または常に同じであれば疑わしいシグナルになりうる
    • Social Media Login DetectionでGmailやYouTubeアカウントへのログイン有無を確認でき、AndroidでGoogleアカウントにログインしていなければ疑われる対象になりうる
    • そのほかにも、エミュレートされたAndroid端末の検知技術は多く存在しうる
  • Androidエミュレーターは不完全である可能性が高く、その不完全さはモバイルブラウザの膨大なJavaScript APIを通じて露呈しうる
  • それでもエミュレーションのアプローチを好んでおり、強力なサーバー数台に4Gドングルを接続する構成を提案している
  • proxidize.comは4Gモバイルプロキシを提供しているが、プロキシ自体が検知可能であるため、Androidエミュレーターで4Gドングルを直接使いたいとしている
  • 最終的な構成は地域別スクレイピングステーションの形になる
    • 1つの地理的位置に、4Gドングル50本が接続された強力なスクレイピングサーバー1台を設置する
    • 各サーバーで50〜100台のエミュレートされたAndroid端末を実行する
    • こうしたステーションを5つの主要都市に配置する
    • シンプルなコマンド・アンド・コントロールサーバーが5つのスクレイピングステーションをオーケストレーションする

関連記事

1件のコメント

 
GN⁺ 2024-04-28
Hacker Newsの意見
  • Webスクレイピング分野で働く弁護士として、こういうスレッドを見るといつも笑ってしまう。今われわれがテック分野の独占企業と見なしているほぼすべての企業やその関連会社は、事業を成長させる過程でスクレイピングを活用してきたのに、今では同じ企業がスタートアップや競合他社によるデータスクレイピングを禁止している。
    そのデータも、法的に認識可能な意味で実際に「彼らの」データではない場合がほとんどだ。だからWebスクレイピングの倫理も、関連する法的論点も、それほど単純ではない。昨秋これについて書いた記事もここで関心を集めた: https://news.ycombinator.com/item?id=37264676
    • Facebookと身元情報も似ている。記憶が正しければ、Facebookは初期にGoogleコンタクトを活用して成長したが、誰かがFacebookのソーシャルグラフデータを長期保存して自社の囲いの外で使おうとすると、攻撃的に阻止する。
      結局、自分たちが成長に使った手口を他人には使わせないということだ。
    • Webスクレイピングの倫理は、むしろとても簡単に見える。「あなたは私のHTTPリクエストに好きなように応答でき、私はその応答を好きなように解釈できる」という程度で十分だ。
      人間のコミュニケーションが始まって以来、会話は常にこういう方式だったのではないかと思う。一方で法的論点は、既存事業者を国家暴力の脅威で保護するために絞り出された布のように見え、特に新しくもなく、情けないが予測可能な類のものだ。さらに広く言えば、これを知的財産権の問題として包み、芸術家やクリエイターの保護に結びつけようとする試みも、論理的に非常にぎこちなく、眉をひそめてしまう。
  • 以前はプロのWebスクレイパーで、今も業界の動向は追い続けている。最近はWebスクレイピング自体で稼ぐのではなく、Webスクレイパーにサービスを売って稼ぐ。
    WebスクレイピングSaaSや関連サービスは多く、住宅用プロキシの提供業者も数十社ある。ほとんどのボット対策メカニズムがあまりにも速く進化しているため、従来のソフトウェアエンジニアリング職の中でも、ボット対策の回避技術だけを専門にしてかなり良い収入を得ることができる。この変化の速さのため、Webスクレイピングを職業にするより、Webスクレイピング会社で働くほうが安定している。スクレイパーはプロジェクト単位で報酬を受け取るため長期的には不安定で、高度なスクレイピングには住宅用プロキシやサーバーレンタルのような運用投資が必要で、低価格の案件は報酬が非常に低い。BrightdataがWebスクレイピングのカンファレンスを開催していることを見るだけでも、大規模スクレイピングサービスの販売がどれほど収益性が高いか分かる。
    • スクレイピングや大規模ボットネットワークの運用には住宅用プロキシが必須だと長らく考えてきたが、自分で使ったことはないので、実際の規模でどう使われているのかは確認できていない。
      こうした用途に、セキュリティの弱いIoT機器やマルウェアに感染した消費者向けハードウェアがよく使われているのか気になる。ISPと協力して住宅用IPを確保する方法は、収益性があるとも実現可能とも思えないので、住宅用プロキシサービスならかなり隠密な方法しかなさそうに見える。
    • 一般的に、スクレイピングに最も近いカンファレンスがあれば勧めてほしい。知る限り、スクレイピング専用のカンファレンスや強いコミュニティはほとんどないので、学んで腕を上げたい。
    • Upworkで何年もスクレイパーを書いてきたが、プロジェクトベースの仕事に疲れてしまい、スクレイピングSaaSで働くか、自分で始めたい。アドバイスが欲しい。
    • 最初はこれがこんなに簡単だとは知らず、コードをオープンソースで公開した。GitHubはAkamaiのようなところがすぐDMCAを送ってきそうだったので避け、管轄の違いを利用して中国版GitHubに似たGiteeに載せた。
      この分野の背景はなかったが、企業が自慢している内容を照らし合わせれば難しくなかったし、スポーツベッティングを自動化するという実用的な目的もあった。実際の本業もそちらに近く、20代後半でプログラミングを素早く学ぶ助けになった。ところが、ほぼ即座に中国のスニーカーボット運営者たちや、英語が母語ではないような独特の英語を書く人たちから依頼が殺到した。法的な脅しのせいではなく、カスタマーサポートの仕事や他人の下で働くことをしたくなかったのでコードを下げたし、依頼の大半が「君が働けば収益は分けよう」という類いで、誰がそんな提案を受けるのか信じがたかった。インターネットは永遠なので、Cyberfed-Akamai 0.8〜2.3をまねていたコードの一部はまだ出回っている可能性がある。20代半ばでプログラミングを学び、3年以内に上げたコードが通用したのなら、そういう製品に高額を請求するサイバーセキュリティ企業は恥じるべきだと思う。高校2年以降は数学もやっておらず、ADHDのため動画も文章も長く見ていられないので、GitHubに似たサービスから写しながら動くまで学んだのがすべてだった。この業界ではおそらく蛇の油のようなソリューションが大量に売られているのだと思う。
    • 業界の動向をどうやって追い続けているのか気になる。
  • この問題については複雑な気持ちだ。ボット対策技術はセキュリティ研究においてますます大きな悩みの種になっており、この分野で働いているとそうしたシステムに対処しなければならない。
    脅威アクターがCloudflareのようなサービスを使って悪意あるペイロードへのアクセスを防いでいる。ブランドなりすましや認証情報フィッシングを見つけて検出しようとする顧客にとっては大きな問題だが、Cloudflareはまったく助けにならず、ただ気にしていない。
    • 同意する。脅威アクターが無料のCloudflareアカウントを作り、作成から2時間しか経っていないドメイン上のフィッシングサイトを、200億ドル企業が支える保護の盾の後ろに隠せるようになったことで、検出を逃れるのがあまりにも簡単になった。
      Akamaiの背後ではフィッシングをほとんど見ないのが面白い。私たちもこの分野で働いているので、今後もこうした脅威を検出できなければならないという利害関係がある。
    • 結局、この問題を解くために何らかの形のマイクロペイメント機構に行き着くのではないかと思う。
  • 「不適応者」と「普通の人」という表現は変だ。こういう仕事をする理由は、退屈な企業向けReactサイトを20回目に作るより、はるかに興味深くて楽しいからだ。
    現実世界の問題を解き、何かをする新しい方法を見つけなければならないので面白い。エクスプロイト開発も同じだ。こういう人たちは不適応者ではなく、自分が情熱を持てることをしている普通の人たちだ。「自分が嫌いな仕事をする人は不適応者だ」という考え方こそ、完全におかしい。
    • その段落全体は冗談だ。最後に小さなウィンクが付いているのはそのためだ。
  • ボット対策技術はセキュリティ上の脅威であり、プライバシー上の脅威のようにも見える。仮想マシンを使うとサイトへのアクセスをブロックしたり、ポートスキャンをしたり、さまざまな形のフィンガープリンティングをしたりするからだ。
    • 新規訪問者にCPU演算をさせるアルゴリズム課題方式のほうが良い。
      手順が明確で、プライバシーリスクや奇妙な小細工もなく、失敗しても人が少なくとも見て報告できる形で失敗する。原因不明の障害のように見えるよりはましだ。
  • 当時も議論されていた: Scrape like the big boys - https://news.ycombinator.com/item?id=29117022 - 2021年11月、コメント189件
  • 「すべてのWebサイトが権限リクエストなしにAndroidの回転および速度データにアクセスできる」だって？ これは本当にあり得ない。
  • 興味深い。今、低頻度のスクレイピングが必要なプロジェクトを作っている。
    拒否された場合をどう処理するか考えていたが、安価なAndroid端末1台が隙間を埋めてくれるかもしれない。