浙江移动劫持 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

浙江移动已经开始使用无校验和的劫持包了，此方法已失效

[roist]

然后铁通系统升级了

[JackyBao]

好奇问下， dns 劫持表现出来是什么样子的？完全没概念呢，谢谢！

[KCheshireCat]

@JackyBao

最明显的就是访问不存在的域名会被导向"错误页"

网页轮回跳转什么的

[lslqtz]

建议将地址走 VPS 隧道而不是直接丢弃。

[KCheshireCat]

@lslqtz

把伪造的包就没什么问题了啊,正常的包也会到达

如果走隧道查询,CDN 是个问题啊

[KCheshireCat]

@lslqtz

"把伪造的包丢弃就没什么问题了啊" 漏字了

[etc0]

今天晚上杭州移动的的缓存服务器貌似炸了吧，淘宝 天猫 百度啥的全都打不开，然后路由器设置了下让所有 dns 查询走 vpn 就正常了= = 然后再分享一个炸掉了的移动缓存服务器 ip 111.0.93.187 。

[KCheshireCat]

@etc0 移动的缓存服务器一直都很烂,我是前几天发现直播一直看不了,
然后发现移动用 DNS 把 crossdomain.xml 文件的域名解析劫持了,缓存又坏的.

[redsonic]

没填校验和说明不是国家队干的，投诉也解决不了

[lslqtz]

@KCheshireCat 直接丢弃感觉提示不太对 如果正常包被劫持到他们的缓存话...

[KCheshireCat]

@redsonic

没有校验和是好事啊,aliDNS 的正确的包没有校验和,UDP 没有校验和也是可以的

有校验和的反而是劫持的包...

[KCheshireCat]

@lslqtz

你理解错了,没有人会用这样的缓存服务,只有运营商会这样搞.

aliDNS 正常的响应都是没有校验和的,有校验和的都是伪造的包,而且应答的劫持地址还连不上.

[redsonic]

@KCheshireCat 我看错了。 另外如果是劫持的，然后还没有校验和的，一般都不是运营商的官方行为，有也是内鬼。

[lslqtz]

@KCheshireCat 你也说了 只有运营商会这么搞
要是运营商劫持你设定的 dns 并返回他们的缓存
那么你丢掉后 dns 整个就坏掉了...

[KCheshireCat]

@lslqtz

做劫持的通常是一个旁路设备,参考某国家级防火墙.这些设备通常不会直接拦截或者修改包,应为开销很大.

也就有后门的路由器或者公司内网的上网行为审计这样的设备才会做得很彻底.

我是做了抓包发现劫持包之后会有正确的包到达才会这么做的.有的时候正确的包还比劫持包快...

[Donate]

浙江移动 换了 AliDNS 之后某些网站打开巨慢...（或者根本就打不开）

[anubu]

windows 上能解决这个问题不能，路由器没刷机。被浙江移动劫持的不行不行的，稍微冷一点的域名第一次都打不开。

[bigw]

这些运营商恶心得一逼啊 我的 app 有个自动更新的功能 结果用户下载下来都是些乱七八糟的 app

[sorcerer]

好方法，我是用 unbound 采取 tcp 形式发送 dns 请求

[sorcerer]

@etc0 原来是缓存服务器炸了，它炸了才让我发现了移动的 dns 劫持

[joyerma]

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

[CloudnuY]

抢答包的 TTL 都正常？

[KCheshireCat]

@CloudnuY

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

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

[shiltian]

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

[etc0]

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

[0x2537]

深圳移动同样存在 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]

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