近些日,在做 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==
1
tool2dx 30 天前
我这里 IDC 都是要人工审核的,页面都要去看一下,有没有违规的地方。
不可能第一个 HTTP 请求包延迟返回,就默认域名通过了。。 而且现在都是 HTTPS 时代,程序化都是获取证书来判断的。 |
2
COW 30 天前 via Android
这码打的,冒充银河证券的诈骗网站?
|
4
frayesshi1 30 天前
@tool2dx 不备案比如阿里云,腾讯云是访问不了 http 的
|
5
daimaosix 30 天前 via Android
跟过移动屏蔽一个原理,不过最近移动升级了墙
|
6
MFWT 29 天前
前段时间看过有类似的案例,不仅用来面对备案墙,甚至用来对付大墙(对,就是那些号称不死 301 的,就是类似原理,甚至有些包不死的,多管齐下,甚至有国内多机房刷运营商 DNS ,来规避 DNS 污染什么的)
建议如果不是共享主机(就,单机单 IP 那种),还是未备案阻断 80/443 比较稳妥一些 |
7
mayli 28 天前
有意思, 这个属于防火墙设备偷懒了。
|