レイヤード サービス プロバイダーとアプリの分類
Note
レイヤード サービス プロバイダーは非推奨です。 Windows 8 および Windows Server 2012 以降では、Windows フィルタリング プラットフォームを使用してください。
Winsock 2 は、レイヤード プロトコルに対応しています。 レイヤード プロトコルは、リモート エンドポイントとの実際のデータ交換のための基になるトランスポート スタックに依存しながら、上位レベルの通信機能のみを実装するプロトコルです。 レイヤード プロトコルまたはレイヤード サービス プロバイダーの例には、認証を実行し、互いに合意された暗号化スキームを確立するために接続確立プロセスにプロトコルを追加するセキュリティ レイヤーがあります。 このようなセキュリティ プロトコルには一般に、TCP や SPX などの、基になる信頼性の高いトランスポート プロトコルのサービスが必要になります。 基本プロバイダーによって実装される基本プロトコルという用語は、リモート エンドポイントとのデータ通信を実行できる TCP や SPX などのプロトコルを実装する Winsock プロバイダーを指します。 レイヤード プロトコルという用語は、単独では機能できないプロトコルを説明するために使用されます。 これらのレイヤード プロトコルは、Winsock レイヤード サービス プロバイダー (LSP) としてインストールされます。
LSP の例として、クライアントに Internet Security and Authentication Server (ISA) の一部としてインストールされる Microsoft Firewall Client Service Provider が挙げられます。 Microsoft ファイアウォール クライアント サービス プロバイダーは、TCP や UDP のための Winsock 基本プロバイダーの上にインストールされます。 ISA ファイアウォール クライアント ソフトウェア内のダイナミック リンク ライブラリ (DLL) は、すべての Winsock アプリケーションが透過的に使用する Winsock レイヤード サービス プロバイダーになります。 これにより、ISA ファイアウォール クライアント LSP は、クライアント アプリケーションからの Winsock 関数呼び出しをインターセプトし、宛先がローカルである場合は元の基になる基本サービス プロバイダーに、宛先がリモートである場合は ISA Server コンピューター上のファイアウォール サービスに要求をルーティングできます。 同様の LSP が Microsoft Forefront Firewall Service および Threat Management Gateway (TMG) クライアントの一部としてクライアントにインストールされます。
LSP の初期化中に、LSP は複数の Winsock サービス プロバイダー インターフェイス (SPI) 関数へのポインターを提供する必要があります。 これらの関数は、通常の処理中に LSP のすぐ上のレイヤー (別の LSP または Ws2_32.DLL のどちらか) によって呼び出されます。
LSP で実装される SPI 関数のサブセットと、これらの各関数に対して実行される追加の処理の性質に基づいて LSP カテゴリを定義できます。 LSP を分類するだけでなく、Winsock ソケットを使用するアプリケーションを分類することによって、実行時に LSP を特定のプロセスに関与させる必要があるかどうかを選択的に判定できるようになります。
Windows Vista 以降では、特定の LSP のみが読み込まれるように、Winsock レイヤード サービス プロバイダーとアプリケーションの両方を分類するための新しいメソッドが提供されています。 これらの関数の追加には、いくつかの理由あります。
主な理由の 1 つは、winlogon や lsass などのシステム クリティカルな特定のプロセスがソケットを作成することですが、これらのプロセスは、ネットワーク上でトラフィックを送信するためにこれらのソケットを使用しません。 そのため、ほとんどの LSP は、これらのプロセスに読み込むべきではありません。 また、バグのある LSP のために lsass.exe がクラッシュする場合があるケースもいくつか文書化されています。 lsass がクラッシュすると、システムは強制的にシャットダウンされます。 これらのシステム プロセスでの LSP の読み込みの副作用として、これらのプロセスが終了しなくなるため、LSP がインストールまたは削除されたときに再起動が必要になることがあります。
2 つ目の理由は、アプリケーションで特定の LSP を読み込みたくないいくつかのケースがあることです。 たとえば、アプリケーションによっては、そのアプリケーションと暗号化 LSP がインストールされていない他のシステムとの通信ができなくなる可能性がある暗号化 LSP を読み込みたくない場合があります。
最後に、LSP カテゴリは、他の LSP がそれ自体をインストールすべき Winsock プロトコル チェーン内の場所を特定するために使用できます。 何年もの間、さまざまな LSP 開発者は、LSP がどのように動作するかを知るための方法を望んできました。 たとえば、データ ストリームを検査する LSP は、データを暗号化する LSP の上に配置したいと考えます。 もちろん、この LSP の分類方法は、それ自体を適切に分類するためにサードパーティ LSP に依存するため、フール プルーフではありません。
Windows Vista 以降の LSP の分類やその他のセキュリティ強化は、ユーザーが悪意のある LSP を誤ってインストールすることを防ぐのに役立つように設計されています。
LSP カテゴリ
Windows Vista 以降では、LSP は、それが Windows ソケットの呼び出しやデータをどのように操作するかに基づいて分類できます。 LSP カテゴリは、Winsock SPI 関数のサブセットに対する動作の識別可能なグループです。 たとえば、HTTP コンテンツ フィルターはデータ インスペクター (LSP_INSPECTOR カテゴリ) として分類されます。 LSP_INSPECTOR カテゴリは、データ転送 SPI 関数へのパラメーターを検査します (ただし、変更はしません)。 アプリケーションでは、LSP のカテゴリをクエリし、LSP カテゴリと、そのアプリケーションの許可された一連の LSP カテゴリに基づいて LSP を読み込まないことを選択できます。
次の表は、LSP を分類できるカテゴリの一覧を示しています。
| LSP カテゴリ | 説明 |
|---|---|
| LSP_CRYPTO_COMPRESS | この LSP は暗号化またはデータ圧縮プロバイダーです。 |
| LSP_FIREWALL | この LSP はファイアウォール プロバイダーです。 |
| LSP_LOCAL_CACHE | この LSP はローカル キャッシュ プロバイダーです。 |
| LSP_INBOUND_MODIFY | この LSP は受信データを変更します。 |
| LSP_INSPECTOR | この LSP はデータを検査またはフィルター処理します。 |
| LSP_OUTBOUND_MODIFY | この LSP は送信データを変更します。 |
| LSP_PROXY | この LSP はプロキシとして機能し、パケットをリダイレクトします。 |
| LSP_REDIRECTOR | この LSP はネットワーク リダイレクターです。 |
| LSP_SYSTEM | この LSP は、サービスやシステム プロセスで使用できます。 |
LSP が複数のカテゴリに属している場合があります。 たとえば、ファイアウォール/セキュリティ LSP は、インスペクター (LSP_INSPECTOR) とファイアウォール (LSP_FIREWALL) の両方のカテゴリに属している可能性があります。
LSP にカテゴリが設定されていない場合は、[その他すべて] のカテゴリに存在すると見なされます。 この LSP カテゴリは、サービスまたはシステム プロセス (lsass、winlogon、多数の svchost プロセスなど) には読み込まれません。
LSP の分類
LSP を分類するために、Windows Vista 以降では、次のいくつかの新しい関数を使用できます。
LSP を分類するために、WSCSetProviderInfo または WSCSetProviderInfo32 関数は、LSP 非表示エントリを識別するための GUID、この LSP プロトコル エントリに対して設定される情報クラス、この関数の動作を変更するために使用される一連のフラグを使用して呼び出されます。
WSCGetProviderInfo または WSCGetProviderInfo32 関数も同様に、LSP の情報クラスに関連付けられたデータを取得するために使用されます。
アプリケーションの分類
アプリケーションを分類するために、Windows Vista 以降では、次のいくつかの新しい関数を使用できます。
アプリケーションを分類するために、WSCSetApplicationCategory 関数は、アプリケーションを識別するための実行可能イメージへの読み込みパス、アプリケーションを起動するときに使用されるコマンド ライン引数、このアプリケーションのすべてのインスタンスで許可される LSP カテゴリを使用して呼び出されます。
WSCGetApplicationCategory 関数も同様に、アプリケーションに関連付けられたレイヤード サービス プロバイダー (LSP) カテゴリを取得するために使用されます。
どの LSP が読み込まれるかの特定
LSP の分類の最後の部分は、どのプロセスにどの LSP が読み込まれるかの特定です。 プロセスが Winsock を読み込むときは、アプリケーション カテゴリと、インストールされているすべての LSP の LSP カテゴリから次の比較が行われます。
- アプリケーションが分類されていない場合は、そのプロセスへのすべての LSP の読み込みが許可されます。
- アプリケーションと LSP の両方にカテゴリが割り当てられている場合は、次のすべてに当てはまる必要があります。
- アプリケーションの指定されたカテゴリに少なくとも 1 つの LSP カテゴリが存在する。
アプリケーションの指定されたカテゴリで指定されているカテゴリのみが LSP のカテゴリで指定されている。 たとえば、アプリケーションがカテゴリを指定する場合、それは LSP のカテゴリに存在する必要があります。
LSP_SYSTEM カテゴリがアプリケーションのカテゴリに存在する場合、それは LSP のカテゴリに存在する必要があります。
Note
LSP が分類されていない場合、そのカテゴリは実質的に 0 です。 一致が発生するには、LSP の指定されたすべてのカテゴリがアプリケーションのカテゴリに存在する必要があります (アプリケーションのカテゴリは LSP のカテゴリのスーパーセットである必要があります)。ここで、LSP_SYSTEM がアプリケーションのカテゴリに存在する場合、それは LSP のカテゴリにも存在する必要があるという注意点があります。
次の例を考えてみましょう。
Foo.exe アプリケーションは、LSP_SYSTEM + LSP_FIREWALL + LSP_CRYPTO_COMPRESS として分類されます。 アプリケーション Bar.exe は、LSP_FIREWALL + LSP_CRYPTO_COMPRESS として分類されます。 システムには、次の 4 つの LSP がインストールされています。
- LSP1 には、LSP_SYSTEM のカテゴリが設定されています。
- LSP2 にはカテゴリが設定されていないため、そのカテゴリは 0 です。
- LSP3 には、LSP_FIREWALL のカテゴリが設定されています。
- LSP4 には、LSP_SYSTEM + LSP_FIREWALL + LSP_CRYPTO_COMPRESS + LSP_INSPECTOR のカテゴリが設定されています。
この例では、Foo.exe アプリケーションが LSP1 のみを読み込むのに対して、Bar.exe アプリケーションは LSP3 を読み込みます。
インストールされている Winsock プロバイダーの特定
Microsoft Windows ソフトウェア開発キット (SDK) には、ローカル コンピューターにインストールされている Winsock トランスポート プロバイダーを特定するために使用できるサンプル Winsock プログラムが含まれています。 既定では、この Winsock サンプルのソース コードは、Windows SDK for Windows 7 の次のディレクトリにインストールされます。
C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\NetDs\winsock\LSP
このサンプルは、レイヤード サービス プロバイダーをインストールしてテストするためのユーティリティです。 ただし、これは、ローカル コンピューター上の Winsock カタログから詳細情報をプログラムで収集するためにも使用できます。 基本プロバイダーとレイヤー サービス プロバイダーの両方を含む現在のすべての Winsock プロバイダーを一覧表示するには、この Winsock サンプルをビルドし、次のコンソール コマンドを実行します。
instlsp -p
この出力は、レイヤード サービス プロバイダーを含む、ローカル コンピューターにインストールされている Winsock プロバイダーの一覧になります。 この出力では、Winsock プロバイダーのカタログ ID と文字列名が一覧表示されます。
すべての Winsock プロバイダーに関するより詳細な情報を収集するには、次のコンソール コマンドを実行します。
instlsp -p -v
この出力は、ローカル コンピューターでサポートされている WSAPROTOCOL_INFO 構造の一覧になります。
ローカル コンピューターにインストールされているレイヤード サービス プロバイダーのみの一覧を取得するには、次のコンソール コマンドを実行します。
instlsp -l
LSP 構造をマップするには、次のコンソール コマンドを実行します。
instlsp -m
Note
TDI 機能は非推奨であり、Microsoft Windows の将来のバージョンでは削除される予定です。 TDI の使用方法に応じて、Winsock カーネル (WSK) または Windows フィルタリング プラットフォーム (WFP) のどちらかを使用してください。 WFP と WSK の詳細については、「Windows フィルタリング プラットフォーム」およびWinsock カーネルに関するページを参照してください。 WSK と TDI に関する Windows コア ネットワークのブログ エントリについては、Winsock カーネル (WSK) の概要に関するページを参照してください。