从‘头铁’到‘真香’：一个安全研究员折腾WFP网络过滤驱动的踩坑全记录

从‘头铁’到‘真香’：一个安全研究员折腾WFP网络过滤驱动的踩坑全记录

第一次听说Windows Filtering Platform（WFP）是在某个技术论坛上，有人用它在内核层实现了网络流量过滤。作为一个长期在用户态摸爬滚打的安全研究员，我立刻被这个想法吸引了——如果能直接在内核层拦截网络请求，岂不是能实现更彻底的访问控制？但当我真正开始研究WFP时，才发现这个决定有多么"头铁"。

1. 为什么选择WFP：一个安全研究员的思考

在网络安全领域，我们常常需要在不同层级实现访问控制。传统的用户态方案（如Hook API）虽然容易上手，但存在明显缺陷：

• 易被绕过：恶意程序可以直接调用底层API
• 稳定性问题：用户态Hook可能影响目标程序正常运行
• 性能瓶颈：频繁的用户态-内核态切换带来额外开销

相比之下，WFP作为微软官方提供的网络过滤框架，具有几个独特优势：

1. 内核级控制：直接在内核网络协议栈中操作
2. 完整的功能覆盖：支持从TCP/IP各层到应用层协议的过滤
3. 官方支持：作为Windows内置组件，兼容性和稳定性有保障

但WFP的学习曲线确实陡峭。官方文档晦涩难懂，社区资源稀少，调试困难——这些都是我后来才深刻体会到的挑战。

2. 环境准备：那些官方没告诉你的坑

2.1 开发环境搭建

WFP开发需要一整套Windows驱动开发环境，这本身就是第一个挑战。以下是我的环境配置清单：

• 硬件：一台专门用于驱动调试的测试机（强烈建议不要在主开发机上操作）
• 软件：
  • Visual Studio 2019（含Windows Driver Kit）
  • WinDbg Preview（内核调试必备）
  • VMware Workstation（用于安全测试）

提示：驱动开发对VS版本有严格要求，WDK版本必须与Windows SDK版本严格匹配，否则会出现各种诡异问题。

2.2 驱动签名问题

现代Windows系统要求所有内核驱动必须经过数字签名。开发过程中，我们需要配置测试签名模式：

# 启用测试签名模式 bcdedit /set testsigning on # 重启生效 shutdown /r /t 0

即使这样，某些安全策略严格的系统仍可能阻止测试签名的驱动加载。我花了整整两天时间才解决这个看似简单的问题。

3. WFP核心概念解析：从困惑到理解

WFP的架构设计非常抽象，官方文档充斥着大量专业术语。经过反复试验，我总结出几个最核心的概念：

3.1 关键组件及其关系

3.2 数据流处理流程

1. 网络数据包到达特定Layer（如TCP接收层）
2. WFP引擎检查该Layer注册的所有Filter
3. 匹配的Filter触发对应的Callout
4. Callout执行自定义逻辑并返回处理结果
5. WFP引擎根据结果决定数据包命运（放行/阻断/修改）

这个流程看似简单，但实际编程时需要精确控制每个组件的注册顺序和依赖关系。

4. 实战：实现网站访问控制

终于到了最激动人心的部分——用WFP实现网站访问控制。以下是关键步骤和代码片段：

4.1 注册Callout

首先需要实现并注册我们的过滤函数：

// Callout函数原型 void NTAPI our_filter_func( const FWPS_INCOMING_VALUES* inFixedValues, const FWPS_INCOMING_METADATA_VALUES* inMetaValues, void* layerData, const void* classifyContext, const FWPS_FILTER* filter, UINT64 flowContext, FWPS_CLASSIFY_OUT* classifyOut) { // 在这里实现过滤逻辑 classifyOut->actionType = FWP_ACTION_BLOCK; } // 注册Callout NTSTATUS register_callout() { FWPS_CALLOUT callout = {0}; callout.calloutKey = OUR_CALLOUT_GUID; callout.flags = 0; callout.classifyFn = our_filter_func; callout.notifyFn = NULL; callout.flowDeleteFn = NULL; return FwpsCalloutRegister(deviceObject, &callout, NULL); }

4.2 创建过滤规则

接下来需要创建Filter，将Callout与特定网络条件关联：

FWPM_FILTER filter = {0}; filter.layerKey = FWPM_LAYER_ALE_AUTH_CONNECT_V4; filter.action.type = FWP_ACTION_CALLOUT_UNKNOWN; filter.action.calloutKey = OUR_CALLOUT_GUID; filter.subLayerKey = OUR_SUBLAYER_GUID; filter.weight.type = FWP_EMPTY; // 自动分配权重 filter.numFilterConditions = 0; // 无条件过滤所有流量 // 添加Filter FwpmFilterAdd(engineHandle, &filter, NULL, NULL);

4.3 处理域名过滤

WFP本身不直接支持基于域名的过滤，需要结合DNS解析结果：

1. 在DNS请求层（FWPM_LAYER_ALE_RESOLVE_CACHE_V4）拦截DNS响应
2. 解析出域名和对应IP地址
3. 在连接层（FWPM_LAYER_ALE_AUTH_CONNECT_V4）阻断目标IP的连接

5. 调试技巧：如何避免蓝屏噩梦

内核开发最令人头疼的就是调试。以下是我总结的几个实用技巧：

• 使用WinDbg进行双机调试：这是最可靠的调试方式
• 善用Verifier：可以捕获许多常见的驱动错误

verifier /flags 0x01 /driver ourdriver.sys

• 日志记录：在内核中使用DbgPrint输出日志

DbgPrint("我们的驱动: 当前状态 %d\n", status);

注意：在内核中打印过多日志会显著影响系统性能，建议仅在调试时启用。

6. 性能优化：让过滤更高效

随着规则数量增加，WFP过滤性能可能下降。以下是一些优化建议：

1. 合理使用Sublayer权重：将高频匹配规则放在高权重Sublayer
2. 优化Filter条件：精确指定协议、端口等条件，减少不必要的检查
3. 批量操作：使用事务（Transaction）批量提交规则变更

FwpmTransactionBegin(engineHandle, 0); // 一系列规则变更操作 FwpmTransactionCommit(engineHandle);

7. 替代方案比较：何时该用（或不该用）WFP

虽然WFP功能强大，但它并非适用于所有场景。下表对比了几种常见的网络过滤方案：

对于大多数应用层过滤需求，用户态方案可能更合适。只有当确实需要内核级的控制能力时，才值得投入时间学习WFP。