A PART OF ANTI-VIRUS 3 - 公開サンプルコードで学ぶ Windows Filtering Platform (WFP) - (WEB 版) 【1 章 WFP の概要とアーキテクチャ】

本章では、WFP の概要と基本的なアーキテクチャについて解説します。

WFP は、Windows におけるエンドポイントセキュリティ、特にネットワーク通信の監視や制御を語る上では避けて通ることのできない仕組みです。

WFP は OS 標準の Microsoft Defender ファイアウォールだけでなく、 Antivirus や EDR などのエンドポイントセキュリティ製品など、様々な用途で利用されています。

この章では、2 章以降で WFP を利用したツールやドライバーを作成するための土台として、WFP がなぜセキュリティ製品に利用されるのか、またその全体像や構成要素がどのように連携してパケットを処理しているのかをできるだけシンプルに解説します。

WFP とは

WFP の概要

WFP は Windows Vista および Windows Server 2008 以降でネットワークフィルタリングアプリケーションを作成するためのプラットフォームを提供する一連の API とシステムサービスです。

WFP は IPv4/IPv6 をサポートしており、データのフィルタリングや変更、再挿入 (re-injection) やパケットとストリームの両方の処理を可能としています。さらに、システムブート時に Base Filtering Engine (BFE) が起動するまでの間のセキュリティの提供や、IPsec で暗号化される前と暗号化後の両方のデータの処理などを実現できます。¹

WFP を使用することで、開発者やアプリケーションベンダーは Windows 用のファイアウォールや侵入検知システム (IDS/IPS)、また Antivirus やネットワーク監視ツールなど、様々なソフトウェアを実装できます。

例えば、Windows に既定で搭載されている Microsoft Defender ファイアウォールも、この WFP を利用してステートフルファイアウォールや様々な条件に基づく通信のフィルタリングを実現しています。²

実際に WFP Explorer などのツールを用いてシステム内に登録されている WFP フィルターを確認すると、ファイアウォール以外にも Antivirus や VPN ソフトなど、様々なアプリケーションが WFP を利用していることを確認できます。

このようなネットワークフィルタリングアプリケーションを作成するためのプラットフォームとして提供される WFP には、 Windows のネットワークスタック内のすべてのレベルでネットワークトラフィックを監視、受信、処理するためのプラットフォームが含まれています。

以下の図は WFP の様々なコンポーネントのアーキテクチャを示したものです。³

このアーキテクチャ図に記載されている通り、WFP は大きく分けて以下のコンポーネントにより構成されています。各コンポーネントの詳細については後述します。

フィルターエンジン (Filter Engine)
Base Filtering Engine (BFE)
Shim
Callout ドライバー

Windows ネットワークスタックにおける WFP

以下の図は、「インサイド Windows 第 6 版上」から引用した Windows ネットワークコンポーネントの概要を表したものです。(本書執筆時点で最新の「インサイド Windows 第 7 版」では、ネットワークの章が削除されているため第 6 版を参照しています。)⁴

この図からも、WFP は Windows のネットワークスタック内の様々なレベルで処理を行うことがわかります。

WFP では、フィルターエンジンによりネットワーク上のフィルタリング操作を行います。フィルターエンジンは複数のフィルタリングレイヤー (Layer) を持ち、ネットワークスタック上の要所で Shim から渡される通信 (パケット/ストリーム/イベント) を、レイヤーに登録されたフィルター群と照合して最終的なアクションを決定します。

エンドポイントセキュリティにおける WFP の利用

ネットワーク通信は、一般に不正な URL へのアクセスやマルウェアのダウンロード、またはリモートログオン試行やネットワークにポートが解放されているサービスに対する侵害など、悪意のある攻撃者による端末の侵入の起点として利用されます。

また、万が一端末が侵害されて組織内のネットワークに侵入された場合には、侵害された端末を足掛かりとして組織ネットワーク内の情報収集や、外部からの遠隔操作コマンドの受信、さらには「ラテラルムーブメント (横展開/水平移動)」と呼ばれる侵害範囲の拡大や、外部への機密情報の漏洩など、一連の攻撃の中の様々なタイミングでネットワーク通信が利用されます。

