gfw攻击

gfw攻击
FB招聘站
分类阅读
专栏
公开课
FIT 2019
企业服务
用户服务
搜索
投稿
登录
注册
记一次对GFW防火墙的探究 Zooood2015-06-08现金奖励共1191043人围观，发现 25 个不明物体网络安全
今天正在努力的写代码，突然同学传了一个数据包给我，说他的openVPN连不上了。抓包发现刚一握手结束便收到了一个RST包，导致一直连不上。我打开数据包，发现果然如此：

vpn1.png

可以看到，三次握手刚完毕，客户端发送第一个控制消息到服务端，便收到了服务端发送的RST数据包，一直如此。

应该是有中间设备搞的鬼，于是我又到服务器端抓取了些数据：

vpn2.png

果然的，服务器也收到了RST数据包，于是两者的连接便断开了。

再仔细分析下客户端的RST数据包：

vpn3.png

IP包的序号是12345，TTL是120。再看正常的数据包：

vpn4.png

IP包的序号是0，TTL是46。很明显RST数据包的TTL比正常的要大，而且每次RST的IP序号都是12345，应该是GFW没错了。

正常情况下初始的TTL是64，正常收到的TTL是46，跳数是15，说明我的电脑到服务器之间经过了15个路由设备。

为了证明这点，查看服务端收到的正常数据包：

vpn5.png

服务器收到的TTL是50，因为我的电脑还要经过内部的一个路由器，所以TTL差了1。

同时查看服务端RST数据包的TTL值：

vpn6.png

TTL值为117，因此得到的信息如下：

客户端->服务器：15、GWF->服务器：117、GFW->客户端：120。

假设GFW每次发送的TTL值都固定不变且为x，则有：x-117+x-120=15；得x=126。

所以GFW和我的电脑的跳数应该是6：

vpn7.png

图示的应该就是GFW的位置。

接下来问题来了，她是怎么识别出openVPN流量的呢？

我猜测是根据数据包的特征来识别的，那么我单独发送单个数据包，应该也会返回RST数据，根据这一理论，我用scapy发送了单个的数据包，内容和三次握手之后客户端发送的第一个数据包一样，但结果是失望的，并没有收到RST数据包。

于是进一步猜测，TCP连接之后再发送相应的数据包，应该能收到RST，于是又根据这一理论，写下了如下代码：

from scapy.all import *
vpn_payload = "\x00\x0e\x38\x24\x5d\x21\xaa\x3a\x11\x2f\xb3\x00\x00\x00\x00\x00"
conf.verb = 0
vpn_s = IP(dst="yovey.me",id=12345)/TCP(sport=58620,dport=1194,flags="S",seq=0)
print "sending syn"
vpn_s.show()
ans0,unans0 = sr(vpn_s)
print "recv packet,seq = ",ans0[0][1].seq
ans0[0][1].show()
vpn_sa = IP(dst="yovey.me",id=12346)/TCP(sport=58620,dport=1194,flags="A",seq=1,ack=ans0[0][1].seq+1)
print "sending ack"
vpn_sa.show()
ans1,unasn1 = sr(vpn_sa,timeout=1)
vpn = IP(dst="yovey.me",id=12347)/TCP(sport=58620,dport=1194,flags="PA",seq=1,ack=ans0[0][1].seq+1)/vpn_payload
print "sending vpn payload"
ans2,unasn2 = sr(vpn)
ans2[0][1].show()
运行程序，还是没有收到RST数据包。

于是我打开tcpdump，抓取了发包过程的数据包，发现了问题：

vpn8.png

在服务器返回syn+ack之后，客户端居然发送了RST到服务器，导致连接断开。经过短暂的思考，才明白客户端网卡在收到来自服务器的syn+ack之后，发现并没有进程在监听该数据包的端口，于是发送了RST数据包给服务器。

必须让客户端不发送RST数据包才行，想到可以通过iptable来过滤数据包，于是在iptable中添加如下规则：

iptables -t filter -A OUTPUT -p tcp --tcp-flags RST RST -j DROP
再运行程序，一切都在计划之中：

vpn9.png

还是熟悉的IP序号，还是熟悉的TTL，看来GFW已经可以根据连接来识别流量了，真是下了血本啊。

想到建立连接，我立马联想到不用建立连接的UDP，是不是UDP数据只需要根据单个数据包就能识别了？于是将服务器配置成UDP模式，再次打开openVPN，特么的居然连上了！于是问题解决了，将配置改成UDP就能正常连接了。

*作者：Zooood，本文属FreeBuf原创奖励计划，未经许可禁止转载

Zooood
1 篇文章
等级： 1级
||
上一篇：浅谈木马如何隐藏上线IP地址下一篇：温州数字电视是如何被黑的？
这些评论亮了

