フィルターアービトレーション

フィルター判定は、Windows フィルタリング プラットフォーム (WFP) に組み込まれているロジックであり、ネットワーク トラフィック フィルタリングの決定を行うときにフィルターが相互に対話する方法を決定するために使用されます。

フィルター判定の動作

次の動作は、フィルター判定システムを特徴付けます。

• すべてのトラフィックを検査できます。 トラフィックは、特定のレイヤーでフィルターをバイパスできません。
• 優先度の高いフィルターで許可されている場合でも、Veto を介してコールアウト フィルターによってトラフィックをブロックできます。
• 複数のプロバイダーが同じレイヤーでトラフィックを検査できます。 たとえば、ファイアウォールの後に侵入検出システム (IDS) フィルターが続く場合や、IPsec の後にサービス品質 (QoS) フィルターが続く場合は、すべて同じレイヤーのトラフィックを調べることができます。

モデルのフィルター処理

各フィルター レイヤーは、優先順位 (重みとも呼ばれます) で並べ替えられたサブレイヤーに分割されます。 ネットワーク トラフィックは、最も高い優先度から最も低い優先度までのサブレイヤーを通過します。 サブレイヤーは、WFP API を使用して開発者によって作成および管理されます。

各サブレイヤー内では、フィルターは重み順に並べ替えられます。 ネットワーク トラフィックは、最高の重みから最も低い重みまでのフィルターに一致するように示されます。

フィルター判定アルゴリズムは、レイヤー内のすべてのサブレイヤーに適用され、最終的なフィルター処理の決定は、すべてのサブレイヤーが評価された後に行われます。 これにより、複数の照合機能が提供されます。

サブレイヤー内では、フィルター判定は次のように実行されます。

• 一致するフィルターの一覧を重み順に高い順に計算します。
• "許可" または "ブロック" が返されるまで (フィルターは "Continue" を返すこともできます)、またはリストが使い果たされるまで、一致するフィルターを順番に評価します。
• 残りのフィルターをスキップし、最後に評価されたフィルターからアクションを返します。

レイヤー内では、フィルター判定は次のように実行されます。

• 優先度が最も高いものから優先度が最も低い順に、すべてのサブレイヤーでフィルター判定を実行します。
• 優先度の高いサブレイヤーがトラフィックをブロックすることを決定した場合でも、すべてのサブレイヤーを評価します。
• 次のセクションで説明するポリシー 規則に基づいて、結果のアクションを返します。

次の図は、サブレイヤー構成のサンプルを示しています。 外側のボックスはレイヤーを表します。 内部ボックスは、フィルターを含むサブレイヤーを表します。 フィルターのワイルドカード (*) は、すべてのトラフィックがフィルターと一致します。

サブレイヤー構成する

フィルターをバイパスする唯一の方法は、上位の重みフィルターが同じサブレイヤー内のトラフィックを許可またはブロックしている場合です。 逆に、フィルターでレイヤー内のすべてのトラフィックが常に表示されるようにする方法の 1 つは、すべてのトラフィックに一致する 1 つのフィルターを含むサブレイヤーを追加することです。

構成可能なオーバーライド ポリシー

以下で説明する規則は、レイヤー内の仲裁決定を管理します。 これらのルールは、ネットワーク トラフィックに適用されるサブレイヤー アクションの 1 つを決定するためにフィルター エンジンによって使用されます。

基本方針は以下のとおりです。

• アクションは、最も優先度の高いサブレイヤーから最も優先順位の低いサブレイヤーの優先順位で評価されます。
• "ブロック" は "Permit" をオーバーライドします。
• "Block" は final (オーバーライドできません) であり、評価を停止します。 パケットは破棄されます。

基本ポリシーでは、ファイアウォールによってオーバーライドされない例外のシナリオはサポートされていません。 この種類のシナリオの一般的な例を次に示します。