そのため、ネットワーク通信のモニタリングはセキュリティの観点で極めて重要なポイントの 1 つとなっています。

しかし、いわゆる NIDS (Network Intrusion Detection System) と呼ばれるような侵入検知システムを導入するためには、監視対象のネットワーク経路上に、通信のモニタリングが可能な機器を配置する必要があります。

※ ここで記載している NIDS は、Windows の Network Driver Interface Specification (NDIS) ⁵ とは異なります。

この特性により、NIDS は組織ネットワークとインターネットの境界などの通信を効果的に監視できる一方で、ネットワーク内のすべての端末間にネットワーク機器を配置することは運用やコストなどの面から実現が困難な場合が多く、組織ネットワーク内の各エンドポイント (端末) 間の通信の監視を行うことはできません。

また、仮に組織内の各ネットワークセグメントにネットワーク機器を配置するなどの集約型の構成とすることでエンドポイント間の通信をある程度効果的にモニタリングできるようにした場合でも、いくつかのセキュリティ上の課題が残ります。

そのうちの 1 つは、現在行われる主要なネットワーク通信のほとんどが TLS によって暗号化されている点です。

TLS により通信が暗号化されている場合、ネットワーク経路上に配置された機器はモニタリング対象のネットワーク通信データを参照することができないため、通信内容に基づく監視やブロックを行う場合には一般に TLS インスペクションなどと呼ばれる Man-in-the-Middle (MiTM) による通信の復号と再暗号化が必要となります。

また 2 点目の課題として、通信経路上のネットワーク機器で収集した情報には端末内でその通信を開始したプロセス(アプリケーション)に関する情報が含まれていない点が挙げられます。

そのため、ネットワーク機器ベースのモニタリングでは、通信を開始したプロセスに関する情報を記録することができず、アプリケーションのコンテキストによる分析や調査を行うことが困難です。

他にも、ネットワーク機器ベースのモニタリングには、ネットワーク機器を経由しない方法で端末間の接続が行われた場合や、リモートワークなどにより、組織のネットワーク以外のネットワークに端末が接続している場合のモニタリングが不可能となるような課題も存在します。

ネットワーク機器ベースの NIDS について上記のような課題が存在していることなどを背景とし、エンドポイントベースのネットワークモニタリングがエンドポイントセキュリティ対策の 1 つとして重要視されています。

エンドポイントベースのネットワークモニタリングとは、通信経路上のネットワーク機器ではなく、端末内で稼働するサービスにより、端末が送受信するネットワーク通信の分析や監視を行うものです。

ネットワーク機器ベースのものと比較して、エンドポイントベースのネットワークモニタリングには一般に以下のような利点があります。

端末内で暗号化前、もしくは復号後のパケットデータを分析することができる
アプリケーションのコンテキストを使用した通信のフィルタリングや監視を行うことができる
端末が接続しているネットワークや通信経路に依存せず、端末の通信をモニタリングすることができる

このようなエンドポイントベースのネットワークモニタリングの機能は Antivirus や EDR、その他のネットワーク監視製品などの様々なソフトウェアにて提供されています。

そして、これらのソフトウェアが Windows でエンドポイントベースのネットワークモニタリングを実現するために使用する主要なプラットフォームが、本書で解説する WFP です。

WFP のアーキテクチャ

この項では、WFP によるネットワーク通信のフィルタリングや監視を行う仕組みについて解説します。

以下の図は、Microsoft の公開ドキュメントに記載されている WFP の関連コンポーネントのアーキテクチャを示したものです。

前述した通り、WFP は大きく分けて以下のコンポーネントにより構成されています。

フィルターエンジン (Filter Engine)
Base Filtering Engine (BFE)
Shim
Callout ドライバー

フィルターエンジン (Filter Engine)

WFP のフィルターエンジンはネットワークデータのフィルタリングなどを行うためのコンポーネントであり、ユーザーモードとカーネルモードの両方にそれぞれ存在しています。(アーキテクチャ図の UM Filter Engine と KM Filter Engine)

