对一款国家级内容过滤系统Dos安全缺陷分析.docx

1、 对一款国家级内容过滤系统对一款国家级内容过滤系统 Dos 安全缺陷分析安全缺陷分析 对一款国家级内容过滤系统对一款国家级内容过滤系统 Dos 安全缺陷分析安全缺陷分析 via GFW BLOG by GFW Blog on 1/7/10 作者：jianxin 来源：http:/ 对某款国家级内容过滤系统 Dos 安全缺陷分析 Author:jianxin 80sec EMail:jianxin# Site:http:/ Date:2009-1-2 From:http:/ 目录 0 00 前言 0 01 know it，了解这款内容过滤系统 0 02 Hack it，对防火墙类 ids的一些安

2、全研究 0 03 后话 0 00 前言 最近在学习网络基础知识，秉承 Hack to learn 的作风，想对学习做个总结就想到分析一些网络设备的安全问题来作为一次总结。相信对于某款国家级内容过滤系统大家都不陌生，也被称为国家边界防 火墙，其本质上只是一款强大的入侵检测系统，并且在某些行为发生时对网络攻击进行实时的联动阻断。这里对它的作用并不做探讨，对如何绕过它也不做分析，这 里仅仅是将它看作一款功能强大的国家级 IPS，从技术角度来讨论下这类 IPS 在关键网络部署时可能存在的一些安全问题以及对普通网站的影响。0 01 know it，了解这款内容过滤系统 同一般的入侵检测系统或者其他号称网

3、关级别过滤系统类似，它定义了一些策略以阻止某些危险的网络访问，其策略包含静态封禁也包含动态封禁，譬如对于 Google 和 Yahoo 类搜索引擎来说，国内用户在使用这些站点时如果触发了敏感的关键词的话，其 IP就会被动 态封禁一段时间，几分钟之类将不能再使用 Google，这里的关键词就是被防火墙所定义的危险行为，譬如拿关键词 Freenet/freenet 来说，在 Google 里进行一次搜索请求之后就会 发现 Google 在几分钟之内将不再能被访问，多余所有其他处于国外的服务器效果也是一样。我分析的整个过程如下:首先对正常的一次 Google 访问抓包，可以看到结果如下：bt#tcp

4、dump-vv-nn-S host 64.233.189.103 and port 80 tcpdump:listening on eth0,link-type EN10MB(Ethernet),capture size 96 bytes 22:39:26.261092 IP(tos 0 0,ttl 64,id 33001,offset 0,flags DF,proto TCP(6),length 60)192.168.1.4.44297 64.233.189.103.80:S,cksum 0 xcc0f(correct),1790346900:1790346900(0)win 5840 22

5、:39:26.349797 IP(tos 0 0,ttl 50,id 41053,offset 0,flags none,proto TCP(6),length 60)64.233.189.103.80 192.168.1.4.44297:S,cksum 0 3698(correct),3974796664:3974796664(0)ack 1790346901 win 5672 22:39:26.350452 IP(tos 0 0,ttl 64,id 33002,offset 0,flags DF,proto TCP(6),length 52)192.168.1.4.44297 64.233

6、.189.103.80:.,cksum 0 79d7(correct),1790346901:1790346901(0)ack 3974796665 win 365 22:39:36.161454 IP(tos 0 0,ttl 64,id 33003,offset 0,flags DF,proto TCP(6),length 67)192.168.1.4.44297 64.233.189.103.80:P,cksum 0 xa1a9(correct),1790346901:1790346916(15)ack 3974796665 win 365 22:39:36.248632 IP(tos 0

7、 0,ttl 50,id 41053,offset 0,flags none,proto TCP(6),length 52)64.233.189.103.80 192.168.1.4.44297:.,cksum 0 4a9a(correct),3974796665:3974796665(0)ack 1790346916 win 89 22:39:37.476626 IP(tos 0 0,ttl 64,id 33004,offset 0,flags DF,proto TCP(6),length 53)192.168.1.4.44297 64.233.189.103.80:P,cksum 0 3e

