从原理上根绝运营商劫持,基于 TTL 的反劫持 iptables 规则

[KCheshireCat]

不管你是遇到加小尾巴跳转,iframe 嵌套广告,302 跳转,还是 JavaScript 脚本劫持.
只要是基于旁路设备监听抢答数据包这个原理的劫持行为. 这套 iptables 规则就能应对.

注意:目前仍在实验阶段,浙江移动测试有效,无法保证不会对正常的连接产生破坏.

主要原理:基于 IP 头 TTL 值的判断丢包.并使用 ACK 空应答包,和装满数据的 TCP 包来更新 TTL,防止正常 TTL 变动导致连接断开.

• 使用 IP 头 TTL 值是因为旁路设备不可能知道服务器和客户端之间究竟有几跳而"自己"又是在哪个位置,服务器的初始 TTL 又是多少.
• 使用 ACK 或 ACK,PSH 标识位的空包来更新 TTL 的原因是旁路设备被没有理由发这样的包,这包不能切断连接而且本身也不携带上层数据.
• 使用数据长度为 MSS 协商值的原因是,旁路设备要追踪 MSS 协商这个性能成本非常高,每条 TCP 连接都会协商 MSS,但不是每条连接都会触发规则需要劫持.

项目地址

需要模块

• bpf
• u32
• connmark
• mark

注意

• connmark的标志位需要 0x7FF 长度来记录 MSS 值,还有 0xFF 来记录 TTL 值.默认记录位置为 0x07FF00FF.
• mark的标志位需要 0x1 长度.默认记录位置为 0x00000001.

工作原理

• 对每条 TCP 连接在握手时的SYN+ACK包的 TTL 值和 MSS 协商值.
• 并使用 TCP flags 标志为ACK|ACK&&PSH,且 TCP Data 长度为 0 或长度为 MSS 协商值的包对保存的 TTL 值更新.
• 其余包在不符合 TTL 值时将被 DROP.

[KCheshireCat]

@Siril #20
目前来说确实有误伤的，这主要和服务器的防火墙策略有一定关系。我在 issue 上做了解释，并提用了使用更宽松规则的临时解决方案。
但对于问题本身，我还没有更好的想法来解决。

[Siril]

@KCheshireCat 但愿能找到改进措施。
----------
下面是脑洞：
仔细考虑后，即使利用 libnetfilter_queue 做出一个，抛开稳定性、吞吐量不谈，
我感觉按延迟也不靠谱， ack 的时间受目标服务器负载的影响，不能说明问题；
主动学习数据包长度、 ttl 值 也难免误伤，
恐怕还要解析数据包内容
一般也就是内容有固定特征的 302 redirect 、 meta-refresh 、 javascript 啥的。

字符串黑名单过滤之。

思路有了，项目起名叫 WFG 不错。 XD

[KCheshireCat]

@Siril #22
最早最早的时候我也是用 string 模块过滤字段的，但这么作通用性太差，自己用还不错，写作项目的话以后维护起来会变成又臭又长的规则表，而且对单个用户来说有用的可能就其中的几个。某条规则什么的时候已经失效也没法验证。

最重要的是运营商改劫持模板方便，我们验证规则，抓包困难。这样十分吃力。

[Siril]

@KCheshireCat
前述脑洞是尝试由程序主动学习过滤列表，
比如说请求许多不同的网站返回相似的结果，
而非人工维护又臭又长的过滤列表。

[Siril]

啊不能改自己的回复， 突然想到如果 libnetfilter 可行， 何必玩高级花样。
既然真正的 response 在假的之后到达，那么假数据包太容易辨认了。
甚至可否将服务端返回的数据包缓存个多少毫秒超时，如果后续没有就发送这个，后续有“重复”的则 DROP 掉前一个。

---------
可能 proxy server 更适合实现这样的功能。

[akw2312]

手邊的四川移動機器 測試有效
不過... 如果劫持是那種整個 TCP 都劫持走的目測也沒辦法了吧..
tcp traceroute 一看都被劫持走的那種 (icmp 正常, tcp 非 80 443 8080 也正常)

[Tovcn]

@Siril 可以写个脚本，让 iptables 把疑似重的包 mark 然后对比包内容，基本一致的就 DROP...
那有对比包的模块否？

[Tovcn]

@Siril 可不是写脚本啊。。 。。错了

[siyanmao]

@Siril 我倒是觉得基于延迟判断非常靠谱。延迟最低极限的，而旁路劫持的 RTT 一般很低，通过不断采样 RTT，发现 RTT 急剧减小基本就可以判定是出现劫持了。不过这样要写程序追踪每一个 tcp 流了……