GFW 回复
感谢反馈，已修复
)381(亮了

zxnO 回复
gfw有什么好研究的。读freebuf有1/3的人都或多或少直接或者间，有意或无意接参与过 gfw 建设。
)74(亮了

JuncoJet (3级)回复
根据跳数找出GFW的位置。
)72(亮了

上七下回复
李克强总理说网速慢，整天背着这些包走，网速也快不到哪里去。。
)69(亮了

过路人回复
开门,查水表
)45(亮了
发表评论已有 25 条评论

JuncoJet (3级) 2015-06-08回复 1楼
根据跳数找出GFW的位置。

亮了(72)

kylin (1级) 2015-06-08回复 2楼
开门，有你的快递

亮了(8)

过路人 2015-06-08回复 3楼
开门,查水表

亮了(45)

GFW 2015-06-08回复 4楼
感谢反馈，已修复

亮了(381)

billcan (3级) 知之为知之，不知为不知、 2015-06-08回复 5楼
学习作者的思路。。赞

亮了(1)

上七下 2015-06-08回复 6楼
李克强总理说网速慢，整天背着这些包走，网速也快不到哪里去。。

亮了(69)

lupus721 (3级) 2015-06-08回复 7楼
想到ttl是可以伪造的，记得当时劫持百度js的时候也有人提出过这个问题，当时确认的办法是一跳一跳减少来试验，但是在当前这种情况下，估计很难在目标的吓一跳范围内找个vpn进行相关测试啊。

亮了(5)

Karblue 2015-06-08回复 8楼
然而暴露了自己的位置 broad.cd.sc.dynamic.163data.com.cn :doge: 小心水表

亮了(17)

est (1级) 2015-06-08回复 9楼
这里启明星辰的人内裤都笑落了吧。

亮了(11)

zxnO 2015-06-08回复 10楼
gfw有什么好研究的。读freebuf有1/3的人都或多或少直接或者间，有意或无意接参与过 gfw 建设。

亮了(74)

lz____ 2015-06-08回复 11楼
学习思路

亮了(1)

twity 2015-06-08回复 12楼
加密数据来分析……这……我感脚很后悔没贡献多几个T的数据，让它好好干

亮了(2)

真伪书生 2015-06-08回复 13楼
我说的是镜像分析加密的数据，比如说VPN 的数据，https 的部分数据…

亮了(1)

echotxl (3级) 我的密码泄露了，我在考虑要不要改密码。。。 2015-06-08回复 14楼
正常情况下初始的TTL是64，正常收到的TTL是46，跳数为什么是15呢？为啥不是18呢？

亮了(11)

Mr_Onion (1级) 2015-06-08回复 15楼
为啥是15跳？64-46不是18？

亮了(4)

xxx 2015-06-10回复
@ Mr_Onion 是啊我也纳闷

亮了(2)

TSTSTS 2015-06-08回复 16楼
我来笑一下然后默默的看下一篇文章

亮了(1)

123 2015-06-08回复 17楼
现在VPN也归GFW管了？

亮了(2)

softbug 认证作者专栏作者(7级) i am here! 2015-06-08回复 18楼
直接过滤id=12345的tcp包可以吗

亮了(4)

阿斯顿发生地方 2015-06-08回复 19楼
成都黑阔你豪

亮了(1)

rngox (1级) 2015-06-09回复 20楼
两个问题：

1. 如何抓取查看服务端收到的数据包？

2. 看两张截图，为什么服务端收到的正常数据包TTL=50，而客户端收到的正常TTL=46？

亮了(1)

ysc3839 2017-07-23回复
@ rngox 在自己服务器上抓包

亮了(0)

rockway (1级) 2015-06-09回复 21楼
門鈴響了，有您的快遞

亮了(3)

onlytest 2015-06-12回复 22楼
IPSec

亮了(0)

morris2600 2015-06-19回复 23楼
GFW发的IP ID一直是12345吗？这个有点弱吧

亮了(1)
昵称
请输入昵称
必须您当前尚未登录。登陆？注册邮箱
请输入邮箱地址
必须（保密）表情插图
有人回复时邮件通知我

Zooood

这家伙太懒，还未填写个人描述！

1
文章数
0
评论数
最近文章
记一次对GFW防火墙的探究
2015.06.08

浏览更多
相关阅读
如何使用RDP跳过网络隔离？SDL中的密码学应用APT追踪 | 尼日利亚黑客组织再起花式攻击狂砸百亿美金，黑产半路截胡，视频三巨头被迫上演“抢钱大战”如何通过VOIP内网评估获取域管理员权限？
特别推荐

关注我们分享每日精选文章

活动预告
11月

FreeBuf精品公开课·双11学习狂欢节 | 给努力的你打打气
已结束
10月

【16课时-连载中】挖掘CVE不是梦（系列课程2）
已结束
10月

【首节课仅需1元】挖掘CVE不是梦
已结束
9月

gfw攻击

文章评论