フィルターエンジンには Windows のネットワークスタックレイヤーにマッピングされた複数のフィルタリングレイヤーが含まれています。

特に、本書で扱うセキュリティのコンテキストで重要となる TCP/IP スタックのネットワーク層とトランスポート層でのフィルター処理や Callout 関数の呼び出しについてはカーネルモード側のコンポーネントが担っています。⁶

フィルタリングレイヤーとサブレイヤー

フィルタリングレイヤー (レイヤー) は、前述したフィルターエンジンにより管理されるコンテナーであり、フィルターをセットとして整理する機能を持っています。⁷

内部的に設定された GUID で管理される各レイヤーには、レイヤーごとに追加できるフィルターの種類が定義されています。⁸

また、各レイヤーはサブレイヤーに分割され、サブレイヤーの優先順位 (weight) に従って評価されます。サブレイヤーはシステムに既定で組み込まれているものに加えて、開発者が独自に追加/定義することも可能です。

フィルター

フィルターは、受信もしくは送信されるパケット/ストリーム/イベントなどと照合されるルールであり、条件に合致する通信のブロックや、Callout 関数の呼び出しなど、パケットをどのように扱うかをフィルターエンジンに指示します。

Base Filtering Engine (BFE)

Base Filtering Engine (BFE) とは、WFP コンポーネント間の調整を行うユーザーモードサービスです。

BFE は WFP のユーザーモード API を実装しており、プラットフォームの管理やカーネルモード側のコンポーネントとの通信を行います。⁹

BFE の主要なタスクは、システムへのフィルターの追加と削除、フィルター構成の保存、および WFP 構成セキュリティの強制です。¹⁰

詳しくは 2 章以降で解説しますが、アプリケーションは WFP の API を利用して BFE にフィルターの登録などの操作を要求します。

Shim

Shim は、1 つまたは複数のフィルタリングレイヤーに対して「Classifying (分類)」を行うカーネルコンポーネントです。¹¹

Shim はネットワークスタックとフィルターエンジンの中間に位置しており、パケットやストリーム、およびイベントがネットワークスタックを通過する際、Shim はこれらを解析して分類可能な条件や値を抽出した後、フィルターエンジンを呼び出して特定のレイヤー内のフィルターと照合します。

そして、その照合結果を元に、対応するネットワークスタックで特定のネットワークトラフィックを許可もしくはブロックします。

Shim は端的に言うと、WFP のフィルターエンジンに対して Windows のネットワークスタックを通過するパケットの可視性を提供するコンポーネントです。

以下は、ネットワークスタックを通過するパケットについて、対応する Shim が WFP フィルターの照合結果を元にアクションを決定する流れをまとめたものです。¹²

パケットがネットワークスタックに入ります。
ネットワークスタックは、適切な Shim を特定し、呼び出します。
Shim は、特定のレイヤーにおいて「Classifying (分類)」プロセスを呼び出します。
分類プロセス中に登録されているフィルターの照合が行われ、その結果に応じたアクションが決定されます。
分類プロセスで Callout フィルターに一致した場合、対応する Callout 関数が呼び出されます。
Shim は、最終的なフィルタリング決定に基づいてパケットの Drop などの操作を行います。

Callout ドライバー

Callout ドライバーは、カーネルモードのフィルタリングレイヤーにおいて、フィルターエンジンに独自の Callout 関数を登録することで、WFP のフィルタリング機能を拡張します。¹³

WFP の Callout はパケットの詳細分析や改変などをサポートしており、 Antivirus などのセキュリティソフトウェアでも利用されます。

フィルタリングレイヤーとフィルター

フィルタリングレイヤー (レイヤー) は、フィルターエンジンにより管理されるコンテナーであり、フィルターをセットとして整理する機能を持っています。また、内部的に設定された GUID で管理される各レイヤーには、レイヤーごとに追加できるフィルターの種類が定義されています。

フィルタリングレイヤーは対応するネットワークスタックに応じて複数存在しています。

以下は、WFP の主要なフィルタリングレイヤーの例です。

