零比特：当 EDR 网速慢到还不如断网

幻泉之洲

2026年6月8日 09:16
北京

在小说阅读器读本章

去阅读

把 EDR 的网速限制到每秒 8 比特——这是一个什么概念？相当于让一个骑自行车的人扛着一整栋写字楼赶路。本文提出一种新的 EDR 断网思路：不封端口、不丢包，而是用系统自带的服务质量策略，把 EDR 进程的带宽压到几乎为零。这种方式操作在比防火墙更底层的位置，留下的痕迹也更少。文末附带了 EDRChoker 工具的完整演示。

EDR 断网这件事

云时代的 EDR，本质上是一个和服务器保持长连接的客户端。检测能力、响应指令、日志回传，全靠这条通道。一旦通道断了，终端上的 agent 就变成了瞎子。攻击者手里能做什么，大家心里都清楚。

断开 EDR 连接，过去主要靠两招：Windows 防火墙规则，或者 Windows 过滤平台。Windows 防火墙本质上也跑在 WFP 之上——它能针对任意进程设置出站阻断，只要你有本地管理员权限。

微软对自己的核心安全进程做了保护。比如 MsMpEng.exe，你想用防火墙规则把它拦下来，系统层面会直接拒绝。这不奇怪，操作系统防的就是这种自残式操作。

WFP 这条路更精细一些。FwpmFilterAdd0 这个 API 可以直接编程注册网络过滤器，EDRSilencer 这类工具打得就是这个点。问题是留下了痕迹。包被丢弃这件事，EDR 自己会记录，Elastic 甚至为 WFP 层面的规避行为专门写了检测规则[1]。

你打断了它的腿，它还能喊一声。这就是问题。

换个思路：不拦你，让你慢到死

Windows 有一套基于策略的服务质量控制机制，叫做 Policy-based QoS。你通过组策略或者 PowerShell，可以给特定程序、端口、协议设定一个绝对的出站带宽上限。

一行命令就能设置：

New-NetQosPolicy -Name \"FTP\" -AppPathNameMatchCondition \"ftp.exe\" -ThrottleRateActionBitsPerSecond 1MB -PolicyStore ActiveStore

实测最小可以设到每秒 8 比特。注意，是比特，不是字节。换算一下，一秒传 1 个英文字母都勉强。

带宽低到这个程度会发生什么？一个现代 TLS 握手大概消耗多少数据，我们来算笔账。

Client Hello 大约 150 到 500 字节，Server Hello 加密钥交换再要 100 到 500 字节。大头是证书链——一张 RSA-2048 或 ECDSA 签名的证书带上公钥，体积不小；如果站点发下来 3 到 4 张中间证书凑成完整链，光这个环节就能吃掉 3000 到 8000 字节，甚至更多。最后再补上各约 100 字节的 Finished 验证消息。一次完整的 TLS 握手，少则 3、4 KB，多到 10 KB 以上，属于常态。

现在你把应用限到每秒千里挑几个字节。握手需要交换好几 KB 的证书——在 8 bps 的带宽下，光传输这些证书就得几个小时。没有哪台服务器会等你这么久。大多数应用程序和 API 都设置了严格超时，2 到 5 秒握手没完成，直接判定丢包，连接超时。

所以不用封你。把你网速掐到 8 bps，你自己就会不停地超时、断开、重试、再超时。效果和断网没有区别，但方式完全不同。

pacer.sys 的位置优势

这个方案真正有意思的地方，在于 QoS 数据包调度器运行在比 WFP 更底层的位面。

看数据从应用层往下走的路线：应用生成数据 → tcpip.sys 打包成 TCP/IP 帧 → WFP 在这一层和 tcpip.sys 紧挨着，执行规则检查、路径匹配、防火墙操作 → 数据离开内核进入 NDIS 层 → pacer.sys 以 NDIS 轻量过滤驱动的身份截获原始以太网帧，紧贴着物理网卡的小端口驱动 → 数据从网卡出去。

pacer.sys 待在 NDIS 这一层。WFP 在第三层，pacer.sys 在第五层。越贴近硬件，控制力越强。现在市面上阻断 EDR 的工具，普遍只能摸到 WFP 那层。

这就意味着：如果你在 pacer.sys 的层级动手，EDR 只要不主动检查 QoS 策略，就不知道自己已经废了。