背景故事
近些日，在做 IDC 的好兄弟说遇到了一个奇怪案例，他们机房的一个租户突破了备案检测的限制，用未备案域名架设网站，结果被工信部扫到，最后吃了一张罚单。好兄弟对这个怎么绕过的甚是好奇，就将情况告诉了我让我帮忙看看。
分析过程
分析开始是对该域名直接访问，看看里面是什么内容，才需要用到这种绕过备案路子。
一看给好兄弟惊呼是一个涉诈网站，还好是工信部扫描罚款，要是有受害者因为这个案例被诈骗，负责人被当成帮 x 罪进去了可得不偿失。涉诈网站快照：
进一步分析域名解析记录后，发现该域名同时解析了境内多家 IDC ，疑似用这种方式规避因被单个机房发现造成的单点故障。
抓包分析
想要知道这个网站是使用了什么方式绕过了备案检测根本方法是抓包，看服务端发送了哪一些奇怪数据包造成了检测机制失效：
从抓包结果来看，序号 1~3 数据包平平无奇，是正常的三次握手。不过序号 4 怎么会出现有”TCP Window Full”的情况，造成了客户端发送 HTTP 请求时候被截断，没有发送完整的 HTTP 请求数据包出去。
再回溯之前序号 1~3 数据包，发现二次握手时，服务端故意将 TCP 的 Window 字段设置为了 4 ，该字段意思是告诉客户端，目前服务端目前只可以接受 4 字节数据。所以在序号 4 中，客户端仅发送了“GET ”数据。待服务端确认收到了“GET ”时，又因为 ACK Window 恢复，客户端继续发送剩下的数据。
被黑产调整过后的数据包就变成了这样：
红色代表着第一个数据包、蓝色代表着第二个数据包。
此时已经能大致推测，检测设备是通过判断 TCP 三次握手后的客户端第一个数据包是否为 HTTP 数据包来工作。如果是 HTTP 数据包，设备会提取其中的 Host 字段以获取域名，并进一步判断该域名是否已备案。
场景复现
需要实现修改 TCP 二次握手内的 Window 字段，在 Linux 中似乎并没有一个比较简单的办法。最终还是使用了 ebpf 完成了修改 Window 字段。也是验证上文中的猜测。
由于该问题刚刚上报给对应机房厂商，为了不必要的麻烦，在这边就不直接提供对应源码，有能力大佬们可以自行尝试下。
总结
黑产巧妙地利用 TCP 二次握手中 Window 大小设置为 4 的特点，并借助 Window Scale 尚未生效的机制，迫使客户端将 HTTP 请求的数据包进行切割。通过这一手段，成功绕过了检测设备的限制：设备仅会解析客户端发送的第一个数据包中的 HTTP 请求，并尝试提取 Host 字段的域名以判断是否备案。然而，由于第一个数据包未包含完整的 Host 字段，设备无法进行有效检测，自然跳过了后续的 Host 字段备案验证环节。
此外，服务端在后续 ACK 数据包中恢复了正常的 Window 大小，对后续通信未造成任何影响（相比于通过修改 TCP MSS 方式更加巧妙）。
同时，黑产还使用了多个国内 IDC 机房，降低了工信部扫描通报后可能导致的单点故障风险。
求职
目前我正在寻找新的工作机会，Base：上海，方向：网络安全开发、网络安全建设、或转发面开发。
如果有兴趣的话可以随时与我联系 WX: YThqZG9xcDE3Yg==
| 
