サーバーソフトウェアの整合性を確認していますか？
サーバーソフトウェアの整合性を検証する問題について、セキュリティスキームをブレインストーミングしようとしています。この問題のドメインは、Valveの Source Dedicated Servers 上に構築されたゲームサーバーです。これらのサーバーは競争の激しいゲームで使用され、これらのサーバーの完全性はトーナメントの実行などにおいて非常に重要です。
ゲームのクライアントは、ValveのSteamシステムによってさまざまな方法ですでに十分に検証されています。さまざまなコンテンツ検証および不正防止システム（VAC）があるため、クライアント側のコンテンツが変更されることはほとんどありません。
ただし、サーバー側では、クライアントが変更されていないバージョンのソフトウェアで確実に再生できるようにするための保護スキームはほとんどありません。ソフトウェア自体は本質的に構成可能であり（構成変数とコマンドを使用）、 サーバープラグイン を使用して機能を拡張できます。さらに、ファイルシステム上またはメモリ内のサーバーコードに対するチェックはありません。 SRCDSサーバーは、本質的に多くのレベルで変更可能です。
これは、ソースエンジンでの競争ゲームに問題を引き起こします。任意の数のConVarの変更、プラグイン、またはサーバーバイナリの変更を使用して、「チート」することができます。つまり、ゲームプレイの力学において、あるチームを他のチームよりも有利にしたり、あるプレイヤーを他のプレイヤーよりも有利にしたりすることができます。現在、クライアントまたはサードパーティがSRCDSサーバーが変更されていないことを確認する方法はありません。
この問題の基本的な解決策はオープンであるようです。クライアントにConVar値の変更を通知したり、サーバーで実行されているプラグインのリストをクライアントが利用できるようにしたり、ディスクおよびメモリ内のファイルのCRCチェックを実行して、クライアントに結果の値を提供したりできます。ただし、これは、発表された/提供された情報を改ざんするサーバーと区別できません。この道を進んだものは、本質的にセキュリティというよりもあいまいな感じがします。
サーバーへのチャレンジ/レスポンスのみを使用してサーバーソフトウェアの整合性を検証するシステムを設計するにはどうすればよいですか？
追伸お気軽にご質問ください。
すばらしい質問ですね。これは、ゲーム業界を分割する要素の1つだと思います。サーバーを集中管理してサーバーを制御しますが、ゲーマーのニーズに対する柔軟性の欠如に悩まされ、鉄の拳で裁定したと非難されたり、制御を与えたりしますかゲーマー人口に悪意のあるまたは汚染されたサーバーのリスクを実行します。
3つの考えが思い浮かびますが、どれも理想的ではありませんが、役に立つかもしれません。
クライアントに設定をアナウンスします-これはサーバーの大きな妥協を先延ばしにすることはありませんが、悪意のあるパーティから要求される努力を増やします。
信頼と評判のルートをたどり、正直であるかどうかにかかわらず、ゲーマーレートサーバーを使用します。これにも問題があり、担当者もゲームをプレイできますが、これは別のオプションです。
クエリを実行できるモジュールとしてサーバーソフトウェアを提供し（la punkbusterおよびValve独自のチェック）、不整合を無効にします。繰り返しますが、誰かがコードを分析して送信する応答を理解すると、この種のことがいつか壊れることが何度も証明され、サーバーの所有者を困らせますが、悪意のあるパーティー。
信頼できないサーバーから直接得られる答えに自信を持つことができる可能性はほとんどありません。それを保証するために第三者が必要であるようです。例えば。クラウドサービスプロバイダーに、オペレーターが特定のISOイメージをいくつかの標準ハードウェアにロードし、その後、十分に制約された構成インターフェイスに関連付けられた特定のポートを通じてのみそれと通信したことを証明する方法を見つけます。クラウドプロバイダーのいずれかがそれを行うかどうか以前に疑問に思いました。
原則として、技術的な解決策があります。すべてのサーバーにTPMが含まれていることを確認し、リモート証明書を使用して、サーバーが正当なサーバー側ソフトウェアを実行していることを各クライアントに証明させることができます。
ただし、実際にはエンジニアリング上の重大な課題があり、このアプローチが非常に現実的でないか、設定での価値よりも高くなる可能性があります。たとえば、クライアントには、どのバージョンのソフトウェアが許可されているかのマスターリストを取得する方法が必要です。サーバーはTPMハードウェアを使用するようにプログラムする必要があります（これは少し特殊な操作です）。証明後にサーバーソフトウェアの整合性が損なわれないようにするためのスキームを考案する必要があります。およびその他の課題。これはすべて、エンジニアリングと管理の主要なプロポーションの面倒のように聞こえます。
残念ながら、TPMのリモート認証機能は現在広く使用されていないため、他の人の努力と経験に基づいて構築することはできません。したがって、このアプローチを採用したい場合は、最先端を行くことになります。プログラムマネージャーを悲鳴させるようなもののように聞こえます。
したがって、私がこのアプローチを小規模の独立系ソフトウェアベンダーに推奨することはおそらくありませんが、原則として、あなたが言及する種類の脅威に対して無理のない適切なセキュリティを提供できると思われます（リソースが無制限の場合）。