IdentityLoggerでCSGOのチーターを制圧

 (mobeigi.com)
1 ポイント 投稿者 GN⁺ 2024-10-18 | 1件のコメント | WhatsAppで共有
  • Invex Gamingは2014〜2019年にオーストラリア・ニュージーランドを拠点とするCSGOコミュニティサーバーを運営しており、繰り返されるBAN回避のため、管理者による手動のデモレビュー負担が大きくなっていた
  • 従来のBANはIPアドレスとSteam IDを紐付けて追跡していたが、チーターが両方を同時に変えると、サーバー側では同じプレイヤーかどうかを確認しにくかった
  • IdentityLoggerはCSGO内蔵のVGUIブラウザの永続Cookieを利用してTracking IDを保存し、IPアドレス・Steam ID・Tracking IDをまとめてフィンガープリントとして使用する
  • 2017年2月に全サーバーへ導入された後、Steam IDとIPアドレスの両方を変えたプレイヤーもTracking IDによって再識別され、即座にBANされた
  • この方式は、Valveが2017年10月にセキュリティ強化のためVGUIブラウザを削除するまで機能し、その後、技術とプラグインが公開された

Invex Gamingの運営とチート対策の負担

  • Invex Gamingは2014年から2019年まで運営されていた、オーストラリア・ニュージーランド拠点のCSGOコミュニティサーバーだった
  • 運営業務は、フォーラムとサーバーインフラの維持、費用とスポンサー管理、プレイヤーモデルの追加、ヒットボックス修正、VIPシステムの自動化、カスタムプラグイン作成、ゲームのエクスプロイト・バグ修正、DDoS対策、通報対応まで幅広かった
  • その中でも、繰り返されるチーターの識別とBANが最も退屈で消耗の大きい作業だった
  • 自動検知にはサーバー側コードやValve Anti-Cheatのような方法があったが、チート開発者とアンチチート開発者のいたちごっこのため、すべてのチートを自動で捕捉するのは難しかった
  • 結局、最後の手段はCSGOのデモを見る手動分析であり、管理者がプレイヤーのチート行為の有無を直接判断する必要があった

IPアドレス・Steam IDによるBANが破綻するポイント

  • 一般的なBANは、サービスへのアクセスを防ぐために識別可能な情報を保存する方式である
  • Invex Gamingのサーバーは主に2つの識別子を使用していた
    • IPアドレス: ISPやサーバープロバイダーが付与するインターネット識別子
    • Steam ID: Steamアカウントに紐付く一意の識別子
  • プレイヤーがBANされると、IPアドレスとSteam IDがBANリストに保存され、その後、同じIPアドレスまたはSteam IDで接続するとサーバーから退出させられた
  • Steam IDだけを変えて同じIPアドレスで戻ってきた場合、新しいSteam IDを既存のBANに関連付けて再びBANできた
  • IPアドレスだけを変えて同じSteam IDを使う場合も、新しいIPアドレスが既存のBANに紐付けられた
  • 問題は、チーターがSteam IDとIPアドレスを同時に交換したときに発生した
    • サーバーから見ると、初めて見るIPアドレスとSteam IDの組み合わせになる
    • 既存のBANと関連付ける方法がなく、再びプレイできてしまう
    • 再度BANされても、2つの識別子を一緒に変えながらBANを回避できる
  • 人気VPNと関連IPアドレスのリストを維持する案も検討されたが、継続的な管理負担のため運営チームは好まなかった
  • その後の分析で、最も悪名高いチーターは地理的に分散したIPアドレスと、CSGOを購入済みの87個を超えるSteamアカウントにアクセスできていた

