这是一个创建于 2864 天前的主题，其中的信息可能已经有所发展或是发生改变。
发现有劫持之后就开始抓包,发现抢答的回应非常像正常的回应,很难找到什么特点来过滤.
但是反过来发现 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
第 1 条附言 · 2017-03-05 11:24:02 +08:00
浙江移动已经开始使用无校验和的劫持包了，此方法已失效
 |
1
roist 2017-01-21 23:27:03 +08:00
然后铁通系统升级了
|
 |
2
JackyBao 2017-01-21 23:45:51 +08:00 via Android
好奇问下， dns 劫持表现出来是什么样子的？完全没概念呢，谢谢！
|
 |
3
KCheshireCat OP |
 |
4
lslqtz 2017-01-22 00:19:02 +08:00
建议将地址走 VPS 隧道而不是直接丢弃。
|
|
5
KCheshireCat OP |
|
6
KCheshireCat OP |
 |
7
etc0 2017-01-22 00:33:12 +08:00  1
今天晚上杭州移动的的缓存服务器貌似炸了吧，淘宝 天猫 百度啥的全都打不开，然后路由器设置了下让所有 dns 查询走 vpn 就正常了= = 然后再分享一个炸掉了的移动缓存服务器 ip 111.0.93.187 。
|
|
8
KCheshireCat OP @etc0 移动的缓存服务器一直都很烂,我是前几天发现直播一直看不了,
然后发现移动用 DNS 把 crossdomain.xml 文件的域名解析劫持了,缓存又坏的. |
 |
9
redsonic 2017-01-22 01:05:16 +08:00
没填校验和说明不是国家队干的，投诉也解决不了
|
|
10
lslqtz 2017-01-22 01:27:01 +08:00 via iPhone
@KCheshireCat 直接丢弃感觉提示不太对 如果正常包被劫持到他们的缓存话...
|
|
11
KCheshireCat OP |
|
12
KCheshireCat OP |
|
13
redsonic 2017-01-22 01:51:28 +08:00
@KCheshireCat 我看错了。 另外如果是劫持的，然后还没有校验和的，一般都不是运营商的官方行为，有也是内鬼。
|
|
14
lslqtz 2017-01-22 02:45:59 +08:00 via iPhone
|
|
15
KCheshireCat OP 1
@lslqtz
做劫持的通常是一个旁路设备,参考某国家级防火墙.这些设备通常不会直接拦截或者修改包,应为开销很大. 也就有后门的路由器或者公司内网的上网行为审计这样的设备才会做得很彻底. 我是做了抓包发现劫持包之后会有正确的包到达才会这么做的.有的时候正确的包还比劫持包快... |
 |
16
Fulminit 2017-01-22 07:54:21 +08:00 via iPhone
浙江移动 换了 AliDNS 之后某些网站打开巨慢...（或者根本就打不开）
|
 |
17
anubu 2017-01-22 08:30:21 +08:00
windows 上能解决这个问题不能，路由器没刷机。被浙江移动劫持的不行不行的，稍微冷一点的域名第一次都打不开。
|
 |
18
bigw 2017-01-22 10:12:41 +08:00
这些运营商恶心得一逼啊 我的 app 有个自动更新的功能 结果用户下载下来都是些乱七八糟的 app
|
 |
19
sorcerer 2017-01-22 10:14:27 +08:00 via iPhone
好方法，我是用 unbound 采取 tcp 形式发送 dns 请求
|
 |
22
CloudnuY 2017-01-22 11:42:05 +08:00 via iPhone
抢答包的 TTL 都正常？
|
|
23
KCheshireCat OP @CloudnuY
如果你是说抢答包 UDP 的 TTL,这个 TTL 不太适合拿来写规则,变动的可能性比较大. 如果你说的是抢答包的解析的 TTL,那是 600,但是这个容易误伤,然后要在 iptables 上面获得这个数值也比较困难. |
 |
24
tianshilei1992 2017-01-22 12:42:37 +08:00
我发现移动的缓存经常炸了…上海移动一到晚上就炸…
|
|
25
etc0 2017-01-22 13:16:56 +08:00
|
 |
26
Xxss 2017-01-22 13:19:34 +08:00
深圳移动同样存在 AliDNS 劫持的问题，太恶心人了。
|
 |
27
vinsoncou 2017-01-22 16:47:59 +08:00
不用移动宽带不就得了
|
 |
29
lixingcong 2017-01-22 17:30:16 +08:00 via Android
"0x0>>0x16&0x3c@4&0xFFFF=0"
这段话是什么意思 有相关的参考博客链接吗 |
|
30
KCheshireCat OP |
 |
32
lechain 2017-01-22 18:29:49 +08:00
我都是直接上 dnscrypt 的
|
 |
33
lanlanlan 2017-01-22 18:37:42 +08:00
移动在 15 年时候我发现过直接劫持 DNSIP 的,当时劫持了 DNSPOD 的 119.29.29.29 以及 ali 的 223.5.5.5 223.6.6.6 谷歌 8.8.8.8 过了好几个小时后才恢复回去 不知道是相关设备的运维手抖了还是临时工干坏事被发现后开除了。
|
|
34
KCheshireCat OP @lixingcong
你可以搜索一下 iptables U32 模块的用法 大致意思是：从 0 位开始将 4 字节的取值框右移 0x16 位，然后对取值和 0x3C 按位与，再然后根据结果跳过相应长度的字节数，在新的的位置开始再跳过 4 字节，和 0xFFFF 按位与，所得的值应该等于 0 。 效果简单来说就是跳过 ip 头，在 UDP 头找到校验和的位置，匹配校验和是 0 的包，再因为前面有“！”取反，所以校验和不是 0 的会被匹配到。 |
 |
35
charli 2017-01-22 20:07:08 +08:00
都是用 tcp 解析， linux 和安卓下用 pdnsd ， win 下用 Pcap_DNSProxy 。
腾讯和 114 的 dns 是支持 tcp 的。 |
|
36
CloudnuY 2017-01-22 23:51:25 +08:00
@KCheshireCat
嗯 我说的第一种，测了几个 IP 发现除了 114DNS 的 TTL 随机变动以外，其他 TTL 范围比较固定，旁路抢答包的 TTL 应该有一些特征 |
|
37
vinsoncou 2017-01-23 09:47:01 +08:00
@KCheshireCat 移动的垃圾宽带有什么好用的
|
 |
38
zysuper 2017-01-23 09:52:32 +08:00
看来要好好学习下网络了，手艺不好，未来形势严峻了呀。
|
Select Language