8、36(correct),1790346916:1790346917(1)ack 3974796665 win 365 22:39:37.563675 IP(tos 0 0,ttl 50,id 41054,offset 0,flags none,proto TCP(6),length 52)64.233.189.103.80 192.168.1.4.44297:.,cksum 0 442e(correct),3974796665:3974796665(0)ack 1790346917 win 89 22:39:37.611453 IP(tos 0 0,ttl 50,id 41055,offset

9、 0,flags none,proto TCP(6),length 1452)64.233.189.103.80 192.168.1.4.44297:.3974796665:3974798065(1400)ack 1790346917 win 89 22:39:37.611545 IP(tos 0 0,ttl 64,id 33005,offset 0,flags DF,proto TCP(6),length 52)192.168.1.4.44297 64.233.189.103.80:.,cksum 0 3cb3(correct),1790346917:1790346917(0)ack 397

10、4798065 win 546 22:39:37.624333 IP(tos 0 0,ttl 50,id 41056,offset 0,flags none,proto TCP(6),length 1452)64.233.189.103.80 192.168.1.4.44297:.3974798065:3974799465(1400)ack 1790346917 win 89 22:39:37.624364 IP(tos 0 0,ttl 64,id 33006,offset 0,flags DF,proto TCP(6),length 52)192.168.1.4.44297 64.233.1

11、89.103.80:.,cksum 0 3683(correct),1790346917:1790346917(0)ack 3974799465 win 727 22:39:37.642937 IP(tos 0 0,ttl 50,id 41057,offset 0,flags none,proto TCP(6),length 1452)64.233.189.103.80 192.168.1.4.44297:.3974799465:3974800865(1400)ack 1790346917 win 89 22:39:37.642953 IP(tos 0 0,ttl 64,id 33007,of

12、fset 0,flags DF,proto TCP(6),length 52)192.168.1.4.44297 64.233.189.103.80:.,cksum 0 3051(correct),1790346917:1790346917(0)ack 3974800865 win 908 22:39:37.646286 IP(tos 0 0,ttl 50,id 41058,offset 0,flags none,proto TCP(6),length 532)64.233.189.103.80 192.168.1.4.44297:P 3974800865:3974801345(480)ack

13、 1790346917 win 89 22:39:37.646302 IP(tos 0 0,ttl 64,id 33008,offset 0,flags DF,proto TCP(6),length 52)192.168.1.4.44297 64.233.189.103.80:.,cksum 0 2dc1(correct),1790346917:1790346917(0)ack 3974801345 win 1083 22:39:37.717617 IP(tos 0 0,ttl 50,id 41059,offset 0,flags none,proto TCP(6),length 1452)6

14、4.233.189.103.80 192.168.1.4.44297:.3974801345:3974802745(1400)ack 1790346917 win 89 22:39:37.717634 IP(tos 0 0,ttl 64,id 33009,offset 0,flags DF,proto TCP(6),length 52)192.168.1.4.44297 64.233.189.103.80:.,cksum 0 2713(correct),1790346917:1790346917(0)ack 3974802745 win 1264 22:39:37.736610 IP(tos

15、0 0,ttl 50,id 41060,offset 0,flags none,proto TCP(6),length 1452)64.233.189.103.80 192.168.1.4.44297:.3974802745:3974804145(1400)ack 1790346917 win 89 22:39:37.736645 IP(tos 0 0,ttl 64,id 33010,offset 0,flags DF,proto TCP(6),length 52)192.168.1.4.44297 64.233.189.103.80:.,cksum 0 20e1(correct),17903

16、46917:1790346917(0)ack 3974804145 win 1445 22:39:37.755088 IP(tos 0 0,ttl 50,id 41061,offset 0,flags none,proto TCP(6),length 1449)64.233.189.103.80 192.168.1.4.44297:P 3974804145:3974805542(1397)ack 1790346917 win 89 22:39:37.755107 IP(tos 0 0,ttl 64,id 33011,offset 0,flags DF,proto TCP(6),length 5

17、2)192.168.1.4.44297 64.233.189.103.80:.,cksum 0 1ab2(correct),1790346917:1790346917(0)ack 3974805542 win 1626 我们可以看到完整的一次请求过程，先是三次握手，然后是发数据包以及服务器和客户端之间的完整交互，从这里我们可以识别出Google 服务器的一些指纹特征，譬如未设置不分片标志，TTL值比较恒定为 50 等等。那么当一次非法的请求发生时，情况会是怎么样的呢？譬如在 Google里搜索会被封禁的关键词 freenet 的时候，结果如下：bt#nc-vv 64.233.189.103 8

