Windows Filtering Platform

Before jumping to the WFP drivers, we must understand how Windows handles networking. The Windows network stack is a layered architecture that follows a mix of the OSI model  and Windows-specific components

Key Layers in Windows Networking

Traditional Windows Filtering Mechanisms (Pre-WFP)

Before WFP, Windows used these older filtering methods:

1. Transport Driver Interface (TDI) Filters
   1. Purpose: Intercept network requests at the socket API level.
   2. Limitations:
      1. Only works for TCP/IP traffic.
      2. No awareness of applications or users.
      3. Deprecated since Windows  7.
2. NDIS Intermediate Drivers
   1. Purpose: Filter packets at the Network Interface level.
   2. Limitations:
      1. Too low-level (works on raw Ethernet frames)
      2. Difficult to implement application-aware filtering
3. Layered Service Providers (LSPs)
   1. Purpose: Hook into Winsock API to modify traffic.
   2. Limitations:
      1. User-mode only (easy for malware to bypass)
      2. Unstable and prone to crashes

Why WFP Replaces Them

1. Unified filtering framework (kernel + user-mode)
2. Application-aware (ALE layers track process IDs)
3. Stateful filtering (tracks connections, not just packets)
4. Better performance (optimized for modern networking)

WFP's Position in the Network Stack

WFP sits between the transport layer and network layer, allowing deep inspection and filtering.

How a Packet Flows through WFP

1. Application makes a network call (e.g., connect())
2. Winsock passes the request to the TCP/IP driver
3. WFP ALE Layers check if the connection is allowed
4. WFP Transport Layers inspect/modify packets
5. WFP Network Layers filter based on IP rules
6. NDIS sends the packet to the NIC

What is WFP?

Windows Filtering Platform (WFP) is a set of user-mode and kernel-mode APIs introduced in Windows Vista and later. It allows software to intercept, inspect, filter, block, modify, or monitor traffic at various points in the Windows networking stack.

You can think of it as a modular firewall framework, but one that's extensible and programmable through:

• User-mode APIs (Fwpm*)
• Kernel-mode APIs (Fwps*)
• Custom callout drivers you write

Why WFP?

WFP is a powerful API provided by Microsoft that lets developers hook into the Windows networking stack at multiple layers – from application-level protocols like HTTP to transport-level flows like TCP/IP.

With WFP, you can:

• Intercept, inspect, block or redirect traffic
• Filter packets by process, user, port, or protocol
• Build kernel-mode callouts that see every byte of data
• Create sophisticated rules in user-mode and update them live

What is a WFP Driver?

A WFP driver is a kernel-mode network filter driver. It attaches to specific points in the Windows network stack to observe or modify network packets.

So, if you want to:

• Block certain websites
• Monitor all DNS queries
• Encrypt/decrypt traffic
• Detect malware patterns

You can do that with a WFP driver.

Why Was WFP Introduced?

Before WFP, developers used:

• TDI filters (Transport Driver Interface) – deprecated
• Winsock Layered Service Providers (LSPs) – complex, unstable
• NDIS Intermediate Drivers – low-level, hard to use

There were fragmented, hard to maintain, and limited in functionality.

WFP unified packet filtering, made it modular and secure, and supported per-app, per-user, per-protocol filtering with system integration.

How WFP Works: Conceptual Model

Here's a textual flow:

[ Application (Chrome.exe) ]
       |
[ Winsock - User Mode ]
       ↓
[ WFP: ALE_CONNECT Layer ]   ← Can inspect app info, user SID
       ↓
[ WFP: Transport Layer ]     ← Can inspect TCP/UDP headers
       ↓
[ WFP: Network Layer ]       ← Can inspect IP/ICMP headers
       ↓
[ WFP: Data-link Layer (NDIS) ]
       ↓
[ NIC Driver → Network ]

WFP sits at multiple layers, and you choose where to attach your driver.

WFP Key Concepts

Below are the key components of the WFP.

Layers

Think of layers as checkpoint in the network stack where WFP can look at and act on traffic.

• A layer is a fixed point in Windows' packet/connection processing pipeline.
• Examples:
  • FWPM_LAYER_ALE_AUTH_CONNECT_V4 – application is trying to make an outbound TCP connection.
  • FWPM_LAYER_INBOUND_TRANSPORT_V4 – inbound TCP/UDP packet has been delivered to transport.
  • FWPM_LAYER_STREAM_V4 – TCP byte stream after reassembly.
• You cannot create your own new layer – these are predefined by Windows.

WFP lets you attach your logic to one or more of these layers. WFP has 50+ layers, but the most important ones are:

Each layer gives you different types of information and control.

1. Application Layer Enforcement (ALE)
   ├── ALE_AUTH_CONNECT (outbound)
   ├── ALE_AUTH_RECV_ACCEPT (inbound)
   └── ALE_FLOW_ESTABLISHED (bi-directional)