IPアドレスのフィンガープリントが生む誤検知の可能性

  • Steam IDはプレイヤーを一意に識別するが、IPアドレスは一意の識別子ではない
  • 同じ家から2人の兄弟がサーバーに接続し、1人だけがチートをしていた場合、同じIPアドレスのために2人のフィンガープリントが絡まり、両方がBANされる可能性があった
  • 大学のように、すべての外部トラフィックが単一のIPアドレスから出ていく共有ネットワークでも問題が生じる
    • 1人がキャンパスネットワークでチートによりBANされる
    • 同じネットワークを使う別のプレイヤーのSteam IDと自宅IPアドレスまで関連付けられ、不当にBANされる可能性がある
  • Invex Gamingはこうしたまれなケースのために例外システムを作り、信頼できないネットワークではプレイしないよう案内した

VGUIブラウザCookieを3つ目の識別子として使用

  • 2017年初め、サーバーのBAN回避問題が大きく悪化し、管理者たちはデモを手動でレビューし続ける必要があった
  • 中核となる課題は、Steam IDとIPアドレスが同時に変わる状況でも同じプレイヤーを見分けることだった
  • CSGOには、サーバー運営者が接続時にMOTDを表示できるゲーム内標準Webブラウザがあり、これはVGUIブラウザと呼ばれていた
  • VGUIブラウザは、サーバー運営者がプレイヤーの画面に任意のWebサイトを開けるようにし、ウィンドウを非表示にすることもできた
  • このブラウザはSteam Cookieで事前認証されており、Steamドメインに自動ログインでき、サーバー運営者が送ったJavaScriptのクライアント側実行も許可していた
  • IdentityLoggerの要点は、VGUIブラウザがCookieをサポートし、セッション間でも保持する点だった
    • テストの結果、VGUIブラウザで保存したCookieはCSGOを終了して再起動しても残っていた
    • Cookieの有効期限に制限もなさそうで、10年を超える有効期限のCookieも保存できた
    • CookieデータはプレイヤーのSteamインストールディレクトリ内のファイルに保存される
  • この方式により、各プレイヤーにTracking IDという3つ目の識別子を付与できた
  • 新規プレイヤーのように見せるには、Steam ID、IPアドレス、Steamインストールフォルダのすべてを変える必要があり、Steamインストールフォルダまで変えるプレイヤーはいないと見込まれた

IdentityLoggerの実装フロー

  • IdentityLoggerは、IPアドレス、Steam ID、Tracking IDを基にプレイヤーをフィンガープリント化する統合システムである
  • プレイヤーがサーバーに接続すると、まずデータベースでBANチェックを実行する
    • IPアドレス、Steam ID、Tracking IDがチェック対象である
    • 既存のBANがあればプレイヤーをサーバーから退出させ、新しい識別子を既存のBANに関連付ける
  • BANされていないプレイヤーには、非表示のVGUIブラウザウィンドウで秘密のWebページを開かせる
  • リクエストには秘密値を入れて認証し、VGUIブラウザのリクエストはクライアント側で作られるが、トラフィックはHTTPSで暗号化される
  • PHPスクリプトはTracking ID Cookieがすでに存在するか確認する
    • なければ新しいTracking IDを生成して保存する
    • Tracking IDはTeStsCOhZO1TQsumJkDUOdMMo13ReRLEngrQTg7S49LKT2rBvgPhauzSYbegscOTのような64文字のランダムな英数字文字列である
    • Cookieは最終的に、プレイヤーのSteamインストールディレクトリにあるvgui.browser.cookies.datファイルに保存される
  • Steam ID・IPアドレス・Tracking IDは、プレイヤーがサーバーに接続するたびにデータベースへ保存される
  • このデータベースは、管理者がプレイヤーのフィンガープリントを調査するWebパネルと、Sourceベースのゲーム向けBAN管理ソフトウェアを基にした改修版SourceBansプラグインに統合された