18、0 hkg01s01-in- 64.233.189.103 80(http)open GET/?q=freenet HTTP/1.1 sent 26,rcvd 0 bt#可以看到一发送非法的请求之后 Google 就主动断开了链接，整个过程的网络抓包如下：bt#tcpdump-vv-nn-S host 64.233.189.103 and port 80 tcpdump:listening on eth0,link-type EN10MB(Ethernet),capture size 96 bytes 22:54:15.744058 IP(tos 0 0,ttl 64,id 36724,off

19、set 0,flags DF,proto TCP(6),length 60)192.168.1.4.42909 64.233.189.103.80:S,cksum 0 xd712(correct),2729633795:2729633795(0)win 5840 22:54:15.831374 IP(tos 0 0,ttl 50,id 12868,offset 0,flags none,proto TCP(6),length 60)64.233.189.103.80 192.168.1.4.42909:S,cksum 0 9163(correct),1209516567:1209516567(

20、0)ack 2729633796 win 5672 22:54:15.831408 IP(tos 0 0,ttl 64,id 36725,offset 0,flags DF,proto TCP(6),length 52)192.168.1.4.42909 64.233.189.103.80:.,cksum 0 xd4a3(correct),2729633796:2729633796(0)ack 1209516568 win 365 22:54:31.619002 IP(tos 0 0,ttl 64,id 36726,offset 0,flags DF,proto TCP(6),length 7

21、7)192.168.1.4.42909 64.233.189.103.80:P,cksum 0 xd6e1(correct),2729633796:2729633821(25)ack 1209516568 win 365 22:54:31.727889 IP(tos 0 0,ttl 50,id 12868,offset 0,flags none,proto TCP(6),length 52)64.233.189.103.80 192.168.1.4.42909:.,cksum 0 8867(correct),1209516568:1209516568(0)ack 2729633821 win

22、89 22:54:32.065444 IP(tos 0 0,ttl 64,id 36727,offset 0,flags DF,proto TCP(6),length 53)192.168.1.4.42909 64.233.189.103.80:P,cksum 0 7cdb(correct),2729633821:2729633822(1)ack 1209516568 win 365 22:54:32.148169 IP(tos 0 0,ttl 53,id 64,offset 0,flags none,proto TCP(6),length 40)64.233.189.103.80 192.1

23、68.1.4.42909:R,cksum 0 3399(correct),1209516568:1209516568(0)win 2605 22:54:32.151504 IP(tos 0 0,ttl 50,id 12869,offset 0,flags none,proto TCP(6),length 52)64.233.189.103.80 192.168.1.4.42909:.,cksum 0 863a(correct),1209516568:1209516568(0)ack 2729633822 win 89 22:54:32.151840 IP(tos 0 0,ttl 64,id 0

24、,offset 0,flags DF,proto TCP (6),length 40)192.168.1.4.42909 64.233.189.103.80:R,cksum 0 xbd24(correct),2729633822:2729633822(0)win 0 22:54:32.153474 IP(tos 0 0,ttl 53,id 64,offset 0,flags none,proto TCP(6),length 40)64.233.189.103.80 192.168.1.4.42909:R,cksum 0 1779(correct),1209516568:1209516568(0

25、)win 9805 可以看到的是，用户在发送完 push 包之后，Google 的服务器也就是 64.233.189.103返回了 ack 数据包表示收到了该请求，并且回复的 ack包的序列号跟预期的一致，这里有两次 push 是因为我用 nc 提交的，加的回车会单独发一个过去。这样理论上服务器应该马上会回复一个 push包响应 我们前面的请求，但是结果我们收到了一个意外的 rst 包如下：22:54:32.148169 IP(tos 0 0,ttl 53,id 64,offset 0,flags none,proto TCP(6),length 40)64.233.189.103.80 19

26、2.168.1.4.42909:R,cksum 0 3399(correct),1209516568:1209516568(0)win 2605 并且该诡异的 tcp 包还发了两次，然后我们的客户端就以为服务器重置了该链接，这个时候服务器还老老实实的回复了一个对前面的push 包的确认包，不过这个包已经被前面莫名其妙的 rst 包用掉了，并且客户端也按要求重置了链接，所以就回复了一个 rst 包：22:54:32.151840 IP(tos 0 0,ttl 64,id 0,offset 0,flags DF,proto TCP(6),length 40)192.168.1.4.42909 64

