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

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

《对一款国家级内容过滤系统Dos安全缺陷分析.docx》由会员分享，可在线阅读，更多相关《对一款国家级内容过滤系统Dos安全缺陷分析.docx（18页珍藏版）》请在冰点文库上搜索。

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

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

viaGFWBLOGbyGFWBlogon1/7/10

作者：

jianxin  来源：

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

Author:

jianxin[80sec]

EMail:

jianxin#

Site:

Date:

2009-1-2

From:

[目录]

0×00前言

0×01knowit，了解这款内容过滤系统

0×02Hackit，对防火墙类ids的一些安全研究

0×03后话

0×00前言

最近在学习网络基础知识，秉承Hacktolearn的作风，想对学习做个总结就想到分析一些网络设备的安全问题来作为一次总结。

相信对于某款国家级内容过滤系统大家都不陌生，也被称为国家边界防火墙，其本质上只是一款强大的入侵检测系统，并且在某些行为发生时对网络攻击进行实时的联动阻断。

这里对它的作用并不做探讨，对如何绕过它也不做分析，这里仅仅是将它看作一款功能强大的国家级IPS，从技术角度来讨论下这类IPS在关键网络部署时可能存在的一些安全问题以及对普通网站的影响。

0×01knowit，了解这款内容过滤系统

同一般的入侵检测系统或者其他号称网关级别过滤系统类似，它定义了一些策略以阻止某些危险的网络访问，其策略包含静态封禁也包含动态封禁，譬如对于Google和Yahoo类搜索引擎来说，国内用户在使用这些站点时如果触发了敏感的关键词的话，其IP就会被动态封禁一段时间，几分钟之类将不能再使用Google，这里的关键词就是被防火墙所定义的危险行为，譬如拿关键词Freenet/freenet来说，在Google里进行一次搜索请求之后就会发现Google在几分钟之内将不再能被访问，多余所有其他处于国外的服务器效果也是一样。

我分析的整个过程如下:

首先对正常的一次Google访问抓包，可以看到结果如下：

bt~#tcpdump-vv-nn-Shost64.233.189.103andport80

tcpdump:

listeningoneth0,link-typeEN10MB（Ethernet）,capturesize96bytes

22:

39:

26.261092IP（tos0×0,ttl64,id33001,offset0,flags[DF],protoTCP（6）,length60）192.168.1.4.44297>64.233.189.103.80:

S,cksum0xcc0f（correct）,1790346900:

1790346900（0）win5840

22:

39:

26.349797IP（tos0×0,ttl50,id41053,offset0,flags[none],protoTCP（6）,length60）64.233.189.103.80>192.168.1.4.44297:

S,cksum0×3698（correct）,3974796664:

3974796664（0）ack1790346901win5672

22:

39:

26.350452IP（tos0×0,ttl64,id33002,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.44297>64.233.189.103.80:

.,cksum0×79d7（correct）,1790346901:

1790346901（0）ack3974796665win365

22:

39:

36.161454IP（tos0×0,ttl64,id33003,offset0,flags[DF],protoTCP（6）,length67）192.168.1.4.44297>64.233.189.103.80:

P,cksum0xa1a9（correct）,1790346901:

1790346916（15）ack3974796665win365

22:

39:

36.248632IP（tos0×0,ttl50,id41053,offset0,flags[none],protoTCP（6）,length52）64.233.189.103.80>192.168.1.4.44297:

.,cksum0×4a9a（correct）,3974796665:

3974796665（0）ack1790346916win89

22:

39:

37.476626IP（tos0×0,ttl64,id33004,offset0,flags[DF],protoTCP（6）,length53）192.168.1.4.44297>64.233.189.103.80:

P,cksum0×3e36（correct）,1790346916:

1790346917

（1）ack3974796665win365

22:

39:

37.563675IP（tos0×0,ttl50,id41054,offset0,flags[none],protoTCP（6）,length52）64.233.189.103.80>192.168.1.4.44297:

.,cksum0×442e（correct）,3974796665:

3974796665（0）ack1790346917win89

22:

39:

37.611453IP（tos0×0,ttl50,id41055,offset0,flags[none],protoTCP（6）,length1452）64.233.189.103.80>192.168.1.4.44297:

.3974796665:

3974798065（1400）ack1790346917win89

22:

39:

37.611545IP（tos0×0,ttl64,id33005,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.44297>64.233.189.103.80:

.,cksum0×3cb3（correct）,1790346917:

1790346917（0）ack3974798065win546

22:

39:

37.624333IP（tos0×0,ttl50,id41056,offset0,flags[none],protoTCP（6）,length1452）64.233.189.103.80>192.168.1.4.44297:

.3974798065:

3974799465（1400）ack1790346917win89

22:

39:

37.624364IP（tos0×0,ttl64,id33006,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.44297>64.233.189.103.80:

.,cksum0×3683（correct）,1790346917:

1790346917（0）ack3974799465win727

22:

39:

37.642937IP（tos0×0,ttl50,id41057,offset0,flags[none],protoTCP（6）,length1452）64.233.189.103.80>192.168.1.4.44297:

.3974799465:

3974800865（1400）ack1790346917win89

22:

39:

37.642953IP（tos0×0,ttl64,id33007,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.44297>64.233.189.103.80:

.,cksum0×3051（correct）,1790346917:

1790346917（0）ack3974800865win908

22:

39:

37.646286IP（tos0×0,ttl50,id41058,offset0,flags[none],protoTCP（6）,length532）64.233.189.103.80>192.168.1.4.44297:

P3974800865:

3974801345（480）ack1790346917win89

22:

39:

37.646302IP（tos0×0,ttl64,id33008,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.44297>64.233.189.103.80:

.,cksum0×2dc1（correct）,1790346917:

1790346917（0）ack3974801345win1083

22:

39:

37.717617IP（tos0×0,ttl50,id41059,offset0,flags[none],protoTCP（6）,length1452）64.233.189.103.80>192.168.1.4.44297:

.3974801345:

3974802745（1400）ack1790346917win89

22:

39:

37.717634IP（tos0×0,ttl64,id33009,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.44297>64.233.189.103.80:

.,cksum0×2713（correct）,1790346917:

1790346917（0）ack3974802745win1264

22:

39:

37.736610IP（tos0×0,ttl50,id41060,offset0,flags[none],protoTCP（6）,length1452）64.233.189.103.80>192.168.1.4.44297:

.3974802745:

3974804145（1400）ack1790346917win89

22:

39:

37.736645IP（tos0×0,ttl64,id33010,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.44297>64.233.189.103.80:

.,cksum0×20e1（correct）,1790346917:

1790346917（0）ack3974804145win1445

22:

39:

37.755088IP（tos0×0,ttl50,id41061,offset0,flags[none],protoTCP（6）,length1449）64.233.189.103.80>192.168.1.4.44297:

P3974804145:

3974805542（1397）ack1790346917win89

22:

39:

37.755107IP（tos0×0,ttl64,id33011,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.44297>64.233.189.103.80:

.,cksum0×1ab2（correct）,1790346917:

1790346917（0）ack3974805542win1626

我们可以看到完整的一次请求过程，先是三次握手，然后是发数据包以及服务器和客户端之间的完整交互，从这里我们可以识别出Google服务器的一些指纹特征，譬如未设置不分片标志，TTL值比较恒定为50等等。

那么当一次非法的请求发生时，情况会是怎么样的呢？

譬如在Google里搜索会被封禁的关键词freenet的时候，结果如下：

bt~#nc-vv64.233.189.10380

hkg01s01-in-[64.233.189.103]80（http）open

GET/?

q=freenetHTTP/1.1

sent26,rcvd0

bt~#

可以看到一发送非法的请求之后Google就主动断开了链接，整个过程的网络抓包如下：

bt~#tcpdump-vv-nn-Shost64.233.189.103andport80

tcpdump:

listeningoneth0,link-typeEN10MB（Ethernet）,capturesize96bytes

22:

54:

15.744058IP（tos0×0,ttl64,id36724,offset0,flags[DF],protoTCP（6）,length60）192.168.1.4.42909>64.233.189.103.80:

S,cksum0xd712（correct）,2729633795:

2729633795（0）win5840

22:

54:

15.831374IP（tos0×0,ttl50,id12868,offset0,flags[none],protoTCP（6）,length60）64.233.189.103.80>192.168.1.4.42909:

S,cksum0×9163（correct）,1209516567:

1209516567（0）ack2729633796win5672

22:

54:

15.831408IP（tos0×0,ttl64,id36725,offset0,flags[DF],protoTCP（6）,length52）192.168.1.4.42909>64.233.189.103.80:

.,cksum0xd4a3（correct）,2729633796:

2729633796（0）ack1209516568win365

22:

54:

31.619002IP（tos0×0,ttl64,id36726,offset0,flags[DF],protoTCP（6）,length77）192.168.1.4.42909>64.233.189.103.80:

P,cksum0xd6e1（correct）,2729633796:

2729633821（25）ack1209516568win365

22:

54:

31.727889IP（tos0×0,ttl50,id12868,offset0,flags[none],protoTCP（6）,length52）64.233.189.103.80>192.168.1.4.42909:

.,cksum0×8867（correct）,1209516568:

1209516568（0）ack2729633821win89

22:

54:

32.065444IP（tos0×0,ttl64,id36727,offset0,flags[DF],protoTCP（6）,length53）192.168.1.4.42909>64.233.189.103.80:

P,cksum0×7cdb（correct）,2729633821:

2729633822

（1）ack1209516568win365

22:

54:

32.148169IP（tos0×0,ttl53,id64,offset0,flags[none],protoTCP（6）,length40）64.233.189.103.80>192.168.1.4.42909:

R,cksum0×3399（correct）,1209516568:

1209516568（0）win2605

22:

54:

32.151504IP（tos0×0,ttl50,id12869,offset0,flags[none],protoTCP（6）,length52）64.233.189.103.80>192.168.1.4.42909:

.,cksum0×863a（correct）,1209516568:

1209516568（0）ack2729633822win89

22:

54:

32.151840IP（tos0×0,ttl64,id0,offset0,flags[DF],protoTCP（6）,length40）192.168.1.4.42909>64.233.189.103.80:

R,cksum0xbd24（correct）,2729633822:

2729633822（0）win0

22:

54:

32.153474IP（tos0×0,ttl53,id64,offset0,flags[none],protoTCP（6）,length40）64.233.189.103.80>192.168.1.4.42909:

R,cksum0×1779（correct）,1209516568:

1209516568（0）win9805

可以看到的是，用户在发送完push包之后，Google的服务器也就是64.233.189.103返回了ack数据包表示收到了该请求，并且回复的ack包的序列号跟预期的一致，这里有两次push是因为我用nc提交的，加的回车会单独发一个过去。

这样理论上服务器应该马上会回复一个push包响应我们前面的请求，但是结果我们收到了一个意外的rst包如下：

22:

54:

32.148169IP（tos0×0,ttl53,id64,offset0,flags[none],protoTCP（6）,length40）64.233.189.103.80>192.168.1.4.42909:

R,cksum0×3399（correct）,1209516568:

1209516568（0）win2605

并且该诡异的tcp包还发了两次，然后我们的客户端就以为服务器重置了该链接，这个时候服务器还老老实实的回复了一个对前面的push包的确认包，不过这个包已经被前面莫名其妙的rst包用掉了，并且客户端也按要求重置了链接，所以就回复了一个rst包：

22:

54:

32.151840IP（tos0×0,ttl64,id0,offset0,flags[DF],protoTCP（6）,length40）192.168.1.4.42909>64.233.189.103.80:

R,cksum0xbd24（correct）,2729633822:

2729633822（0）win0

恩，这个tcp链接到这里玩完了。

那么这个莫名其妙的rst包是谁发出来的呢？

首先来确认下是不是Google自己抽风发出来的吧。

注意最上面提到的正常情况下来自Google返回的包的指纹，我们可以看到如下几个地方发生了明显的变化：

22:

54:

15.831374IP（tos0×0,ttl50,id12868,offset0,flags[none],protoTCP（6）,length60）64.233.189.103.80>192.168.1.4.42909:

S,cksum0×9163（correct）,1209516567:

1209516567（0）ack2729633796win5672

22:

54:

32.148169IP（tos0×0,ttl53,id64,offset0,flags[none],protoTCP（6）,length40）64.233.189.103.80>192.168.1.4.42909:

R,cksum0×3399（correct）,1209516568:

1209516568（0）win2605

首先ttl发生了变化，这在默认情况下基本代表了设备在网络上的位置，另外ID在系统内被用来识别一个tcp包，明显的差异过大，然后Google的服务器还返回了一堆可选字段的内容，但是那个怪异的rst包完全没有这个特征，通过这些基本可以确认这个rst包并非来自于真正的Google服务器，通过多抓几次数据包就可以证明这个结论。

那么这个设备是出于哪个位置呢？

我们简单的tracert下看看结果：

tracerouteto64.233.189.103（64.233.189.103）,30hopsmax,38bytepackets

1localhost（192.168.1.1）4.667ms1.949ms1.650ms

2114.249.208.1（114.249.208.1）28.304ms28.438ms34.123ms

3125.35.65.97（125.35.65.97）26.429ms27.363ms25.844ms

4bt-227-（202.106.227.109）27.641ms26.971ms27.268ms

561.148.153.121（61.148.153.121）26.936ms27.722ms27.802ms

6123.126.0.121（123.126.0.121）27.675ms26.996ms28.620ms

7219.158.4.94（219.158.4.94）82.732ms82.175ms82.608ms

8219.158.3.66（219.158.3.66）69.978ms70.491ms136.986ms

9219.158.3.130（219.158.3.130）77.807ms87.424ms446.165ms

10219.158.32.230（219.1