还剩14页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
暗藏通道看网络平安电脑资料通过本文的tunnel技术同时逃过了防火墙的屏蔽以及系统的追踪试验,我们可以看到网络平安仅仅依靠某种或某几种手段是不可靠的,同时对平安系统的盲目性依赖往往会造成宏大的平安隐患,什么是暗藏通道什么是局域网平安,系统管理员怎样才能保障局域网的平安?这是一个不断变化的平安概念,很长的一个时期以来,在局域网与外界互联处放置一个防火墙,严格控制开放的端口,就能在很大程度上掌握平安的主动权,方便的控制网内外用户所能使用的效劳比方,在防火墙上仅仅开放80,53两个端口,那么无论是内部还是外面的恶意人士都将无法使用一些已经比拟危险的效劳但要注意一点,防火墙在某种意义上是很愚蠢的,管理员对防火墙的过分依赖以及从而产生的懈怠情绪将不可防止的形成平安上的重大隐患,作为一个证明,通道技术就是一个很好的例子,这也是本文要讨论的那么什么是通道呢?这里通道,是指一种绕过防火墙端口屏蔽的通讯方式防火墙两端的数据包封装在防火墙所允许通过的数据包类型或是端口上,然后穿过防火墙与对端通讯,当封装的数据包到达目的地时,再将数据包复原,并将复原后的数据包交送到相应的效劳上举例如下A主机系统在防火墙之后,受防火墙保护,防火墙配置的访问控制原那么是只允许80端口的数据进出,B主机系统在防火墙之外,是开放的如今假设需要从A系统Tel到B系统上去,怎么办?使用正常的tel肯定是不可能了,但我们知道可用的只有80端口,那么这个时候使用tunnel通道,就是一个好的方法,思路如下在A机器上起一个tunnel的client端,让它侦听本机的一个不被使用的任意指定端口,如1234,同时将1234端口上的数据指引到远端(B机)的80端口上(注意,是80端口,防火墙允许通过),然后在B机上起一个server,同样挂接在80端口上,同时指引80端口的client的转发到本机的tel效劳端口23,这样就ok了如今在A机上tel本机端口1234,根据刚刚的设置数据包会被转发到目的端口为80的B机,因为防火墙允许通过80端口的数据,因此数据包畅通的穿过防火墙,到达B机此时B机在80端口侦听的进程收到A的数据包,会将数据包复原,再交还给tel进程当数据包需要由B到A返回时,将由80端口再回送,同样可以顺利的通过防火墙实际上tunnel概念已经产生很久了,而且很有可能读者使用过类似的技术,比方下面的网址.-tunnel.它是一个专业提供tunnel效劳的公司,通过他们的在线tunnelserver局域网内的用户可以使用被防火墙所屏蔽的ICQ,E-MAIL,pcanywhere,AIM,MSN,Yahoo,Morpheus,Napster等等诸多软件我们看到,这里有ICQNapster等软件,相信我们的读者很多都使用过走proxy的ICQOICQ等等,其实他们的原理是差不多的什么是tunnel作为一个实际的例子,我们下面来介绍一个在非公开领域使用的的通道软件,tunnel在tunnel主页(请参阅参考资料)上有这么一端话,tunnelcreatesabidirectionalvirtualdataconnectiontunnelledinrequests.Therequestscanbesentviaanproxyifsodesired.Thiscanbeusefulforusersbehindrestrictivefirewalls.Ifaessisallowedthroughaproxyit‘‘spossibletousetunnelandsaytelorPPPtoconnecttoaputeroutsidethefirewall.从这段说明中我们可以看出来它就是我们今天说要介绍的tunnel技术的一个证明,我们下面大致介绍一下它的使用tunnel目前比拟稳定的版本是
3.
0.5支持各种常见的unix系统,包括window平台可以从相关站点(请参阅参考资料)下载,它的安装是比拟简单的,照INSTALL文件做就可以了,这里不介绍整个软件安装完毕后,我们会得到两个关键文件,htc和hts其中htc是客户端(c),而hts是servers端,我们来看看详细怎么使用的假设有A(域名client.yiming.机,B域名server.yiming.机,两机均为solaris环境,A机在防火墙保护中,B机在防火墙以外,防火墙的管理员控制了访问规那么,仅ALLOW80和53端口的进出数据包而我们的任务是要利用tunnel从A机tel到B机上,穿过防火墙的限制操作如下首先我们在A上启动client端,命令很简单client.yiming.#htc-F1234server.yiming.:80,系统回到提示符下,此刻我们用stat-an可以看到系统内多出了1234端口的侦听*.1234*.*0000LISTEN然后我们在B机上启动server端,命令如下server.yiming.#hts-Flocalhost:2380系统回到提示符下,此刻我们用stat看*.80*.*0000LISTEN80端口处于侦听状态,需要注意的是,假如系统本身跑的有web效劳(80端口本身处于侦听),并不会影响tunnel的工作Okserver以及client端都启动了,我们可以开场我们的通道试验了,在client.yiming.上执行一下如下命令看看Client.yiming.#tellocalhost1234Trying
0.
0.
0.
0...Connectedto
0.Escapecharacteris‘‘^]‘‘.SunOS
5.7Thisisyiming‘‘sprivatebox!Anyquestioncontactmewithyiming@security.zz.ha.login:看到B机的提示符了输入账号密码看看是否工作正常?Login:yimingPassword:omithere;sever.yiming.#lsbakcheckgodlost+foundmrtgrunsoftwgOK!工作正常,和正常的tel没有什么差异仔细观察整个过程,会发如今最开场的地方显示的是Trying
0.
0.
0.
0...,Connectedto
0.而不是Tryingserver.yiming.…Connecttoserver.yiming.,这就很直观的可以看出来client端是转发1234数据包到本机80端口的(然后再转发到远端)而不是直接连接远端的B机上面是比拟直观的测试,为了进一步验证server和client之间不是通过23端口通讯,我们抓取数据包来看看我们在server起个抓包工具tcpdump(请参阅参考资料)瞧瞧server.yiming.#tcpdumphostclient.yiming.tcpdump:listeningonhme014:42:
54.213699client.yiming..51767server.yiming..80:S1237977857:12379778570win8760DF14:42:
54.213767server.yiming..80client.yiming..51767:S1607785698:16077856980ack1237977858win8760DF14:42:
54.216186client.yiming..51768server.yiming..80:.ack1win8760DF14:42:
54.218661client.yiming..51768server.yiming..80:P1:4443ack1win8760DF14:42:
54.218728client.yiming..51768server.yiming..80:P44:484ack1win8760DF篇幅所限,上面只是截取了结果中的一点点数据包,但已经可以说明问题了,我们看到server和client之间顺利的完成了三次握手,然后开场push数据,而且通讯确实走的是80端口有点意思噢看是看出来了,但太不直白,到底在搞什么呀,我们再略微改动一下tcpdump的运行方式,进一步在来看看tel的数据是否被封装在80端口的数据包内传输?server.yiming.#tcpdump-Xhostclient.yiming.14:43:
05.246911server.yiming..80client.yiming..51768:.2997:44571460ack89win8760DF0x0000450005dc3b234000ff06e2c2yyyyyyyyE...;#@......f.D0x0010xxxxxxxx0050de425fd5ac4f39ac016f.f.#.P.B..O
9..o0x00205010223898e40000746f74616c203636P.
8....total.660x0030370d0a64727778722d78722d
782020327..drwxr-xr-x..20x00403920726f6f742021202120726f6f
74209.root.....root.呵呵,这次清楚多了,上面应该是一次ls命令的输出结果,可以清楚的看到tel的结果!果然tel的数据是在80端口的数据包内!tunnel带来的平安问题写到这里,我们可以想象一下,假如管理员完全信赖防火墙,那么在一个有这样隐患的的局域网中,会发生什么样的后果?我们可以看到,多年以来,对防火墙的依赖也一直列在SANS的Top10平安问题中既然如此,就很自然的会产生一个问题是这种tunnel行为能被发现吗?首先我们想到的是使用入侵检测系统,在目前的网络平安设计中,防火墙参加侵检测系统是一种比拟流行的平安联动配置,既然tunnel绕过了防火墙,那么IDS系统呢?我们来测测看看在下面的测试中,我们将使用IDS系统是Snort,版本
1.
8.2(请参阅参考资料)这可是大名鼎鼎的开放源代码的IDS系统,在它的说明中,被描绘为一个轻量级的,可跨平台工作的入侵检测系统,在xx年12月英国的独立测试实验室NSS的评测中(请参阅参考资料),击败了包括商用IDS系统的所有对手,这些商用软件可是包括ISS,CISCOSECUREIDS,CAETRUST,CYBERSAFECENTRAX,NFR有兴趣的读者还可以看这篇名为OpensourcemountsIDSchallenge的报道(请参阅参考资料)好,对Snort的大致介绍完毕,我们来看看结果吧,Snort对整个试验过程抓获的数据包产成了告警,如下[**]WEB-MISCwhiskerspliceattack[**]12/02-14:42:
54.389175client.yiming.:51767-server.yiming.:80TCPTTL:251TOS:0x0ID:3327IpLen:20DgmLen:42DF***AP***Seq:0x49CA0BA7Ack:0x5FD4DCE3Win:0x2238TcpLen:20=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+[**]WEB-MISCwhiskerspliceattack[**]12/02-14:43:
03.195006client.yiming.:51767-server.yiming.:80TCPTTL:251TOS:0x0ID:3439IpLen:20DgmLen:41DF***AP***Seq:0x49CA0C20Ack:0x5FD4DCE3Win:0x2238TcpLen:20=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+[**]WEB-MISCwhiskerspliceattack[**]12/02-14:43:
04.630268client.yiming.:51768-server.yiming.:80TCPTTL:251TOS:0x0ID:3496IpLen:20DgmLen:41DF***AP***Seq:0x49CA0C4EAck:0x5FD4DCE3Win:0x2238TcpLen:20=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+我们看到snort对抓获的数据包产生了WEB-MISCwhiskerspliceattack的告警,然而这种攻击并没有发生,同时snort对tunnel数据包没有发觉这样snort就同时出现了IDS系统的两个问题,falsepositive,falsenegative这也很正常,因为这也是基于签名的IDS系统的通病,目前决大数IDS系统包括著名的商用软件ISSNFR等都是基于签名的,也就是说系统维护着一套特定攻击数据包的数据形式签名系统工作时,检查经过的数据包的内容,和自己数据库内数据形式签名比照,假如和某种攻击形式签名一样,那么就判断发生了某种攻击由此我们可以看出很明显的存在假设干问题如对签名的依赖不可防止的导致两个结果,falsenegativefalsepositive也就是说会产生漏报和误报,这一点很容易理解,当新出现一种攻击形式时,由于IDS系统内没有相应的数据签名,那么就不可能捕获相应的攻击数据包,falsenegative由此发生同时,过于依赖签名形式也很容易误报,就象我们上面的例子同时,对数据签名的依赖会在一定程度上降低系统性能-经过的数据包都需要和IDS系统的签名对照(请参阅参考资料)此外,基于签名的IDS系统本身有可能由于根据签名这一特性而被攻击,一个例子是stick,这个程序的作者利用IDS系统进展签名匹配工作原理,发送大量带有攻击特征的数据包给IDS系统,使IDS系统本身处理才能超过极限,从而导致IDS系统无法响应,一些解决思路看来依靠手头的IDS是无法发觉这种行为了,那么有其它方法吗?我们仔细分析一下事件过程中截获的tunnel数据包再说吧仔细观察截获的tunnel数据包,可以发现紧跟着三次握手完成后的第一个数据包包含着一个POST动作,是由htc(client端)发送到htsserver端的如下14:55:
39.128908client.yiming..51767server.yiming..80:S3521931836:35219318360win8760DF0x00004500002cd34000fb0653c9xxxxxxxxE....@...S..f.#0x0010yyyyyyyyca370050d1ec6a3c
00000000.f.D.
7.P..j....0x00206002223817080000020405b40000`.
39.128945server.yiming..80client.yiming..51767:S2946004964:29460049640ack3521931837win8760DF0x00004500002ccb854000ff065810yyyyyyyyE....@...X..f.D0x0010xxxxxxxx0050ca37af9877e4d1ec6a3d.f.#.P.
7..w...j=0x002060122238ef790000020405b4`.
8.y......14:55:
39.131002client.yiming..51767server.yiming..80:.ack1win8760DF0x000045000028d3cd4000fb0653xxxxxxxxE....@...S..f.#0x0010yyyyyyyyca370050d1ec6a3daf9877e
5.f.D.
7.P..j=..w.0x00205010223807370000000000000000P.
8.
39.132841server.yiming..80client.yiming..51767:.ack44win8760DF0x000045000028cb864000ff065813yyyyyyyyE....@...X..f.D0x0010xxxxxxxx0050ca37af9877e5d1ec6a
68.f.#.P.
7..w...jh0x002050102238070c0000P.
8....14:55:
39.132860client.yiming..51767server.yiming..80:P1:4443ack1win8760DF0x000045000053d3ce4000fb0653a0xxxxxxxxE..S..@...S..f.#0x0010yyyyyyyyca370050d1ec6a3daf9877e
5.f.D.
7.P..j=..w.0x002050182238d23a0000504f5354202f696eP.
8.:..POST./in0x00306465782e68746d6c3f637261703d3130dex.htmlcrap=100x0040303738383034383620485454502f312e
07880486./
1.0x0050310d0a
1..
1..看起来是发送client端的数据包到server端的,那么server有什么反响呢?我们往下看在上面这个过程完成后,htc和hts又发生了一次握手(注意,又一次握手),如下14:55:
39.134301client.yiming..51768server.yiming..80:S2851199448:28511994480win8760DF0x00004500002cd3df4000fb0653b6xxxxxxxxE....@...S..f.#0x0010yyyyyyyyca380050a9f1d9d
800000000.f.D.
39.134389server.yiming..80client.yiming..51768:S2946060449:29460604490ack2851199449win8760DF0x00004500002ccb8f4000ff065806yyyyyyyyE....@...X..f.D0x0010xxxxxxxx0050ca38af9950a1a9f1d9d
9.f.#.P.
8..P.....0x002060122238cf190000020405b4`.
39.136527client.yiming..51768server.yiming..80:.ack1win8760DF0x000045000028d3e04000fb0653b9xxxxxxxxE....@...S..f.#0x0010yyyyyyyyca380050a9f1d9d9af9950a
2.f.D.
8.P......P.0x002050102238e6d60000000000000000P.
39.137333client.yiming..51768server.yiming..80:P1:4342ack1win8760DF0x000045000052d3e14000fb06538exxxxxxxxE..R..@...S..f.#0x0010yyyyyyyyca380050a9f1d9d9af9950a
2.f.D.
8.P......P.0x00205018223825ce0000474554202f696e64P.8%...GET./ind0x003065782e68746d6c3f637261703d313030ex.htmlcrap=1000x00403738383034383620485454502f312e
317880486./
1.10x00500d0a..14:55:
39.137379server.yiming..80client.yiming..51768:.ack43win8718DF0x000045000028cb904000ff065809yyyyyyyyE....@...X..f.D0x0010xxxxxxxx0050ca38af9950a2a9f1da
03.f.#.P.
8..P.....0x00205010220ee6d60000P......14:55:
39.139733client.yiming..51768server.yiming..80:P43:8946ack1win8760DF0x000045000056d3e24000fb065389xxxxxxxxE..V..@...S..f.#0x0010yyyyyyyyca380050a9f1da03af9950a
2.f.D.
8.P......P.0x002050182238e1560000486f73743a203230P.
8.V..Host:.200x0030322e3130322e3232372e36383a38300d
2.
102.
227.68:
80.0x00400a436f6e6e656374696f6e3a20636c6f.Connection:.clo0x005073650d0a0d0ase....14:55:
39.151300server.yiming..80client.yiming..51768:P1:170169ack89win8760DF0x0000450000d1cb914000ff06575fyyyyyyyyE.....@...W.f.D0x0010xxxxxxxx0050ca38af9950a2a9f1da
31.f.#.P.
8..P....10x002050182238e7210000485454502f312e31P.
8.!../
1.10x003020323030204f4b0d0a436f6e74656e
74.
200.OK..Content0x00402d4c656e6774683a203130323430300d-Length:.
102400.0x00500a436f6e6e656374696f6e3a20636c6f.Connection:.clo0x006073650d0a507261676d613a206e6f2d63se..Pragma:.no-c0x0070616368650d0a43616368652d436f6e74ache..Cache-Cont0x0080726f6c3a206e6f2d63616368652c206erol:.no-cache.n0x00906f2d73746f72652c206d7573742d7265o-store.must-re0x00a076616c69646174650d0a457870697265validate..Expire0x00b0733a20300d0a436f6e74656e742d5479s:.
0..Content-Ty0x00c070653a20746578742f68746d6c0d0a0dpe:.text/html...从数据包中可以看到,本次通讯中htsserver端向htcclient端发送了一个GET的标识包,估计是去取刚刚client端发来的数据包,而且是一次新的握手!为了验证,我们分别在clientserver端,执行stat-an,结果证明了我们的观察是正确的,如下client.yiming..51767server.yiming..808760087600ESTABLISHEDclient.yiming..51768server.yiming..808760087600ESTABLISHED在server端,执行stat-an,结果如下server.yiming..80client.yiming..517678760087600ESTABLISHEDserver.yiming..80client.yiming..517688760087600ESTABLISHED果然,防火墙两边的系统都起了两个socket,和一般程序不同,这是个比拟特殊的现象GET动作完成后,server端又向client端发送了一个数据包,内容是/
1.1200OKContent-Length:102400Connection:closePragma:no-cacheCache-Control:no-cacheno-storemust-revalidateExpires:0Content-Type:text/html这里应该是定义数据包传输最大值等参数的作者发觉,经由了这三次htc和hts之间的作用后,tunnel才真正的建立起来,后面的工作才能正常开展,而且很有意思的是,自此以后所有后续的数据包一律没有80端口经常走的GETPUTPOST之类的内容!!这里看来可以想点方法上面说过,正常走80端口的数据包应该是web行为,那么就数据包中就应该少不了get等正常的动作内容,假如在80端口经过的数据总是没有这些东东,那么就肯定有问题了,那么这种问题就有了一种解决方案,就是手工检查通过80端口通过的数据包,假如数据包是明文传送,那么就很容易发现这种行为但这种行为也只能在理论上可行在实际上的操作是不可能的,有没有比拟成熟的这种产品呢?按照这个思路检索网上的数据,果然发现有种入侵检测e-Gap系统可以确实发觉及屏蔽tunnel等通道软件的存在,它工作在tcp/ip的应用层,在应用层一级检测数据包确实切性,比方,检测80端口的数据包,假如看起来数据包中总是没有有效的数据(URLgetput等参数),那么e-Gap系统就会报警,并中断连接行为(请参阅参考资料)需要注意的是,这种侦测方法仅对明文传送的有效,假如数据被加密,那么也就无计可施了那么再进一步,假如加密了呢?目前作者掌握的情况来看,StealthWatch硬件产品可能是一种比拟好的选择,它完全摈弃了基于签名的工作形式,而是采用一种正在申请专利的基于flow-base构架策略,按照几家评测实验室的结果来看,可以有效的发觉已经公开和未公开的各种攻击,Dos,蠕虫,病毒等,甚至包括加密的通讯!但是,它的价钱也远远的超出了普通的商用IDS系统,一套齐备的设施需4万美元!详细效果作者目前没有条件测试(请参阅参考资料)在我们的试验中,tunnel同时逃过了防火墙的屏蔽以及入侵检测系统的追踪,这是值得考虑的我们可以看到,网络平安仅仅依靠某种或某几种手段是不可靠的,尤其是对平安性要求很高的应用系统,同时对平安系统的盲目依赖往往会造成宏大的平安隐患模板内容仅供参考 。