从原理上根绝运营商劫持,基于 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.

[nfroot]

之前看劫持包的 TTL 都不对的时候 就在想这个问题了 只是对这个太不了解…… 自己技能也达不到这个级别……

点赞

[RobertYang]

点赞，被电信插广告他们还不认

[lslqtz]

如果旁路设备知道客户端与它的 TTL ，那么旁路设备再检测服务器 TTL 加起来的话。

[est]

crazy idea 。。。居然能在 iptables 做这么多事。。。学习了。

[est]

结合 ip netns 可以只对浏览器生效。这样可以限制误伤范围。

[TMily]

额 能不能将特定 WAN 口改为特定防火墙区域呢，多拨的话，都不一定是哪个口拨上的说

[KCheshireCat]

@est

其实这个规则对某国家级防火墙的 RST 包也有效,只不过它会对服务器和客户端双方都发送,虽然有效但是救不了这条连接.

[KCheshireCat]

@TMily

额,我不清楚 openwrt 上的防火墙区域是怎么回事,你可以直接填上去试试,不行的话,就用排除法.

把不是 wan 口的接口排除掉

[est]

@KCheshireCat 能不能用 bytecode 实现服务器主动发一条 TTL 到达不了客户端的 ACK,PSH 但是墙能收到。。。然后 seq 号是不是就混乱了呢？

[est]

@KCheshireCat 你们二次元头像党又是玩技术的太可怕了。

[aru]

1. 能否限制只对 tcp port 80 起作用（也许能降低 cpu 占用率？）
2. openwrt 下有没有朋友来搞搞？

[feng32]

好东西，等晚上回去在 openwrt 上测试一下，依赖的模块是否都现成的看一下

[KCheshireCat]

@est iptables 本职工作是防火墙啊,要发包大概要打补丁实现了吧,这方面我不太懂

[KCheshireCat]

@aru 我用 x86 的 AMD 速龙 x4 老爷机跑满 100M 是一点问题也没有,几乎没有负载,轻轻松.
路由器的嵌入式平台就不知道了,只对 80 起效是可以做到的,但是上网主要流量也就是 80 的多啊...

[aru]

@KCheshireCat
p2p 下载基本都是非 80 的，而且流量很大。我的大流量应用就是 PT ，经常达到 200Mbps ，估计加上这个会是一个瓶颈。
今天尝试在 lede （ openwrt fork ）上添加项目的 iptables ，找不到 bpf 模块 :(

[KCheshireCat]

@aru
你需要针对端口限制的话可以在要填"{your WAN}"的那两行加入端口匹配条件.

然后一般来说容易缺失的 iptables 模块就是 u32 或者 bpf 了,大多数人只是用 iptables 解决些简单的需求,所以不会用到这种需要写字节码的模块.

不过可以自己编译 openwrt 固件的时候把这几个模块一起编译进去,再或者你可以看看 openwrt 官方源有没有提供补全 iptables 的包,这样就不用自己编译了.

[aru]

@KCheshireCat u32 我编译和加载了， bpf 实在没找到配置选项，网上找了挺多地方，没发现究竟是哪个配置参数

[JJaicmkmy]

@KCheshireCat 如果是自己的服务器的话，可以在服务器上也 DROP 掉 RST 的包，对 SS 有奇效。

[KCheshireCat]

@JJaicmkmy #18
这么弄的话好像会触发路由黑洞，以前看别人提过。

[Siril]

awesome idea ， but.....
看 issue ，疑似有误伤，求解惑。
不知可否在其他发行版复现这个问题

[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 流了……