27、.233.189.103.80:R,cksum 0 xbd24(correct),2729633822:2729633822(0)win 0 恩，这个 tcp链接到这里玩完了。那么这个莫名其妙的 rst 包是谁发出来的呢？首先来确认下是不是 Google 自己抽风发出来的吧。注意最上面提到的正常情况下来自 Google 返回的包的指纹，我们可以看到如下几个地方发生了明显的变化：22:54:15.831374 IP(tos 0 0,ttl 50,id 12868,offset 0,flags none,proto TCP(6),length 60)64.233.189.103.80 192.16

28、8.1.4.42909:S,cksum 0 9163(correct),1209516567:1209516567(0)ack 2729633796 win 5672 22:54:32.148169 IP(tos 0 0,ttl 53,id 64,offset 0,flags none,proto TCP(6),length 40)64.233.189.103.80 192.168.1.4.42909:R,cksum 0 3399(correct),1209516568:1209516568(0)win 2605 首先 ttl 发生了变化，这在默认情况下基本代表了设备在网络上的位置，另外 ID

29、 在系统内被用来识别一个 tcp 包，明显的差异过大，然后 Google 的服务 器还返回了一堆可选字段的内容，但是那个怪异的 rst 包完全没有这个特征，通过这些基本可以确认这个 rst 包并非来自于真正的 Google 服务器，通过多 抓几次数据包就可以证明这个结论。那么这个设备是出于哪个位置呢？我们简单的 tracert下看看结果：traceroute to 64.233.189.103(64.233.189.103),30 hops max,38 byte packets 1 localhost(192.168.1.1)4.667 ms 1.949 ms 1.650 ms 2 114.

30、249.208.1(114.249.208.1)28.304 ms 28.438 ms 34.123 ms 3 125.35.65.97(125.35.65.97)26.429 ms 27.363 ms 25.844 ms 4 bt-227-(202.106.227.109)27.641 ms 26.971 ms 27.268 ms 5 61.148.153.121(61.148.153.121)26.936 ms 27.722 ms 27.802 ms 6 123.126.0.121(123.126.0.121)27.675 ms 26.996 ms 28.620 ms 7 219.158.

31、4.94(219.158.4.94)82.732 ms 82.175 ms 82.608 ms 8 219.158.3.66(219.158.3.66)69.978 ms 70.491 ms 136.986 ms 9 219.158.3.130(219.158.3.130)77.807 ms 87.424 ms 446.165 ms 10 219.158.32.230(219.158.32.230)413.888 ms 87.384 ms 86.614 ms 11 64.233.175.207(64.233.175.207)114.188 ms 79.037 ms 113.107 ms 12

32、209.85.241.56(209.85.241.56)87.721 ms 88.063 ms 87.341 ms 13 66.249.94.6(66.249.94.6)87.068 ms 99.377 ms 94.140 ms 14 hkg01s01-in-(64.233.189.103)86.094 ms 85.901 ms 86.429 ms ttl是数据包在网络上的存活时间，每经过一个路由器这个 ttl就会减 1，可以避免某些数据包无止境的在网络上传输，所以可以被用来确认设备离我们主机在 网络上的跳数和距离。我们在抓包的时候可以发现我们默认发出去的数据包 ttl是 64，我这里用的是

33、linux 的系统，一般的网络设备初始值为 64，128，255，linux 类系统的初始值一般都为 64，所以这里我们可以看到 Google 返回值是 50，这是可以确认的，因为可以看到我们到 google有 14 跳，一般 linux 服务器的初始值为 64，到我们这正好是 50。那么这个 ttl=53 的异常包是在哪呢？64-13=11，哦，应该是 在 11 跳左右，到路由上链上找找就发现可能是 64.233.175.207 这个 IP 发的，但是去查却会发现这个 ip 是Google 的，米国人民劫持我们的 数据包不让访问 Google？不太靠谱啊，那么很可能是从第 10 旁路出去的包，查查第 10 跳发现是网通骨干网的，这理论上就是可能的了，当然，这之前的节 点都有可能，但是最有可能的应该还是这个节点，因为这个节点可以监视所有出口 的流量嘛！再来分析下是如何拒绝掉我们的链接的，该