Introduction to Windows Filtering Platform (WFP)

What Happens When an App Sends Data?

Let's say a browser sends request to http://example.com. Here' what happens internally on Windows:

[ Application Layer (e.g., Chrome) ]
            |
[ Winsock API (user-mode socket calls) ]
            |
[ Transport Layer (TCP/UDP) - kernel-mode ]
            |
[ Network Layer (IP, routing) - kernel-mode ]
            |
[ NDIS (Network Driver Interface Specification) ]
            |
[ Physical NIC Driver (e.g., Intel Ethernet driver) ]
            |
[ Ethernet/Internet ]

        [ Applications ]
               ↓
    +------------------------+
    | Base Filtering Engine  |  ← User Mode
    | (BFE)                  |
    +------------------------+
               ↓
    +------------------------+
    | Filter Engine          |  ← Kernel Mode
    +------------------------+
        ↓         ↓        ↓
  [ Filters ]  [ Callouts ] [ Conditions ]
        ↓
  [ Network Stack ]
        ↓
    [ NIC Driver ]

• Your app calls send() or connect().
• That passes through Winsock, which interfaces with the Windows TCP/IP stack.
• From there, data goes through multiple kernel-mode layers before hitting the network

Why Do We Care About Kernel-Mode?

User-Mode (App code)

• Limited access to system resources
• Safe (isolated from the OS kernel)
• Slower access to low-level events

Kernel-Mode (Drivers)

• Full access to memory, hardware, and networking stack
• Used by antivirus, firewalls, VPNs, and system utilities
• Risk of BSOD (blue screen) if misused

WFP works in kernel mode to intercept and inspect/modify traffic at various layers.

What Is Windows Filtering Platform?

Windows Filtering Platform (WFP) is a set of APIs and system services provided by Microsoft that allows kernel and user mode software to intercept, filter, or modify network traffic.

WFP is used by:

• Windows Defender Firewall
• VPN software
• Antivirus/EDR tools
• DLP (Data Loss Prevention) systems
• 3rd-party firewalls and network monitors

It was introduced in Windows Vista / Server 2008, and is now a critical part of Windows security and networking.

WFP Architecture: Where It Hooks

WFP operates across the entire Windows networking stack, form the lowest hardware levels (NDIS drivers) to high-level HTTP traffic.

Here's a simplified diagram:

Application Layer (HTTP, DNS, SMB, etc.)
        ↓
Transport Layer (TCP, UDP, etc.)
        ↓
Network Layer (IPv4/IPv6)
        ↓
Link Layer (NDIS, network drivers)

You can insert filters at any of these layers. That's what makes WFP so powerful – you choose where and how deeply you want to inspect or block traffic.

For example:

• Want to block HTTP POSTs? Filter at stream layer.
• Want to scan DNS? Filter at datagram layer.
• Want to reroute packets? Filter at network layer.

WFP Filtering Flow

WFP filtering is done through:

• Filters: Rules that define what traffic to act on
• Callouts: Optional handlers (usually in kernel) that inspect, modify, or log traffic
• Sublayers: Logical groups of filters with priorities
• BFE (Base Filtering Engine): Core service that coordinates filters

Each packet that travels through the system passes through multiple layers. Your filter gets a chance to:

• Allow (FWP_ACTION_PERMIT)
• Block (FWP_ACTION_BLOCK)
• Inspect further via callout

Key Components of WFP

1 Base Filtering Engine (BFE)

User-mode service (runs as Bfe.dll)

Controls the global WFP state, filtering configuration, and event notifications.

Manages:

• Filter databases
• Callout registrations
• Layer bindings

We can interact with BFE from user-mode application with the FwpmXxx API.

2 Filter Engine

• Kernel-mode component
• Makes decisions about whether packets should be allowed, blocked, modified, or inspected.
• Evaluates each packet or network event against the active filters.

3 Filtering Layers

WFP has multiple predefined layers that correspond to different points in the packet's lifecycle.

We can select the layer based on what kind of traffic we want to filter and at what point.

4 Filters

• Rules that define what traffic should be matched
• Consist of:
  • Conditions (e.g., protocol == TCP, remote port == 80)
  • Actions (PERMIT, BLOCK, CALLOUT)
  • Weight (priority)
• Filters are installed via user-mode but are enforced by the kernel

5 Callouts

• Kernel-mode callbacks registered by the driver
• Invoked when a filter with an action of FWP_ACTION_CALLOUT_TERMINATING or FWP_ACTION_CALLOUT_INSPECTION matches traffic.
• We write these to inspect, log, modify, block, or redirect traffic.

Key functions:

• classifyFn – runs when a packet matches the filter
• notifyFn – called when filters are added/removed
• flowDeleteFn – optional, cleans up per-flow state

6 Sublayers

• Logical containers for filters
• Help organize filters and control evaluation order
• We can define our own sublayers with a unique GUID

How It all Works

Here's the typical packet filtering workflow

1. A packet arrives (from the network or an application)
2. It reaches a WFP layer (e.g., OUTBOUND_TRANSPORT_V4)
3. The Filter Engine checks all active filters for that layer.
4. If a filter matches, the engine:
   1. Executes the action (permit/block)
   2. Or calls our driver via the callout
5. Our callout function processes the packet (e.g., logs, blocks, modifies)
6. The decision is enforced or the packet is dropped

Real-World Analogy

Imagine a security checkpoint at different doors of a building. Each checkpoint represents a filtering layer. Guards at each door are filters. Some guards just let people in or stop them (simple filters). Some call their supervisor (callout) to inspect or question the person further.