浙江移动劫持 aliDNS 的解决方法之一

[KCheshireCat]

发现有劫持之后就开始抓包,发现抢答的回应非常像正常的回应,很难找到什么特点来过滤.
但是反过来发现 aliDNS 自己的回应很有特点:没有填写校验和,UDP 的校验和是可选的.
那么接下来的工作就简单了,我就做了点微小的工作

把 aliDNS 地址回应的包有校验和的包全部丢弃.

iptables -A INPUT -s 223.5.5.5 -p udp --sport 53 -m u32 ! --u32 "0x0>>0x16&0x3c@4&0xFFFF=0" -j DROP
iptables -A INPUT -s 223.6.6.6 -p udp --sport 53 -m u32 ! --u32 "0x0>>0x16&0x3c@4&0xFFFF=0" -j DROP
iptables -A FORWARD -s 223.5.5.5 -p udp --sport 53 -m u32 ! --u32 "0x0>>0x16&0x3c@4&0xFFFF=0" -j DROP
iptables -A FORWARD -s 223.6.6.6 -p udp --sport 53 -m u32 ! --u32 "0x0>>0x16&0x3c@4&0xFFFF=0" -j DROP

[joyerma]

@Fulminit 我家也是，换回运营商自己的就好了。

[CloudnuY]

抢答包的 TTL 都正常？

[KCheshireCat]

@CloudnuY

如果你是说抢答包 UDP 的 TTL,这个 TTL 不太适合拿来写规则,变动的可能性比较大.

如果你说的是抢答包的解析的 TTL,那是 600,但是这个容易误伤,然后要在 iptables 上面获得这个数值也比较困难.

[tianshilei1992]

我发现移动的缓存经常炸了…上海移动一到晚上就炸…

[etc0]

@KCheshireCat
@sorcerer
似乎是移动的缓存服务器不支持 https ，然后导致所有开启了 https 的站点都没法正常访问。

[Xxss]

深圳移动同样存在 AliDNS 劫持的问题，太恶心人了。

[vinsoncou]

不用移动宽带不就得了

[superxxin]

@vinsoncou 流弊

[lixingcong]

"0x0>>0x16&0x3c@4&0xFFFF=0"

这段话是什么意思 有相关的参考博客链接吗

[KCheshireCat]

@vinsoncou

因噎废食，我很佩服哦

[lbp0200]

dig baidu.com +tcp @114.114.114.114

[lechain]

我都是直接上 dnscrypt 的

[lanlanlan]

移动在 15 年时候我发现过直接劫持 DNSIP 的,当时劫持了 DNSPOD 的 119.29.29.29 以及 ali 的 223.5.5.5 223.6.6.6 谷歌 8.8.8.8 过了好几个小时后才恢复回去 不知道是相关设备的运维手抖了还是临时工干坏事被发现后开除了。

[KCheshireCat]

@lixingcong

你可以搜索一下 iptables U32 模块的用法

大致意思是：从 0 位开始将 4 字节的取值框右移 0x16 位，然后对取值和 0x3C 按位与，再然后根据结果跳过相应长度的字节数，在新的的位置开始再跳过 4 字节，和 0xFFFF 按位与，所得的值应该等于 0 。

效果简单来说就是跳过 ip 头，在 UDP 头找到校验和的位置，匹配校验和是 0 的包，再因为前面有“！”取反，所以校验和不是 0 的会被匹配到。

[charli]

都是用 tcp 解析， linux 和安卓下用 pdnsd ， win 下用 Pcap_DNSProxy 。
腾讯和 114 的 dns 是支持 tcp 的。

[CloudnuY]

@KCheshireCat
嗯 我说的第一种，测了几个 IP 发现除了 114DNS 的 TTL 随机变动以外，其他 TTL 范围比较固定，旁路抢答包的 TTL 应该有一些特征

[vinsoncou]

@KCheshireCat 移动的垃圾宽带有什么好用的

[zysuper]

看来要好好学习下网络了，手艺不好，未来形势严峻了呀。