Inbound/Outbound ALE レイヤー
Stream/Datagram レイヤー
Inbound/Outbound Transport レイヤー
Inbound/Outbound IP レイヤー

例えば端末から IPv4 を使用して TCP 接続を行う場合は、まずアウトバウンドの ALE レイヤー (FWPM_LAYER_ALE_AUTH_CONNECT_V4) によって TCP 接続要求が検査されます。¹⁴ (ALE レイヤーはアプリケーションのコンテキストでのフィルタリングをサポートしており、エンドポイントセキュリティ用途でのフィルタリングにおいて非常に重要なレイヤーです。)

TCP 接続要求が ALE レイヤーを通過した場合、SYN パケットがアウトバウンドの Transport レイヤー (FWPM_LAYER_OUTBOUND_TRANSPORT_V4) とアウトバウンドの IP レイヤー (FWPM_LAYER_OUTBOUND_IPPACKET_V4) の順に検査された後に送信されます。¹⁵

また、TCP 接続完了後に送信されるデータについては、Stream レイヤー(FWPM_LAYER_STREAM_V4) や、アウトバウンドの Transport、IP レイヤーなどで検査されます。

開発者は、その目的や用途に合わせて、適切なフィルタリングレイヤーにフィルターを登録できます。

しかし、フィルターは様々なアプリケーションが追加することが可能なコンポーネントであるため、特定の通信に対して競合する処理 (許可またはブロック) を行うことを指定したフィルターが同時に適用される状況が発生する場合があります。

そのため、WFP では最終的な判定を決定する「Filter Arbitration (フィルター調停)」のロジックが定められています。¹⁶

Filter Arbitration が最終的な判定を行う上で特に重要な要素は以下です。

各フィルタリングレイヤーに割り当てられたサブレイヤーの優先順位 (Weight とも呼ばれます)
各サブレイヤーに割り当てられたフィルターが定義した処理(許可/ブロックなど)
各サブレイヤーに割り当てられたフィルターの優先順位 (Weight)
オーバライドの許可設定 (FWPS_RIGHT_ACTION_WRITE など) の有無

本書では Filter Arbitration のロジックにより通信が許可もしくはブロックされる細かいパターンについては扱いませんが、特定のフィルタリングレイヤーにおける判定ロジックは基本的には以下のように判定されます。

レイヤーはサブレイヤーに分割され、ネットワークトラフィックはサブレイヤーの優先順位 (Weight) が高い順に評価されます。
各サブレイヤー内では、条件に一致するフィルターが Weight の高い順に評価されます。
サブレイヤー内で一致したフィルターを評価していき、“Permit” または “Block” が返された時点でそのサブレイヤー内の残りのフィルター評価はスキップされ、最後に評価されたフィルターのアクションがそのサブレイヤーの結果になります。(フィルターが “Continue” を返す場合もあります。)
レイヤー全体としては、サブレイヤーごとの結果を集約して最終的なアクションを決定します。
オーバーライド可否はフィルターごとに制御でき、FWPS_RIGHT_ACTION_WRITE や FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT により、“soft/hard” な許可もしくはブロックを行います。例えば “soft block” は他のサブレイヤーの許可アクションに上書きされる可能性がありますが、“hard block” は別のサブレイヤーで許可することが不可能であり、ブロックが最終的な判定結果となります。¹⁷

以下は、Microsoft の公開ドキュメント¹⁸から引用した Filter Arbitration ロジックのイメージ図です。

各レイヤー内のボックスはそれぞれサブレイヤーを表しており、ALE のレイヤー内ですべてのサブレイヤーが評価された結果、サブレイヤーとしての優先順位は FW1 (Firewall 1) より低い FW2 (Firewall 2) のブロックアクションが最終的な判定結果に利用されることを示しています。

WFP フィルターの情報を確認する方法

この項では、実際にシステムに登録されている WFP のコンポーネントの情報や、通信のフィルタリング状況を確認する方法を解説します。

WFP Explorer を使用する

システムに登録されている WFP コンポーネントを参照するために最も効果的な方法の 1 つは、WFP Explorer を使用することです。

