MS-RPC とそのセキュリティメカニズムの概要

ネットワーク（またはローカル）の観点から見ると、サーバーとクライアントはどのように通信しているのでしょうか。サーバーは、プロトコルシーケンスとエンドポイントの組み合わせを登録することで、RPC 接続の着信をリッスンします。プロトコルシーケンスは、たとえば、 ncacn_ip_tcp （TCP）、 ncacn_np （名前付きパイプ）、または ncalrpc （LPC）などです。エンドポイントは、TCP 5555 や \\pipe\\example（名前付きパイプが使用される場合）のようなポートです。名前付きパイプは、TCP ポート 445 を介して SMB トランスポートで伝送されます。これには非表示の IPC$ 共有が使用されます。プロトコルシーケンスの全リスト については、 Microsoft の Web サイトを参照してください。

サーバーは何らかのエンドポイントで接続をリッスンしますが、クライアントは接続先をどのように把握するのでしょうか。その答えはエンドポイントのタイプ、つまり動的か well-known（静的）かによって異なります。

動的なエンドポイントとは、サーバー側でエンドポイントマッパーを通じて登録されたエンドポイントです。エンドポイントマッパー（別名 epmapper）は、サービスを実際のエンドポイントにマッピングする RPC サービスです。epmapper は、RPC over HTTP に TCP ポート 135 と 593 を使用します。そのためクライアントは、epmapper を使用してリモートマシンで動的に登録された RPC サーバーをすべて列挙できます（ 指定された APIを使用）。

well-known エンドポイントとは、epmapper 経由で登録されなかったエンドポイントのことです。クライアントは、サーバーがあらかじめ登録していたエンドポイントを知っている必要があります。これが可能となるのは、そのエンドポイントがクライアントとサーバーの両方のコードにハードコードされている場合、またはそのエンドポイントが IDL ファイル内にある場合です。以下にプリント・スプーラー・サービスの IDL の例を示します。

[

uuid(12345678-1234-ABCD-EF00-0123456789AB),

version(1.0),

ms_union,

endpoint("ncacn_np:[\\pipe\\spoolss]"),

pointer_default(unique)

]

RPC は、バインディングハンドルを使用した、クライアントとサーバー間の論理接続です。サーバーとクライアントのどちらも、認証情報の設定時などに、関数を使用してバインディングデータを操作します。クライアントがバインディングに認証を設定すると、そのバインディングは認証済みとみなされます。クライアントプログラムが RPC 関数を呼び出すと、ネットワークバインディングが発生します。ネットワークトラフィックの観点から言えば、RPC クライアントは、認証情報を含むパケットでバインド要求を送信し、RPC インタラクションを開始します。サーバーは、bind_ack（確認）または bind_nak（エラーが発生）で応答します。

図 2 の Wireshark スニペットには、Task Scheduler インターフェースの動的エンドポイント解決が示されています。クライアントは Task Scheduler のエンドポイント情報を入手すると、新しい接続を作成します。その後、別のバインディングプロセスとの新たな接続が見られ、バインディング認証の一部として AUTH3 パケットが含まれています。

エンドポイントと同様に、バインディングにも、自動、暗黙的、明示的など、いくつかのタイプがあります（図 3）。アプリケーションがバインディングプロセスを制御する度合いはこれらの各タイプで異なります。 

• 自動バインディング（廃止）：クライアントとサーバーのアプリケーションは、バインディングプロセスを処理せず、代わりに RPC ランタイムがこのプロセスを完全に制御します。
  
• 暗黙的バインディング：クライアントには、バインディングを実行する前にバインディングハンドルを設定するオプションが与えられます。クライアントがバインディングを確立すると、RPC ランタイムライブラリが残りの処理を行います。
  
• 明示的バインディング：クライアントがバインディングハンドルを設定する必要があります。 RPC ランタイムはそれをサーバーに渡すだけです。

ここまで、RPC の基本的な仕組みを説明してきました。ここからは、クライアントが関数にアクセスできないようにするためのアクション、ポリシー、メカニズムについて見ていきます。これは、攻撃と防御の両面で興味深いトピックです。

トランスポート認証

名前付きパイプや HTTP などの一部のトランスポートには、プロトコルの一部として認証が含まれています。たとえば、名前付きパイプは、SMB を介して伝送され、SMB に認証が含まれています。基本的に、サーバーが名前付きパイプエンドポイントを登録すると、そのエンドポイントには有効なユーザーの資格情報を持つクライアントしか接続できません。ドメイン環境では、同じドメイン内にドメインユーザーがいるだけで、認証チェックに合格できます。マシンがドメインに属していない場合、クライアントは、リモートサーバー上のローカルユーザーの資格情報を必要とします（図 4）。除外については後述します。

インターフェースフラグの使用

インターフェースのセキュリティを確保するための 3 つ目の方法は、インターフェースフラグを使用することです。このフラグは、インターフェースの作成時に RpcServerRegisterIf* 関数を使用して設定します。セキュリティに関するインターフェースフラグには次のようなものがあります。

RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH — 使用する転送方式や認証レベルにかかわらず、呼び出しのたびにセキュリティコールバックが呼び出されます。 

RPC_IF_ALLOW_LOCAL_ONLY — ローカルのリクエストのみ許可します。

RPC_IF_ALLOW_SECURE_ONLY — 認証レベルが RPC_C_AUTHN_LEVEL_NONE よりも高いクライアントのみ接続できます。このフラグを指定すると、NULL セッションを使用してアクセスするクライアントは拒否されます。このフラグは、クライアントが有効な認証情報を保有していることを保証するだけであり、呼び出し元のユーザーが特権レベルを保有していることを保証するわけではありません。

RPC_IF_SEC_NO_CACHE — このフラグは、インターフェースのセキュリティコールバックのキャッシュを完全に無効にします。

RPC_IF_SEC_CACHE_PER_PROC — このフラグは、キャッシュメカニズムを完全に無効にするのではなく、デフォルトのふるまいをインターフェースベースからコールベースに変更します。

サーバーのプログラマーは、インターフェース上の関数にセキュリティチェックを含めることができます。つまり、呼び出す関数ごとにチェックのロジックを変更またはカスタマイズできます。一般的なセキュリティチェックとして、図 6 に示すようなアクセスチェック（srvsvc）があります。