• サード パーティのファイアウォールが存在する場合でも、リモート管理ポートを開く必要があります。
• 機能するためにポートを開く必要があるコンポーネント (ユニバーサル プラグ アンド プレイ UPnP など)。 管理者がコンポーネントを明示的に有効にしている場合、ファイアウォールはトラフィックをサイレント でブロックしないようにする必要があります。

上記のシナリオをサポートするには、アクションオーバーライドのアクセス許可を管理することで、フィルター処理の決定を別のフィルタリング決定よりもオーバーライドすることが困難である必要があります。 このアクセス許可は、FWPS_RIGHT_ACTION_WRITE フラグとして実装され、フィルターごとに設定されます。

評価アルゴリズムでは、現在のアクション ("Permit" または "Block") が FWPS_RIGHT_ACTION_WRITE フラグと共に保持されます。 このフラグは、優先度の低いサブレイヤーがアクションをオーバーライドできるかどうかを制御します。 FWPS_CLASSIFY_OUT0 構造体で FWPS_RIGHT_ACTION_WRITE フラグを設定またはリセットすることで、アクションをオーバーライドする方法とオーバーライドできない方法をプロバイダーが管理します。 フラグが設定されている場合は、アクションをオーバーライドできることを示します。 フラグがない場合は、アクションをオーバーライドできません。

フィルター アクションは、構造体 FWPM_ACTION0 内の 型 メンバーを FWP_ACTION_BLOCK または FWP_ACTION_PERMITに設定することで設定できます。 アクションの種類と共に、フィルターはフラグ FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHTも公開します。 このフラグをクリアすると、後で説明するように、ハード許可が Veto によってオーバーライドされる場合を除き、アクションの種類はハードであり、オーバーライドできません。それ以外の場合は、優先度の高いアクションによってオーバーライドできるソフトです。

次の表に、フィルターアクションと吹き出しアクションの既定の動作を示します。

Veto は、フィルターを呼び出す前に FWPS_RIGHT_ACTION_WRITE フラグがリセットされたときにフィルターによって返される "ブロック" アクションです。 Veto は、ハード許可で許可されたトラフィックをブロックします。

Veto が発行されると、構成の競合が示されます。 競合を軽減するために、次のアクションが実行されます。

• トラフィックはブロックされます。

• 監査イベントが生成されます。

• 通知が生成されます。

  手記

  通知は、サブスクライブしているすべてのエンティティによって受信されます。 これには通常、ファイアウォール (誤った構成を検出するため)、またはアプリケーション (特定のフィルターがオーバーライドされているかどうかを検出するために) が含まれます。

  手記

  "ハード許可" フィルターがオーバーライドされたときにインスタンス化される必須のユーザー インターフェイス (UI) はありません。 オーバーライドの通知は、受け取るために登録されたすべてのプロバイダーに送信されます。これにより、ファイアウォールまたは "許可" フィルターを作成したアプリケーションは、ユーザーアクションを要求する UI を表示できます。 これらのオーバーライド イベントに対してプラットフォーム UI 通知を行う価値はありません。サイレント ブロックを望まないファイアウォール ISV は WFP の別の場所に登録することでこれを行うことができるか、(あまり推奨されない) コールアウト ドライバーですべてのロジックを処理できるためです。 ユーザーにプロンプトを表示することが適切であると考える ISV は、ユーザー エクスペリエンスを所有し、独自の UI を作成することをお勧めします。

上記の軽減動作により、"ハード許可" フィルターが "ブロック" フィルターによって自動的にオーバーライドされないようにし、リモート管理ポートがファイアウォールによってブロックされないようにするシナリオについて説明します。 "ハード許可" フィルターを自動的にオーバーライドするには、ファイアウォールのフィルターを優先度の高いサブレイヤー内に追加する必要があります。

ポートを開くよう要求するユーザー アプリケーションは、優先順位の低いサブレイヤーにオーバーライド可能なフィルターを追加します。 ファイアウォールは、フィルターにサブスクライブして通知イベントを追加し、ユーザー (またはポリシー) の検証後に一致するフィルターを追加できます。

関連トピック

フィルターの重みの割り当て