BAN回避を防ぐ仕組み

  • 例えば、プレイヤーがIPアドレス198.51.100.1、Steam IDSTEAM_1:1:1111で初めて接続すると、Tracking IDが新規生成される
  • このプレイヤーがチート行為でBANされると、IPアドレス、Steam ID、Tracking IDがすべてBANデータベースに入る
  • 後に同じプレイヤーがIPアドレス100.64.50.74、Steam IDSTEAM_1:1:3333で接続すると、新しいIPアドレスと新しいSteam IDはBANチェックを通過する
  • しかし、以前に保存されたTracking IDが過去のBANと関連付いているため、BANチェックを通過できない
  • システムは即座にプレイヤーを再BANし、新しいIPアドレスと新しいSteam IDを既存のBANに関連付ける
  • 以降、このプレイヤーはどのIPアドレスやSteam IDを使っても、同じTracking IDのため接続直後にBANされる

2017年の導入結果と公開

  • Invex Gamingはテスト後、2017年2月にIdentityLoggerをすべてのCSGOサーバーへ導入した
  • 導入直後、チーターのBAN数が大きく増えた
  • 長年知っていた信頼されていたコミュニティメンバーの一部も、秘密アカウントでチートをしていたことが明らかになった
  • 一部のチーターは、Steam IDとIPアドレスを変えたにもかかわらずBAN回避として検出された理由を直接尋ねてきた
  • 他のサーバー運営者もプラグインに関心を示し、金銭を提示したケースもあった
  • 技術が広く知られればCookieファイルを削除するだけで回避できるため、実装は管理者チーム内で秘密に保たれた
  • この方式は、2017年10月にValveがゲームセキュリティを強化する過程でVGUIブラウザを完全に削除するまで機能した
  • VGUIブラウザ削除後に技術が公開され、プラグインもオープンソースとして公開された

関連記事

