本章では、WFP の概要と基本的なアーキテクチャについて解説します。
\nWFP は、Windows におけるエンドポイントセキュリティ、\n特にネットワーク通信の監視や制御を語る上では避けて通ることのできない仕組みです。
\nWFP は OS 標準の Microsoft Defender ファイアウォールだけでなく、\nAntivirus や EDR などのエンドポイントセキュリティ製品など、様々な用途で利用されています。
\nこの章では、2 章以降で WFP を利用したツールやドライバーを作成するための土台として、WFP がなぜセキュリティ製品に利用されるのか、\nまたその全体像や構成要素がどのように連携してパケットを処理しているのかをできるだけシンプルに解説します。
\nWFP は Windows Vista および Windows Server 2008 以降で\nネットワークフィルタリングアプリケーションを作成するためのプラットフォームを提供する一連の API とシステムサービスです。
\nWFP は IPv4/IPv6 をサポートしており、データのフィルタリングや変更、再挿入 (re-injection) やパケットとストリームの両方の処理を可能としています。\nさらに、システムブート時に Base Filtering Engine (BFE) が起動するまでの間のセキュリティの提供や、IPsec で暗号化される前と暗号化後の両方のデータの処理などを実現できます。1
\nWFP を使用することで、開発者やアプリケーションベンダーは Windows 用のファイアウォールや侵入検知システム (IDS/IPS)、\nまた Antivirus やネットワーク監視ツールなど、様々なソフトウェアを実装できます。
\n例えば、Windows に既定で搭載されている Microsoft Defender ファイアウォールも、\nこの WFP を利用してステートフルファイアウォールや様々な条件に基づく通信のフィルタリングを実現しています。2
\n実際に WFP Explorer などのツールを用いてシステム内に登録されている WFP フィルターを確認すると、\nファイアウォール以外にも Antivirus や VPN ソフトなど、様々なアプリケーションが WFP を利用していることを確認できます。
\nこのようなネットワークフィルタリングアプリケーションを作成するためのプラットフォームとして提供される WFP には、\nWindows のネットワークスタック内のすべてのレベルでネットワークトラフィックを監視、受信、処理するためのプラットフォームが含まれています。
\n以下の図は WFP の様々なコンポーネントのアーキテクチャを示したものです。3
\nこのアーキテクチャ図に記載されている通り、WFP は大きく分けて以下のコンポーネントにより構成されています。\n各コンポーネントの詳細については後述します。
\n以下の図は、「インサイド Windows 第 6 版 上」から引用した Windows ネットワークコンポーネントの概要を表したものです。(本書執筆時点で最新の「インサイド Windows 第 7 版」では、ネットワークの章が削除されているため第 6 版を参照しています。)4
\nこの図からも、WFP は Windows のネットワークスタック内の様々なレベルで処理を行うことがわかります。
\nWFP では、フィルターエンジンによりネットワーク上のフィルタリング操作を行います。\nフィルターエンジンは複数のフィルタリングレイヤー (Layer) を持ち、ネットワークスタック上の要所で Shim から渡される通信 (パケット/ストリーム/イベント) を、レイヤーに登録されたフィルター群と照合して最終的なアクションを決定します。
\nネットワーク通信は、一般に不正な URL へのアクセスやマルウェアのダウンロード、\nまたはリモートログオン試行やネットワークにポートが解放されているサービスに対する侵害など、\n悪意のある攻撃者による端末の侵入の起点として利用されます。
\nまた、万が一端末が侵害されて組織内のネットワークに侵入された場合には、\n侵害された端末を足掛かりとして組織ネットワーク内の情報収集や、外部からの遠隔操作コマンドの受信、\nさらには「ラテラルムーブメント (横展開/水平移動)」と呼ばれる侵害範囲の拡大や、外部への機密情報の漏洩など、\n一連の攻撃の中の様々なタイミングでネットワーク通信が利用されます。
\nそのため、ネットワーク通信のモニタリングはセキュリティの観点で極めて重要なポイントの 1 つとなっています。
\nしかし、いわゆる NIDS (Network Intrusion Detection System) と呼ばれるような侵入検知システムを導入するためには、\n監視対象のネットワーク経路上に、通信のモニタリングが可能な機器を配置する必要があります。
\n※ ここで記載している NIDS は、Windows の Network Driver Interface Specification (NDIS) 5 とは異なります。
\nこの特性により、NIDS は組織ネットワークとインターネットの境界などの通信を効果的に監視できる一方で、\nネットワーク内のすべての端末間にネットワーク機器を配置することは運用やコストなどの面から実現が困難な場合が多く、\n組織ネットワーク内の各エンドポイント (端末) 間の通信の監視を行うことはできません。
\nまた、仮に組織内の各ネットワークセグメントにネットワーク機器を配置するなどの集約型の構成とすることで\nエンドポイント間の通信をある程度効果的にモニタリングできるようにした場合でも、いくつかのセキュリティ上の課題が残ります。
\nそのうちの 1 つは、現在行われる主要なネットワーク通信のほとんどが TLS によって暗号化されている点です。
\nTLS により通信が暗号化されている場合、ネットワーク経路上に配置された機器はモニタリング対象のネットワーク通信データを参照することができないため、\n通信内容に基づく監視やブロックを行う場合には一般に TLS インスペクションなどと呼ばれる Man-in-the-Middle (MiTM) による通信の復号と再暗号化が必要となります。
\nまた 2 点目の課題として、通信経路上のネットワーク機器で収集した情報には\n端末内でその通信を開始したプロセス(アプリケーション)に関する情報が含まれていない点が挙げられます。
\nそのため、ネットワーク機器ベースのモニタリングでは、通信を開始したプロセスに関する情報を記録することができず、\nアプリケーションのコンテキストによる分析や調査を行うことが困難です。
\n他にも、ネットワーク機器ベースのモニタリングには、ネットワーク機器を経由しない方法で端末間の接続が行われた場合や、\nリモートワークなどにより、組織のネットワーク以外のネットワークに端末が接続している場合のモニタリングが不可能となるような課題も存在します。
\nネットワーク機器ベースの NIDS について上記のような課題が存在していることなどを背景とし、\nエンドポイントベースのネットワークモニタリングがエンドポイントセキュリティ対策の 1 つとして重要視されています。
\nエンドポイントベースのネットワークモニタリングとは、通信経路上のネットワーク機器ではなく、\n端末内で稼働するサービスにより、端末が送受信するネットワーク通信の分析や監視を行うものです。
\nネットワーク機器ベースのものと比較して、エンドポイントベースのネットワークモニタリングには一般に以下のような利点があります。
\nこのようなエンドポイントベースのネットワークモニタリングの機能は Antivirus や EDR、その他のネットワーク監視製品などの様々なソフトウェアにて提供されています。
\nそして、これらのソフトウェアが Windows でエンドポイントベースのネットワークモニタリングを\n実現するために使用する主要なプラットフォームが、本書で解説する WFP です。
\nこの項では、WFP によるネットワーク通信のフィルタリングや監視を行う仕組みについて解説します。
\n以下の図は、Microsoft の公開ドキュメントに記載されている WFP の関連コンポーネントのアーキテクチャを示したものです。
\n前述した通り、WFP は大きく分けて以下のコンポーネントにより構成されています。
\nWFP のフィルターエンジンはネットワークデータのフィルタリングなどを行うためのコンポーネントであり、ユーザーモードとカーネルモードの両方にそれぞれ存在しています。(アーキテクチャ図の UM Filter Engine と KM Filter Engine)
\nフィルターエンジンには Windows のネットワークスタックレイヤーにマッピングされた複数のフィルタリングレイヤーが含まれています。
\n特に、本書で扱うセキュリティのコンテキストで重要となる TCP/IP スタックのネットワーク層とトランスポート層でのフィルター処理や Callout 関数の呼び出しについてはカーネルモード側のコンポーネントが担っています。6
\nフィルタリングレイヤー (レイヤー) は、前述したフィルターエンジンにより管理されるコンテナーであり、フィルターをセットとして整理する機能を持っています。7
\n内部的に設定された GUID で管理される各レイヤーには、レイヤーごとに追加できるフィルターの種類が定義されています。8
\nまた、各レイヤーはサブレイヤーに分割され、サブレイヤーの優先順位 (weight) に従って評価されます。\nサブレイヤーはシステムに既定で組み込まれているものに加えて、開発者が独自に追加/定義することも可能です。
\nフィルターは、受信もしくは送信されるパケット/ストリーム/イベントなどと照合されるルールであり、\n条件に合致する通信のブロックや、Callout 関数の呼び出しなど、\nパケットをどのように扱うかをフィルターエンジンに指示します。
\nBase Filtering Engine (BFE) とは、WFP コンポーネント間の調整を行うユーザーモードサービスです。
\nBFE は WFP のユーザーモード API を実装しており、プラットフォームの管理やカーネルモード側のコンポーネントとの通信を行います。9
\nBFE の主要なタスクは、システムへのフィルターの追加と削除、フィルター構成の保存、および WFP 構成セキュリティの強制です。10
\n詳しくは 2 章以降で解説しますが、アプリケーションは WFP の API を利用して BFE にフィルターの登録などの操作を要求します。
\nShim は、1 つまたは複数のフィルタリングレイヤーに対して「Classifying (分類)」を行うカーネルコンポーネントです。11
\nShim はネットワークスタックとフィルターエンジンの中間に位置しており、パケットやストリーム、およびイベントがネットワークスタックを通過する際、Shim はこれらを解析して分類可能な条件や値を抽出した後、フィルターエンジンを呼び出して特定のレイヤー内のフィルターと照合します。
\nそして、その照合結果を元に、対応するネットワークスタックで特定のネットワークトラフィックを許可もしくはブロックします。
\nShim は端的に言うと、WFP のフィルターエンジンに対して Windows のネットワークスタックを通過するパケットの可視性を提供するコンポーネントです。
\n以下は、ネットワークスタックを通過するパケットについて、対応する Shim が WFP フィルターの照合結果を元にアクションを決定する流れをまとめたものです。12
\nCallout ドライバーは、カーネルモードのフィルタリングレイヤーにおいて、\nフィルターエンジンに独自の Callout 関数を登録することで、WFP のフィルタリング機能を拡張します。13
\nWFP の Callout はパケットの詳細分析や改変などをサポートしており、\nAntivirus などのセキュリティソフトウェアでも利用されます。
\nフィルタリングレイヤー (レイヤー) は、フィルターエンジンにより管理されるコンテナーであり、\nフィルターをセットとして整理する機能を持っています。\nまた、内部的に設定された GUID で管理される各レイヤーには、レイヤーごとに追加できるフィルターの種類が定義されています。
\nフィルタリングレイヤーは対応するネットワークスタックに応じて複数存在しています。
\n以下は、WFP の主要なフィルタリングレイヤーの例です。
\n例えば端末から IPv4 を使用して TCP 接続を行う場合は、まずアウトバウンドの ALE レイヤー (FWPM_LAYER_ALE_AUTH_CONNECT_V4) によって TCP 接続要求が検査されます。14\n(ALE レイヤーはアプリケーションのコンテキストでのフィルタリングをサポートしており、エンドポイントセキュリティ用途でのフィルタリングにおいて非常に重要なレイヤーです。)
TCP 接続要求が ALE レイヤーを通過した場合、SYN パケットがアウトバウンドの Transport レイヤー (FWPM_LAYER_OUTBOUND_TRANSPORT_V4) とアウトバウンドの IP レイヤー (FWPM_LAYER_OUTBOUND_IPPACKET_V4) の順に検査された後に送信されます。15
また、TCP 接続完了後に送信されるデータについては、Stream レイヤー(FWPM_LAYER_STREAM_V4) や、\nアウトバウンドの Transport、IP レイヤーなどで検査されます。
開発者は、その目的や用途に合わせて、適切なフィルタリングレイヤーにフィルターを登録できます。
\nしかし、フィルターは様々なアプリケーションが追加することが可能なコンポーネントであるため、\n特定の通信に対して競合する処理 (許可またはブロック) を行うことを指定したフィルターが同時に適用される状況が発生する場合があります。
\nそのため、WFP では最終的な判定を決定する「Filter Arbitration (フィルター調停)」のロジックが定められています。16
\nFilter Arbitration が最終的な判定を行う上で特に重要な要素は以下です。
\nFWPS_RIGHT_ACTION_WRITE など) の有無本書では Filter Arbitration のロジックにより通信が許可もしくはブロックされる細かいパターンについては扱いませんが、\n特定のフィルタリングレイヤーにおける判定ロジックは基本的には以下のように判定されます。
\nFWPS_RIGHT_ACTION_WRITE や FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT により、“soft/hard” な許可もしくはブロックを行います。\n例えば “soft block” は他のサブレイヤーの許可アクションに上書きされる可能性がありますが、“hard block” は別のサブレイヤーで許可することが不可能であり、ブロックが最終的な判定結果となります。17以下は、Microsoft の公開ドキュメント18から引用した Filter Arbitration ロジックのイメージ図です。
\n各レイヤー内のボックスはそれぞれサブレイヤーを表しており、ALE のレイヤー内ですべてのサブレイヤーが評価された結果、\nサブレイヤーとしての優先順位は FW1 (Firewall 1) より低い FW2 (Firewall 2) のブロックアクションが最終的な判定結果に利用されることを示しています。
\nこの項では、実際にシステムに登録されている WFP のコンポーネントの情報や、\n通信のフィルタリング状況を確認する方法を解説します。
\nシステムに登録されている WFP コンポーネントを参照するために最も効果的な方法の 1 つは、WFP Explorer を使用することです。
\nWFP Explorer は、インサイド Windows 第 7 版の著者でもある Pavel Yosifovich 氏が公開している GUI ツールであり、\n以下のリポジトリからダウンロードすることができます。
\nWFP Explorer
\nhttps://github.com/zodiacon/AllTools/blob/master/WFPExp.exe
\nWFP Explorer を使用すると、システムに登録されているプロバイダーやフィルターなどの様々な情報を GUI 上で直感的に一覧参照することができます。(アプリケーションがフィルター等を登録する際に指定しているセキュリティディスクリプタによっては、WFP Explorer のようなツールや netsh コマンドの出力結果に表示されない場合があります。)
\n以下のコマンドは、指定の条件を含むフィルターの情報を出力するためのコマンドです。
\nnetsh wfp show filters verbose=ON file=%USERPROFILE%\\Downloads\\wfpfilters.xml条件には、プロトコルやローカル/リモートアドレスやポート番号、\nまたはアプリケーションのパスやユーザーの SID、トラフィックの方向などを指定できます。
\n例えば、トラフィックの送受信を行っているアプリケーションのパスを条件としたい場合は、\n以下の例のように appid に対象のアプリケーションのフルパスを指定します。
\nnetsh wfp show filters verbose=OFF file=%USERPROFILE%\\Downloads\\wfpfilters.xml appid=\"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe\"以下は、直近のネットワークイベントを出力するためのコマンドです。
\nWFP フィルターによるネットワークトラフィックのフィルタリング結果などを確認できます。
\nnetsh wfp show netevents file=%USERPROFILE%\\Downloads\\wfpnetevents.xmlnetevents の場合も、プロトコルやローカル/リモートアドレスやポート番号、\nまたはアプリケーションのパスやユーザーの SID などを条件として指定できます。
\n以下のコマンドは、WFP によって処理されるネットワークイベントのキャプチャセッションを開始するコマンドです。
\nnetsh wfp capture start コマンドを実行してキャプチャセッションを開始後、\nnetsh wfp capture stop コマンドを実行するまでのイベントをキャプチャできます。
netsh wfp capture start cab=off file=%USERPROFILE%\\Downloads\\wfpdiag\n\nnetsh wfp capture stopこのコマンドを実行した結果生成される wfpdiag.xml からネットワークイベントを確認することができます。
\n以下は wfpdiag.xml に含まれるドロップイベントの抜粋です。
\n<netEvent>\n <header>\n \t<timeStamp>2026-02-11T01:28:57.540Z</timeStamp>\n \t<ipVersion>FWP_IP_VERSION_V4</ipVersion>\n \t<ipProtocol>6</ipProtocol>\n \t<localAddrV4>192.168.52.236</localAddrV4>\n \t<remoteAddrV4>8.8.8.8</remoteAddrV4>\n \t<localPort>50685</localPort>\n \t<remotePort>80</remotePort>\n \t<appId>\n \t\t<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>\n \t</appId>\n \t</header>\n <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>\n <classifyDrop>\n \t<filterId>71422</filterId>\n \t<layerId>48</layerId>\n </classifyDrop>\n <internalFields>\n \t<terminatingFiltersInfo numItems=\"2\">\n \t\t<item>\n \t\t\t<filterId>71422</filterId>\n \t\t\t<subLayer>32768</subLayer>\n \t\t\t<actionType>FWP_ACTION_BLOCK</actionType>\n \t\t</item>\n \t\t<item>\n \t\t\t<filterId>69913</filterId>\n \t\t\t<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_WF</subLayer>\n \t\t\t<actionType>FWP_ACTION_PERMIT</actionType>\n \t\t</item>\n \t</terminatingFiltersInfo>\n \t<policyAppId/>\n </internalFields>\n</netEvent>このイベントからは、msedge.exe による 8.8.8.8 の 80 番ポート宛ての通信が\nFWPM_NET_EVENT_TYPE_CLASSIFY_DROP の通りドロップされたことを示しており、\nフィルター ID 71422 のフィルターにより FWP_ACTION_BLOCK によりブロックの評価が行われたことがわかります。
また、netsh wfp show state などで出力した情報と組み合わせることで、\nlayerId が 48 であるレイヤー (FWPM_LAYER_ALE_AUTH_CONNECT_V4) にて、\nfilterId が 71422 のフィルター (Block Edge) により通信のブロック判定が行われたことなども確認できます。
本章では、WFP が Windows のネットワークスタックに組み込まれたフィルタリングプラットフォームであり、Microsoft Defender ファイアウォールや Antivirus または EDR などの実装に広く利用されていることを確認しました。
\nまた、WFP の主要コンポーネントであるフィルターエンジン、BFE、Shim、Callout ドライバーの役割と、\nフィルタリングレイヤー/サブレイヤー/フィルターの関係を整理するとともに、\nサブレイヤーやフィルターの優先順位、オーバーライド可否に基づいて最終的な許可/ブロック判定が決定される動作について解説しました。
\n次章では、ユーザーモードから WFP フィルターを利用してトラフィックのフィルタリングを行うサンプルコードの解説を行います。
\nWFP Features https://learn.microsoft.com/ja-jp/windows/win32/fwp/about-windows-filtering-platform#wfp-features
\n↩\nインサイド Windows 第 6 版 上 P.736 ( Mark E. Russinovich, David A. Solomon, Alex Inescu 著 / 株式会社クイープ 訳 / 日経BP社 / 2012 年)
\n↩\nWFP Architecture https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview
\n↩\nインサイド Windows 第 6 版 上 P.653 ( Mark E. Russinovich, David A. Solomon, Alex Inescu 著 / 株式会社クイープ 訳 / 日経BP社 / 2012 年)
\n↩\nOverview of NDIS driver types https://learn.microsoft.com/ja-jp/windows-hardware/drivers/network/ndis-drivers
\n↩\nFilter Engine https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#filter-engine
\n↩\nWFP Operation https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation
\n↩\nFiltering conditions available at each filtering layer https://learn.microsoft.com/ja-jp/windows/win32/fwp/filtering-conditions-available-at-each-filtering-layer
\n↩\nWindows Kernel Programming, Second Edition P.472 (Pavel Yosifovich 著 / Independently published / 2023 年)
\n↩\nBase Filtering Engine https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#base-filtering-engine
\n↩\nShims https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation#shims
\n↩\nWFP Operation https://learn.microsoft.com/ja-jp/windows/win32/fwp/basic-operation#wfp-operation-1
\n↩\nCallout Drivers https://learn.microsoft.com/ja-jp/windows/win32/fwp/windows-filtering-platform-architecture-overview#callout-drivers
\n↩\nPacket Inspection Points https://learn.microsoft.com/ja-jp/windows-hardware/drivers/network/packet-inspection-points
\n↩\nTCP Packet Flows https://learn.microsoft.com/ja-jp/windows/win32/fwp/tcp-packet-flows
\n↩\nFilter Arbitration https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration
\n↩\nConfigurable Override Policy https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration#configurable-override-policy
\n↩\nFilter Arbitration https://learn.microsoft.com/ja-jp/windows/win32/fwp/filter-arbitration
\n↩\nnetsh wfp https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/netsh-wfp
\n↩\n