对一款国家级内容过滤系统Dos安全缺陷分析.docx
《对一款国家级内容过滤系统Dos安全缺陷分析.docx》由会员分享,可在线阅读,更多相关《对一款国家级内容过滤系统Dos安全缺陷分析.docx(18页珍藏版)》请在冰豆网上搜索。
![对一款国家级内容过滤系统Dos安全缺陷分析.docx](https://file1.bdocx.com/fileroot1/2023-4/27/06db1048-b5b4-4569-a82b-8df9a53236cb/06db1048-b5b4-4569-a82b-8df9a53236cb1.gif)
对一款国家级内容过滤系统对一款国家级内容过滤系统Dos安全缺陷分析安全缺陷分析对一款国家级内容过滤系统对一款国家级内容过滤系统Dos安全缺陷分析安全缺陷分析viaGFWBLOGbyGFWBlogon1/7/10作者:
jianxin来源:
http:
/对某款国家级内容过滤系统Dos安全缺陷分析Author:
jianxin80secEMail:
jianxin#Site:
http:
/Date:
2009-1-2From:
http:
/目录000前言001knowit,了解这款内容过滤系统002Hackit,对防火墙类ids的一些安全研究003后话000前言最近在学习网络基础知识,秉承Hacktolearn的作风,想对学习做个总结就想到分析一些网络设备的安全问题来作为一次总结。
相信对于某款国家级内容过滤系统大家都不陌生,也被称为国家边界防火墙,其本质上只是一款强大的入侵检测系统,并且在某些行为发生时对网络攻击进行实时的联动阻断。
这里对它的作用并不做探讨,对如何绕过它也不做分析,这里仅仅是将它看作一款功能强大的国家级IPS,从技术角度来讨论下这类IPS在关键网络部署时可能存在的一些安全问题以及对普通网站的影响。
001knowit,了解这款内容过滤系统同一般的入侵检测系统或者其他号称网关级别过滤系统类似,它定义了一些策略以阻止某些危险的网络访问,其策略包含静态封禁也包含动态封禁,譬如对于Google和Yahoo类搜索引擎来说,国内用户在使用这些站点时如果触发了敏感的关键词的话,其IP就会被动态封禁一段时间,几分钟之类将不能再使用Google,这里的关键词就是被防火墙所定义的危险行为,譬如拿关键词Freenet/freenet来说,在Google里进行一次搜索请求之后就会发现Google在几分钟之内将不再能被访问,多余所有其他处于国外的服务器效果也是一样。
我分析的整个过程如下:
首先对正常的一次Google访问抓包,可以看到结果如下:
bt#tcpdump-vv-nn-Shost64.233.189.103andport80tcpdump:
listeningoneth0,link-typeEN10MB(Ethernet),capturesize96bytes22:
39:
26.261092IP(tos00,ttl64,id33001,offset0,flagsDF,protoTCP(6),length60)192.168.1.4.4429764.233.189.103.80:
S,cksum0xcc0f(correct),1790346900:
1790346900(0)win584022:
39:
26.349797IP(tos00,ttl50,id41053,offset0,flagsnone,protoTCP(6),length60)64.233.189.103.80192.168.1.4.44297:
S,cksum03698(correct),3974796664:
3974796664(0)ack1790346901win567222:
39:
26.350452IP(tos00,ttl64,id33002,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4429764.233.189.103.80:
.,cksum079d7(correct),1790346901:
1790346901(0)ack3974796665win36522:
39:
36.161454IP(tos00,ttl64,id33003,offset0,flagsDF,protoTCP(6),length67)192.168.1.4.4429764.233.189.103.80:
P,cksum0xa1a9(correct),1790346901:
1790346916(15)ack3974796665win36522:
39:
36.248632IP(tos00,ttl50,id41053,offset0,flagsnone,protoTCP(6),length52)64.233.189.103.80192.168.1.4.44297:
.,cksum04a9a(correct),3974796665:
3974796665(0)ack1790346916win8922:
39:
37.476626IP(tos00,ttl64,id33004,offset0,flagsDF,protoTCP(6),length53)192.168.1.4.4429764.233.189.103.80:
P,cksum03e36(correct),1790346916:
1790346917
(1)ack3974796665win36522:
39:
37.563675IP(tos00,ttl50,id41054,offset0,flagsnone,protoTCP(6),length52)64.233.189.103.80192.168.1.4.44297:
.,cksum0442e(correct),3974796665:
3974796665(0)ack1790346917win8922:
39:
37.611453IP(tos00,ttl50,id41055,offset0,flagsnone,protoTCP(6),length1452)64.233.189.103.80192.168.1.4.44297:
.3974796665:
3974798065(1400)ack1790346917win8922:
39:
37.611545IP(tos00,ttl64,id33005,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4429764.233.189.103.80:
.,cksum03cb3(correct),1790346917:
1790346917(0)ack3974798065win54622:
39:
37.624333IP(tos00,ttl50,id41056,offset0,flagsnone,protoTCP(6),length1452)64.233.189.103.80192.168.1.4.44297:
.3974798065:
3974799465(1400)ack1790346917win8922:
39:
37.624364IP(tos00,ttl64,id33006,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4429764.233.189.103.80:
.,cksum03683(correct),1790346917:
1790346917(0)ack3974799465win72722:
39:
37.642937IP(tos00,ttl50,id41057,offset0,flagsnone,protoTCP(6),length1452)64.233.189.103.80192.168.1.4.44297:
.3974799465:
3974800865(1400)ack1790346917win8922:
39:
37.642953IP(tos00,ttl64,id33007,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4429764.233.189.103.80:
.,cksum03051(correct),1790346917:
1790346917(0)ack3974800865win90822:
39:
37.646286IP(tos00,ttl50,id41058,offset0,flagsnone,protoTCP(6),length532)64.233.189.103.80192.168.1.4.44297:
P3974800865:
3974801345(480)ack1790346917win8922:
39:
37.646302IP(tos00,ttl64,id33008,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4429764.233.189.103.80:
.,cksum02dc1(correct),1790346917:
1790346917(0)ack3974801345win108322:
39:
37.717617IP(tos00,ttl50,id41059,offset0,flagsnone,protoTCP(6),length1452)64.233.189.103.80192.168.1.4.44297:
.3974801345:
3974802745(1400)ack1790346917win8922:
39:
37.717634IP(tos00,ttl64,id33009,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4429764.233.189.103.80:
.,cksum02713(correct),1790346917:
1790346917(0)ack3974802745win126422:
39:
37.736610IP(tos00,ttl50,id41060,offset0,flagsnone,protoTCP(6),length1452)64.233.189.103.80192.168.1.4.44297:
.3974802745:
3974804145(1400)ack1790346917win8922:
39:
37.736645IP(tos00,ttl64,id33010,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4429764.233.189.103.80:
.,cksum020e1(correct),1790346917:
1790346917(0)ack3974804145win144522:
39:
37.755088IP(tos00,ttl50,id41061,offset0,flagsnone,protoTCP(6),length1449)64.233.189.103.80192.168.1.4.44297:
P3974804145:
3974805542(1397)ack1790346917win8922:
39:
37.755107IP(tos00,ttl64,id33011,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4429764.233.189.103.80:
.,cksum01ab2(correct),1790346917:
1790346917(0)ack3974805542win1626我们可以看到完整的一次请求过程,先是三次握手,然后是发数据包以及服务器和客户端之间的完整交互,从这里我们可以识别出Google服务器的一些指纹特征,譬如未设置不分片标志,TTL值比较恒定为50等等。
那么当一次非法的请求发生时,情况会是怎么样的呢?
譬如在Google里搜索会被封禁的关键词freenet的时候,结果如下:
bt#nc-vv64.233.189.10380hkg01s01-in-64.233.189.10380(http)openGET/?
q=freenetHTTP/1.1sent26,rcvd0bt#可以看到一发送非法的请求之后Google就主动断开了链接,整个过程的网络抓包如下:
bt#tcpdump-vv-nn-Shost64.233.189.103andport80tcpdump:
listeningoneth0,link-typeEN10MB(Ethernet),capturesize96bytes22:
54:
15.744058IP(tos00,ttl64,id36724,offset0,flagsDF,protoTCP(6),length60)192.168.1.4.4290964.233.189.103.80:
S,cksum0xd712(correct),2729633795:
2729633795(0)win584022:
54:
15.831374IP(tos00,ttl50,id12868,offset0,flagsnone,protoTCP(6),length60)64.233.189.103.80192.168.1.4.42909:
S,cksum09163(correct),1209516567:
1209516567(0)ack2729633796win567222:
54:
15.831408IP(tos00,ttl64,id36725,offset0,flagsDF,protoTCP(6),length52)192.168.1.4.4290964.233.189.103.80:
.,cksum0xd4a3(correct),2729633796:
2729633796(0)ack1209516568win36522:
54:
31.619002IP(tos00,ttl64,id36726,offset0,flagsDF,protoTCP(6),length77)192.168.1.4.4290964.233.189.103.80:
P,cksum0xd6e1(correct),2729633796:
2729633821(25)ack1209516568win36522:
54:
31.727889IP(tos00,ttl50,id12868,offset0,flagsnone,protoTCP(6),length52)64.233.189.103.80192.168.1.4.42909:
.,cksum08867(correct),1209516568:
1209516568(0)ack2729633821win8922:
54:
32.065444IP(tos00,ttl64,id36727,offset0,flagsDF,protoTCP(6),length53)192.168.1.4.4290964.233.189.103.80:
P,cksum07cdb(correct),2729633821:
2729633822
(1)ack1209516568win36522:
54:
32.148169IP(tos00,ttl53,id64,offset0,flagsnone,protoTCP(6),length40)64.233.189.103.80192.168.1.4.42909:
R,cksum03399(correct),1209516568:
1209516568(0)win260522:
54:
32.151504IP(tos00,ttl50,id12869,offset0,flagsnone,protoTCP(6),length52)64.233.189.103.80192.168.1.4.42909:
.,cksum0863a(correct),1209516568:
1209516568(0)ack2729633822win8922:
54:
32.151840IP(tos00,ttl64,id0,offset0,flagsDF,protoTCP(6),length40)192.168.1.4.4290964.233.189.103.80:
R,cksum0xbd24(correct),2729633822:
2729633822(0)win022:
54:
32.153474IP(tos00,ttl53,id64,offset0,flagsnone,protoTCP(6),length40)64.233.189.103.80192.168.1.4.42909:
R,cksum01779(correct),1209516568:
1209516568(0)win9805可以看到的是,用户在发送完push包之后,Google的服务器也就是64.233.189.103返回了ack数据包表示收到了该请求,并且回复的ack包的序列号跟预期的一致,这里有两次push是因为我用nc提交的,加的回车会单独发一个过去。
这样理论上服务器应该马上会回复一个push包响应我们前面的请求,但是结果我们收到了一个意外的rst包如下:
22:
54:
32.148169IP(tos00,ttl53,id64,offset0,flagsnone,protoTCP(6),length40)64.233.189.103.80192.168.1.4.42909:
R,cksum03399(correct),1209516568:
1209516568(0)win2605并且该诡异的tcp包还发了两次,然后我们的客户端就以为服务器重置了该链接,这个时候服务器还老老实实的回复了一个对前面的push包的确认包,不过这个包已经被前面莫名其妙的rst包用掉了,并且客户端也按要求重置了链接,所以就回复了一个rst包:
22:
54:
32.151840IP(tos00,ttl64,id0,offset0,flagsDF,protoTCP(6),length40)192.168.1.4.4290964.233.189.103.80:
R,cksum0xbd24(correct),2729633822:
2729633822(0)win0恩,这个tcp链接到这里玩完了。
那么这个莫名其妙的rst包是谁发出来的呢?
首先来确认下是不是Google自己抽风发出来的吧。
注意最上面提到的正常情况下来自Google返回的包的指纹,我们可以看到如下几个地方发生了明显的变化:
22:
54:
15.831374IP(tos00,ttl50,id12868,offset0,flagsnone,protoTCP(6),length60)64.233.189.103.80192.168.1.4.42909:
S,cksum09163(correct),1209516567:
1209516567(0)ack2729633796win567222:
54:
32.148169IP(tos00,ttl53,id64,offset0,flagsnone,protoTCP(6),length40)64.233.189.103.80192.168.1.4.42909:
R,cksum03399(correct),1209516568:
1209516568(0)win2605首先ttl发生了变化,这在默认情况下基本代表了设备在网络上的位置,另外ID在系统内被用来识别一个tcp包,明显的差异过大,然后Google的服务器还返回了一堆可选字段的内容,但是那个怪异的rst包完全没有这个特征,通过这些基本可以确认这个rst包并非来自于真正的Google服务器,通过多抓几次数据包就可以证明这个结论。
那么这个设备是出于哪个位置呢?
我们简单的tracert下看看结果:
tracerouteto64.233.189.103(64.233.189.103),30hopsmax,38bytepackets1localhost(192.168.1.1)4.667ms1.949ms1.650ms2114.249.208.1(114.249.208.1)28.304ms28.438ms34.123ms3125.35.65.97(125.35.65.97)26.429ms27.363ms25.844ms4bt-227-(202.106.227.109)27.641ms26.971ms27.268ms561.148.153.121(61.148.153.121)26.936ms27.722ms27.802ms6123.126.0.121(123.126.0.121)27.675ms26.996ms28.620ms7219.158.4.94(219.158.4.94)82.732ms82.175ms82.608ms8219.158.3.66(219.158.3.66)69.978ms70.491ms136.986ms9219.158.3.130(219.158.3.130)77.807ms87.424ms446.165ms10219.158.32.230(219.158.32.230)413.888ms87.384ms86.614ms1164.233.175.207(64.233.175.207)114.188ms79.037ms113.107ms12209.85.241.56(209.85.241.56)87.721ms88.063ms87.341ms1366.249.94.6(66.249.94.6)87.068ms99.377ms94.140ms14hkg01s01-in-(64.233.189.103)86.094ms85.901ms86.429msttl是数据包在网络上的存活时间,每经过一个路由器这个ttl就会减1,可以避免某些数据包无止境的在网络上传输,所以可以被用来确认设备离我们主机在网络上的跳数和距离。
我们在抓包的时候可以发现我们默认发出去的数据包ttl是64,我这里用的是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跳发现是网通骨干网的,这理论上就是可能的了,当然,这之前的节点都有可能,但是最有可能的应该还是这个节点,因为这个节点可以监视所有出口的流量嘛!
再来分析下是如何拒绝掉我们的链接的,该