WFP Explorer は、インサイド Windows 第 7 版の著者でもある Pavel Yosifovich 氏が公開している GUI ツールであり、以下のリポジトリからダウンロードすることができます。

WFP Explorer

https://github.com/zodiacon/AllTools/blob/master/WFPExp.exe

WFP Explorer を使用すると、システムに登録されているプロバイダーやフィルターなどの様々な情報を GUI 上で直感的に一覧参照することができます。(アプリケーションがフィルター等を登録する際に指定しているセキュリティディスクリプタによっては、WFP Explorer のようなツールや netsh コマンドの出力結果に表示されない場合があります。)

これらの情報は後述する netsh wfp コマンドを使用した方法でも参照可能ですが、素早くフィルターなどの情報を確認する場合には WFP Explorer の方が適しています。

netsh wfp コマンドを使用する

netsh wfp コマンドは、WFP の管理とトラブルシューティングのために提供されているツールです。¹⁹

netsh wfp コマンドには様々なオプションがありますが、本書で特に使用するコマンドを以下にまとめます。

netsh wfp show state

以下のコマンドは WFP と IPsec の現在の状態をファイルに出力します。

netsh wfp show state file=- のようにファイルパスの部分を - に置き換えることで、コンソール上に結果を出力することも可能ですが、データ量が多いので通常はファイルとして保存して確認します。

netsh wfp show state file=%USERPROFILE%\Downloads\wfpstate.xml

このコマンドで出力した XML は以下のような要素で構成されており、プロバイダーやサブレイヤーなどの情報を確認できます。

netsh wfp show filters

以下のコマンドは、指定の条件を含むフィルターの情報を出力するためのコマンドです。

netsh wfp show filters verbose=ON file=%USERPROFILE%\Downloads\wfpfilters.xml

条件には、プロトコルやローカル/リモートアドレスやポート番号、またはアプリケーションのパスやユーザーの SID、トラフィックの方向などを指定できます。

例えば、トラフィックの送受信を行っているアプリケーションのパスを条件としたい場合は、以下の例のように appid に対象のアプリケーションのフルパスを指定します。

netsh wfp show filters verbose=OFF file=%USERPROFILE%\Downloads\wfpfilters.xml appid="C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"

netsh wfp show netevents

以下は、直近のネットワークイベントを出力するためのコマンドです。

WFP フィルターによるネットワークトラフィックのフィルタリング結果などを確認できます。

netsh wfp show netevents file=%USERPROFILE%\Downloads\wfpnetevents.xml

netevents の場合も、プロトコルやローカル/リモートアドレスやポート番号、またはアプリケーションのパスやユーザーの SID などを条件として指定できます。

netsh wfp capture

以下のコマンドは、WFP によって処理されるネットワークイベントのキャプチャセッションを開始するコマンドです。

netsh wfp capture start コマンドを実行してキャプチャセッションを開始後、 netsh wfp capture stop コマンドを実行するまでのイベントをキャプチャできます。

netsh wfp capture start cab=off file=%USERPROFILE%\Downloads\wfpdiag

netsh wfp capture stop

このコマンドを実行した結果生成される wfpdiag.xml からネットワークイベントを確認することができます。

以下は wfpdiag.xml に含まれるドロップイベントの抜粋です。

<netEvent>
   <header>
   	<timeStamp>2026-02-11T01:28:57.540Z</timeStamp>
   	<ipVersion>FWP_IP_VERSION_V4</ipVersion>
   	<ipProtocol>6</ipProtocol>
   	<localAddrV4>192.168.52.236</localAddrV4>
   	<remoteAddrV4>8.8.8.8</remoteAddrV4>
   	<localPort>50685</localPort>
   	<remotePort>80</remotePort>
   	<appId>
   		<asString>\.d.e.v.i.c.e.\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.3.\.p.r.o.g.r.a.m. .f.i.l.e.s. .(.x.8.6.).\.m.i.c.r.o.s.o.f.t.\.e.d.g.e.\.a.p.p.l.i.c.a.t.i.o.n.\.m.s.e.d.g.e...e.x.e...</asString>
   	</appId>
   	</header>
   <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
   <classifyDrop>
   	<filterId>71422</filterId>
   	<layerId>48</layerId>
   </classifyDrop>
   <internalFields>
   	<terminatingFiltersInfo numItems="2">
   		<item>
   			<filterId>71422</filterId>
   			<subLayer>32768</subLayer>
   			<actionType>FWP_ACTION_BLOCK</actionType>
   		</item>
   		<item>
   			<filterId>69913</filterId>
   			<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_WF</subLayer>
   			<actionType>FWP_ACTION_PERMIT</actionType>
   		</item>
   	</terminatingFiltersInfo>
   	<policyAppId/>
   </internalFields>