2. Transport Layers
   ├── INBOUND_TRANSPORT
   └── OUTBOUND_TRANSPORT

3. Network Layers
   ├── INBOUND_NETWORK
   └── OUTBOUND_NETWORK

4. Data Link Layers
   ├── INBOUND_MAC
   └── OUTBOUND_MAC

Filters

Filters are rules that say:

“If traffic looks like this; do something about it.”

They are defined in user mode and describe:

• Which layer to attach to
• What conditions must match (like port, IP, protocol)
• What action to take

Example:

If destination port is 80 AND protocol is TCP → run my callout

You define filters with the Fwpm API* in user mode.

Callouts

In the Windows Filtering Platform, a callout extends the capabilities of WFP by providing custom processing logic for network packets or connection events. A callout is defined by a set of callout functions (such as classify, notify, and flow-delete functions) and a GUID that uniquely identifies it. WFP includes several built-in callouts. Additional callouts can be added by developing and registering them in a callout driver.

Callouts are your custom logic that runs when a filter matches. You write this logic in a kernel-mode driver.

• A callout is basically “what to do when this layer is reached” if you want special processing beyond simple allow/block.
• It is a function set you (or Windows) register with WFP, identified by a GUID.
• The main function is classifyFn, which decides what to do with the traffic.

You implement a function (like ClassifyFn) that decides:

• Should this packet be blocked, allowed, modified, or ignored?
• You can create your own callouts in a driver. Windows also has built-in ones.

Example use:

Your ClassifyFn might check if a packet contains bad content, and then block it.

Callout = “code”

Filter = "rule"

+------------------------------------------------+
|                Application Layer               |
+------------------------------------------------+
        |
        v
+------------------------------------------------+
|                WFP Filtering Engine            |
+------------------------------------------------+
        |
        |   (Filter conditions & actions)
        v
+-------------------+       +-------------------+
|   Filter Object   | --->  |   Callout Object   |
| (matches packets) |       | (custom logic)     |
+-------------------+       +-------------------+
        |                        ^
        v                        |
  [Permitted/Blocked]       +-------------------+
  [Modified Packet]         |  Callout Functions|
                            |  - classifyFn     |
                            |  - notifyFn       |
                            |  - flowDeleteFn   |
                            +-------------------+
                                  |
                                  v
                             [Packet processed
                              by callout logic]

Relationship between layer and callout

[Layer]  <— fixed position in packet path
   ^
   |
[Filter] — tells WFP what to do at that layer
   |
   +-- (simple action: permit/block)
   |
   +-- (complex action: invoke Callout)
                   |
                   v
             [Callout function code]

The Filtering Engine

The Filtering Engine is part of Windows that evaluates all the filters and decides:

• Should it call a driver?
• What priority does each rule have?
• What action does the system?

It lives in kernel-mode and works 24/7.

Think of it as:

A smart traffic cop reading your filter signs and deciding who to stop.

The Base Filtering Engine (BFE)

A user-mode service that helps manage:

• Filters
• Callouts
• Sublayers

It is the central coordinator of all WFP operations. It runs as a Windows service (BFE), Uses Remote Procedure Calls (RPC) for user-mode communication.

If BFE is stopped, network traffic may fail completely.

Sublayers

Filters are grouped into sublayers.

Why?

• To organize them
• To assign priorities within a group
• To manage them more easily

Each sublayer can contain many filters.

Sublayers are like folders. Filters are like documents inside.

Contexts & Metadata

When a packet hits your callout, WFP gives you extra info called metadata.

You can access:

• Source & destination IP addresses
• Ports
• App path (e.g., chrome.exe)
• User SID
• Timestamps
• Interface info

You can also flow context if you want to remember something between packets in a connection.

Injection

WFP also lets you:

• Modify a packet and send it forward
• Drop it entirely
• Clone a packet and send a copy somewhere else
• Create your own packet from scratch and inject it

This is done using APIs like:

• FwpsInjectNetworkSend*
• FwpsInjectTransportSend*

Be careful: Injection done wrong can crash the system.

ClassifyFn, NotifyFn, FlowDeleteFn

When you write a WFP driver, your core functions are:

1 Filtering Layers

WFP integrates deeply into the networking stack and offers hooks at multiple layers:

Each layer has filtering callouts you can register with.

2 Callouts

Callouts are custom functions (in drivers) that WFP calls when a packet reaches a filtering layer. You register these with the Base Filtering Engine (BFE).

Callouts are typically implemented in kernel-mode via a WFP callout driver.

3 Filtering Engine

The Base Filtering Engine (BFE) is a Windows service that manages filters and performs classification and enforcement based on filters and callouts.

You communicate with BFE from user-mode via the Fwpm API*.