1件のコメント

 
GN⁺ 2024-10-18
Hacker News のコメント

  • UT2004 ではプレイヤーの GUID（CD キーのハッシュ）や IP でブロックできますが、Epic がゲームを放置してからキー生成ツールが大量に出回り、GUID ブロックは無力化されました。最近は VPN も 2 ドルで使えるので、IP ブロックにも大きな限界があります。
    今使っている主な解決策は、IP ブロックに加えて、既知の VPN サブネットのデータベースをすべてファイアウォールに入れて VPN ブロックすること、そして特定のシステムフォルダ構造を調べる似たようなフィンガープリンティング手法です。

    • 「VPN のせいで IP ブロックに限界がある」というなら、https://redman.xyz/doku.php/schachtmeister2 はまさにそういう人たちを防ぐために作られたものです。
      Tremulous（ioquake3 のフォーク）で人々が IP ブロックを何度も回避したため作られたものですが、他のゲームにも使えます。私のプロジェクトではありませんが、作者は知っていて、需要があれば特定のゲーム向け、あるいは汎用向けにフォークして手を入れることもできます。
      schachtmeister2 では whois -10 "Hosting"、whois -13 "VPN"、whois +7 "residential" のような ヒューリスティックも使えます。
      追記: Git リポジトリが 502 を返しているのを見て、管理者に連絡しました。
    • UT2004 のメンテナンスを手伝えるならうれしいです。あのゲームが本当に好きです。
      オンラインはもう腕が追いつかないのでやっていませんが、30 分くらい空いたときに AI 相手にさっと 1 戦入っても、今でも楽しいです。
    • 私が運営を手伝っている Counter-Strike 1.6 サーバーにも時々チーターが来ますが、意外にもノースコープのスナイパーヘッドショットを空中で決めるような、隠す気のない「ragehack」が多いです。
      サーバー所有者が non-Steam アカウント（海賊版）での接続を許可しているため、Unreal の GUID のように SteamID ブロックに頼ることができません。偽装 ID を変えるのはインストールフォルダのかなり深い場所のどこかなので少し面倒ですが、不可能ではありません。北アフリカ、旧バルト圏とその周辺地域、北・西アジアではかなり人気のあるゲームなので、こうしたプレイヤーがいないとサーバーは空になります。
      そこでアメとムチを併用しています。Steam プレイヤーにはほぼ即時リロード、一部の過激な自動運営・キック機能の免除、予約済みニックネームと「VIP」タグが与えられます。VPN キー数個分の値段で正当な利点とゲームの所有権を得るわけで、1 回きりの費用は開発元に直接入ります。あるいは 5 週間、毎週 1 ゲーム以上プレイして、SNS で運営に連絡すれば無料でも可能です。
      ムチの側では、単にキック・ブロックするのではなく、本当に歓迎されていないことを示すために、わざと面倒にして二度と来たくなくなるようにします。武装解除して最下級武器を渡す、マップ外や床にめり込むようにランダムテレポートする、amx_rocket を繰り返して花火にする、amx_drug で視野角を最大にして酔ったような効果をかける、AI に代わりにプレイしてもらわないと楽しめない低スキルの loser だとからかう、といった具合です。
      「違法」扱いされる amx プラグインやコマンドもあります。通常は悪用の可能性が大きいので敬遠されますが、こうした状況では役に立ちます。特に amx_exec は、管理者がクライアントのゲーム内コンソールに直接アクセスして任意のコマンドや設定を実行できるので、かなり恐ろしいものです。
      例えば rate 1000、name iCaNtAiM、unbind all、bind y quit、fps_max 50 のようなコマンドで、ネットワーク速度をめちゃくちゃにし、名前を変え、キーバインドを消し、デフォルトのチャットキーをゲーム終了に割り当て、最大 FPS を目立ちはしないもののイライラする程度に低くできます。デフォルト値への復旧は設定ファイルを削除すれば簡単ですが、設定のバックアップがないと非常にうんざりすることがあります。
      興味深いことに、多くのサーバーが VIP 特典を月 20 ドルまでで販売しています。最初は衝撃でしたが、サードパーティのサーバーブラウザでほどよい位置に露出するにはかなりの費用を払わなければならない、影のカルテルのような構造があり、収入の相当部分が「boost」に使われていることが分かりました。
      うちのサーバー所有者が 2 か月間「boost」の支払いを止めたところ、平均プレイヤー数は 14/32 から 3/32 に落ち、週末ごとに通常 28/32 まで埋まっていた最大接続者数も、金曜の夜に運がよくて 12/32 程度になりました。支払いを再開した途端にプレイヤー数は跳ね上がりましたが、その費用が月 180 ドルというのが狂っているところです。
      運営に参加する前は、面白いデスマッチ、良い管理、低遅延、高性能サーバー、ゲームで 2 番目に人気のマップのリメイク・リミックス専用であれば十分人気が出ると思っていました。しかし大多数のプレイヤーの目に触れるには、既存の門番たちに過剰な費用を払わなければならないようです。
    • なぜチーターのブロックがここまで問題になるのか理解できません。ブロックせず、裏で チーターとしてマークして、チーター専用サーバーにだけ入れるようにすれば、すぐにやめるはずです。
      Web スクレイパーに IP がブロックされたと知らせるのと同じで、そういう戦略では得るものがありません。より良い方法は、スクレイパーの IP を裏でマークしておき、ページにランダムに混ぜ込んだゴミデータだけを渡すことです。
      チート検出も同じだと思います。ブロックすれば戦略的優位を失うだけで、IP や CD キーやアカウントの交換はチーターにとって些細な不便にすぎません。
    • この方式は、モバイルデータのテザリングやプロキシを使うチーターには依然として破られます。より高度な ネットワーク分析を検討したことがあるのか気になります。
      仕事としても個人的にも関心のある分野なので、提案が必要なら手伝えます。

  • 筆者が例示用 IPv4 アドレスに RFC5737 の TEST-NET-2 アドレスを使っている点が良いです: “An example of an IPv4 IP address is 198.51.100.1.”
    https://www.rfc-editor.org/rfc/rfc5737

    • 例示用に予約された識別子を使うのがとても好きです。ドキュメントでは TEST-NET-2 IP と example.com をいつも使っています。
    • 興味深いのは、ドキュメントが予約アドレスをタイプミスして使っている場合です。例えば 189.51.100.1 や 198.15.100.1 のような形で、実際にこうした RFC がいくつもあります。

  • いつかキャリアの中で、サーバーサイド専用のアンチチートをぜひ扱ってみたい。こういう敵対的な軍拡競争は、長く深く考えるのが本当に面白そう

    • 問題は、多くの会社がそのコストを払いたがらないこと。「ランニングマシン作業」なので、人やお金をいくら投入しても結局また元に戻ってくる
      プレイヤー数は開発者数よりはるかに多いので、負け戦になる
    • 今取り組んでいる分野。本当の問題は、重要な処理をすべてサーバーで行うには性能コストが大きいことで、開発者が怠けてクライアントにあまりに多くの仕事を押し付け、それが標準のように定着してしまった
      重要な行動をすべてサーバーへ移すのは簡単でも安価でもないが、チートをより包括的に防ぐ方法ではある
      そこに物理演算の多いゲーム、120 tickrate（追加テスト後にさらに上げる可能性もある）、細かな操作ベースのアクション戦闘、MMORPG規模への拡張を目標にすると、本当に難しくなる
    • 最新の技術水準はかなり退屈で、ユーザーコマンドのペイロードは午後の半日もあれば学べる
      今ではYOLOベースのエイムボットがあり、世界はずっと複雑になった。現実的な結論は、アンチチートはいずれ破られ得るということ
      クライアント側では、主要なアンチチートサービスにハッシュが登録されていない個人用バイナリを作れるし、サーバー側ではゲームルール上許されるものしか見えない
      超人的な反応速度を防ぐ仕組みはなく、おそらくあるべきでもないため、もはや解けない問題になる
      だからコミュニティによる判断が必要になるが、これも退屈。Counter-Strikeで上手いプレイヤーがチーター扱いされるのは、昔からあると同時に面白い問題
    • この仕事は人々の生活もかなり改善する。オンラインゲーム全体がチーターのせいで無人地帯になることもある
      数年前にBattlefieldのゲームをいくつか買ったが、スピードハックやエイムボットのチーターのせいで、いくつかはプレイできなかった。サーバー側で簡単に検知できそうなのに、なぜ何もしないのかと思った
    • Minecraftでしかやったことはないが、かなり面白かった

  • Webサイトが落ちている、または遅くて記事を読みたいなら、ページ全体のスクリーンショットがある: https://i.imgur.com/SPp6IHX.jpeg
    この記事がこんなに多くのトラフィックを受けるとは思っていなかった

  • この記事はチーターを防ぐこと、つまりチート検知ではなく、BANされたチーターが繰り返し戻ってくるBAN回避を防ぐ話
    特に最近はDMAのようなハードウェアチートまである状況で、チート検知はまったく別のゲーム。個人的には、BAN回避者を防ぐ最も効果的な方法の1つは、ゲームで実際にお金を取ることだと思う

    • ブログの事件当時、CS:GOは無料ではなかったにもかかわらず、80個を超えるアカウントにアクセスできるように見えるチーターたちがいた
    • チーターは価格に敏感ではない。小さな子ども用プールで王様のように振る舞うのが彼らの好む娯楽なので、新しいアカウントやゲームキーに毎月60ドルを使っても気にしない
      CS:GOの人たちは、数百ドル相当のスキンが入ったアカウントがBANされてもあまり気にしない。他人の盗まれたアカウントを5ドル程度で買ったか、どうせチートサービスに月30ドル払っているから
      常習的なチーターとpay-to-winのクジラの間には、ものすごく大きな重なりがありそう
      ゲームでチーターを減らす、より信頼できる方法はチーター用ハニーポット。BANして新しいアカウントを買ったチーターを再び追跡するのではなく、静かに他のチーター、わざとイライラするように作ったボット、偽の遅延、ときどきキー入力を無視する、といったマッチメイキングにだけ入れてしまう
      彼らの楽しみを台無しにすれば、彼らはゲームを台無しにするのをやめる。そうすると情報戦が逆回転し、新しいアカウントを買うべきかを知るために、自分がチーターやボットと定期的にプレイしているかどうかをまず見抜かなければならなくなる
    • TPM基準のBANも、回避をかなり高くつくものにする。その時点から、チーターは新しいマザーボードを買うか、マザーボードに新しいTPMチップをはんだ付けしなければならない
      もちろん、いつかずさんなサプライヤーがTPMキーを流出させれば、偽造可能になるかもしれない

  • 大きな国のプレイヤーは、小さな国にあるコミュニティ感を見落としがち
    毎日ゲームをする人がサーバー3〜4台分しかいなければ、すぐに互いを知るようになり、それがジョークや楽しさを大きく増してくれる

    • プレイヤーベースが小さい古いマルチプレイヤーゲームを遊んでいて、そういう感覚を少し味わった
      一緒に1試合した人を二度と見ることがない、数百万人規模のゲームよりずっと良い。同じ理由で、コミュニティ運営サーバーがあるゲームも好き
    • ある程度年齢が上なら、Gamespyでサーバーをお気に入り登録していたことを覚えているはず
      誰が接続しているか、そして主に自分の接続状態がどれだけ良いかによって、同じサーバーに入り続けることになった

  • 「別のSteam IDで接続してきたが、すでにBANされたIPアドレスを使っているなら再びBANする」という方式は、CGNATとIPアドレスのローテーションのせいで無実のプレイヤーを罰することになると気づくまではうまく機能する
    チーターはたいてい、ルーターに新しいIPを要求させる方法を知っていて、そのIPは後で別の人に割り当てられる

    • 実際にそういう状況が起き、ユーザーのBANを解除したり例外を作ったりするために、ケースごとに検討した
      ただし、かなりまれで、数か月間に報告されたのは片手で数えられる程度だった。サーバーがもっと人気なら、はるかに頻繁に経験したはず
    • 記事の「Problematic cases of IP address fingerprinting」セクションでこの問題を扱っていた
    • そういう状況では、誤検知を減らすために秘密のCookieに頼ったと思う

  • 「英国にいる、完全に信頼している別のサーバー運営者1人だけに解決策と手法を共有した」というなら、おそらくそれは私たちだったと思う
    結局は他のフィンガープリンティング信号と組み合わせたが、VGUIを使う方式は驚くほど効果的だった。2018年ごろにWebブラウザーが削除されたと記憶しているが、残念だった。サーバーと連動するカスタムスキルツリーや面白い統合を作れたので、非常に強力だった

  • 「トラフィック自体はHTTPSで暗号化されているので、Wiresharkのようなパケットスニッフィングツールを使っても生のトークンは見つけられない」という点については、内蔵ブラウザがシステムプロキシとシステムの証明書リストを使っていたなら、FiddlerやBurp SuiteのようなツールでHTTPSを復号するのはとても簡単です

    • 要点は、Wiresharkを動かしたときに問題がどれほど目立つかです。目立たないため、実際に何が起きているのかを突き止めるには、はるかに多くの作業が必要になります
      リクエストも他のリクエストの間に普通に紛れ込んでおり、それらのリクエストは予想できるものです。通常、MOTDリクエストは当然あるはずなので、不自然には見えません
      回避方法がローカルファイルを1つ削除するだけのようにはるかに単純な状況では、実際のリクエストを見つけてFiddlerやBurp Suiteを設定するよりも、これで十分うまく機能していました
      過剰に設計する必要はありません
    • 作者が念頭に置いていた対象は、HNの読者層ではなく、平均的なスクリプトキディだったのだと思います
    • Firefoxから秘密鍵をエクスポートしてWiresharkに取り込むのもかなり簡単です
      数回クリックすればよく、使っているTLSによっては接続ごとに行う必要があるかもしれませんが、それほど難しくはありません

  • 「特許を取るべきだった」というのは冗談だと分かっていますが、もし特許を取っていたなら、その手法を公開しなければならず、すぐに役に立たなくなっていたでしょう
    とはいえ、記事自体を少しも貶めるつもりはありません。楽しく読みました