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()
orconnect()
. - 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.
Layer Name | Layer Key Constant | Purpose |
---|---|---|
ALE_AUTH_CONNECT_V4 | FWPM_LAYER_ALE_AUTH_CONNECT_V4 | Pre-connect check for outbound TCP/UDP |
OUTBOUND_TRANSPORT_V4 | FWPM_LAYER_OUTBOUND_TRANSPORT_V4 | Packet about to leave transport layer |
STREAM_V4 | FWPM_LAYER_STREAM_V4 | Inspect TCP byte streams |
INBOUND_MAC_FRAME_ETHERNET | FWPM_LAYER_INBOUND_MAC_FRAME_ETHERNET | Filter raw frames at the NIC level |
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
orFWP_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 filternotifyFn
– called when filters are added/removedflowDeleteFn
– 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
- A packet arrives (from the network or an application)
- It reaches a WFP layer (e.g.,
OUTBOUND_TRANSPORT_V4
) - The Filter Engine checks all active filters for that layer.
- If a filter matches, the engine:
- Executes the action (permit/block)
- Or calls our driver via the callout
- Our callout function processes the packet (e.g., logs, blocks, modifies)
- 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.
Leave a comment
Your email address will not be published. Required fields are marked *