</netEvent>

このイベントからは、msedge.exe による 8.8.8.8 の 80 番ポート宛ての通信が FWPM_NET_EVENT_TYPE_CLASSIFY_DROP の通りドロップされたことを示しており、フィルター ID 71422 のフィルターにより FWP_ACTION_BLOCK によりブロックの評価が行われたことがわかります。

また、netsh wfp show state などで出力した情報と組み合わせることで、 layerId が 48 であるレイヤー (FWPM_LAYER_ALE_AUTH_CONNECT_V4) にて、 filterId が 71422 のフィルター (Block Edge) により通信のブロック判定が行われたことなども確認できます。

まとめ

本章では、WFP が Windows のネットワークスタックに組み込まれたフィルタリングプラットフォームであり、Microsoft Defender ファイアウォールや Antivirus または EDR などの実装に広く利用されていることを確認しました。

また、WFP の主要コンポーネントであるフィルターエンジン、BFE、Shim、Callout ドライバーの役割と、フィルタリングレイヤー/サブレイヤー/フィルターの関係を整理するとともに、サブレイヤーやフィルターの優先順位、オーバーライド可否に基づいて最終的な許可/ブロック判定が決定される動作について解説しました。

次章では、ユーザーモードから WFP フィルターを利用してトラフィックのフィルタリングを行うサンプルコードの解説を行います。

本書のもくじ

WFP Features https://learn.microsoft.com/ja-jp/windows/win32/fwp/about-windows-filtering-platform#wfp-features
↩
インサイド Windows 第 6 版上 P.736 ( Mark E. Russinovich, David A. Solomon, Alex Inescu 著 / 株式会社クイープ訳 / 日経BP社 / 2012 年)
↩
WFP Architecture https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview
↩
インサイド Windows 第 6 版上 P.653 ( Mark E. Russinovich, David A. Solomon, Alex Inescu 著 / 株式会社クイープ訳 / 日経BP社 / 2012 年)
↩
Overview of NDIS driver types https://learn.microsoft.com/ja-jp/windows-hardware/drivers/network/ndis-drivers
↩
Filter Engine https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#filter-engine
↩
WFP Operation https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation
↩
Filtering conditions available at each filtering layer https://learn.microsoft.com/ja-jp/windows/win32/fwp/filtering-conditions-available-at-each-filtering-layer
↩
Windows Kernel Programming, Second Edition P.472 (Pavel Yosifovich 著 / Independently published / 2023 年)
↩
Base Filtering Engine https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#base-filtering-engine
↩
Shims https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation#shims
↩
WFP Operation https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation#wfp-operation-1
↩
Callout Drivers https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#callout-drivers
↩
Packet Inspection Points https://learn.microsoft.com/ja-jp/windows-hardware/drivers/network/packet-inspection-points
↩
TCP Packet Flows https://learn.microsoft.com/ja-jp/windows/win32/fwp/tcp-packet-flows
↩
Filter Arbitration https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration
↩
Configurable Override Policy https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration#configurable-override-policy
↩
Filter Arbitration https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration
↩
netsh wfp https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/netsh-wfp
↩

Published Apr 11, 2026

Aspiring Reverse Engineer and CTF Player (Team: 0nePadding). Passionate about WinDbg and Anti-Virus internals. OSCP / CISSP. Working at Microsoft Japan, but all views expressed are my own.かしわば(@kash1064) on Twitter