跟踪HTTP通道流程分析网络安全隐患
来源:pcdog
什么是局域网安全，体系办理员怎样才能保障局域网的安全？这是一个不断变化的安全概念，很长的一个时期以来，在局域网与外界互联处放置一个防火墙，严格控制开放的端口，就能在很大程度上掌握安全的主动权，方便的控制网表里用户所能利用的服务。好比，在防火墙上仅仅开放80，53两个端口，那么无论是内部还是外面的歹意人士都将无法利用一些已经证明比力危险的服务。
但要注意一点，防火墙在某种意义上是很愚笨的，办理员对防火墙的太过依赖以及从而孕育发生的怠惰情绪将不行避免的形成安全上的重大隐患，作为一个证明，"通道"技术就是一个很好的例子，这也是本文要讨论的。
那么什么是通道呢？这里所谓的通道，是指一种绕过防火墙端口屏蔽的通讯方法。防火墙两头的数据包封装在防火墙所容许经过的数据包类型或是端口上，然后穿过防火墙与对端通讯，当封装的数据包抵达目标地时，再将数据包还原，并将还原后的数据包交送到相应的服务上。举例如下：
A主机体系在防火墙之后，受防火墙保护，防火墙设置装备摆设的拜访控制准绳是只容许80端口的数据收支，B主机体系在防火墙之外，是开放的。如今假设需要从A体系Telnet到B体系上去，怎样办？利用正常的telnet肯定是不行能了，但我们知道可用的只要80端口，那么这个时候利用Httptunnel通道，就是一个好的措施，思绪如下：
在A呆板上起一个tunnel的client端，让它侦听本机的一个不被利用的任意指定端口，如1234，同时将来自1234端口上的数据指引到远端（B机）的80端口上（注意，是80端口，防火墙容许经过），然后在B机上起一个server，同样挂接在80端口上，同时指引80端口的来自client的转发到本机的telnet服务端口23，这样就ok了。如今在A机上telnet本机端口1234，根据刚才的设置数据包会被转发到目标端口为80的B机，由于防火墙容许经过80端口的数据，因此数据包畅通的穿过防火墙，抵达B机。此时B机在80端口侦听的历程收到来自A的数据包，会将数据包还原，再交还给telnet历程。当数据包需要由B到A前往时，将由80端口再回送，同样可以顺利的经过防火墙。
实际上tunnel概念已经孕育发生好久了，并且很有大概读者利用过雷同的技术，好比上面的网址http://www.http-tunnel.com。它是一个专业提供tunnel服务的公司，经过他们的在线tunnel server,局域网内的用户可以利用被防火墙所屏蔽的ICQ，E-MAIL，pcanywhere，AIM，MSN，Yahoo，Morpheus，Napster等等诸多软件。我们看到，这里有ICQ,Napster等软件，信任我们的读者许多都利用过走proxy的ICQ,OICQ等等，其实他们的原理是差不多的。
什么是Httptunnel
作为一个实际的例子，我们上面来介绍一个在"非公开范畴"利用的的通道软件，httptunnel。在httptunnel主页（请参阅参考资料）上有这么一端话，
httptunnel creates a bidirectional virtual data connection tunnelled in HTTP requests. The HTTP requests can be sent via an HTTP proxy if so desired.
This can be useful for users behind restrictive firewalls. If WWW access is allowed through a HTTP proxy, it's possible to use httptunnel and, say, telnet or PPP to connect to a computer outside the firewall.
从这段阐明中我们可以看出来它就是我们今天说要介绍的tunnel技术的一个证明，我们上面大致介绍一下它的利用。
httptunnel如今比力稳固的版本是3.0.5, 支持种种罕见的unix体系，包括window平台。可以从相关站点（请参阅参考资料）下载，它的安置是比力简单的，照INSTALL文件做就可以了，这里不介绍。
整个软件安置终了后，我们会失掉两个关键文件，htc和hts,此中htc是客户端（c），而hts是server(s)端，我们来看看详细怎样利用的。
假设有A（域名client.yiming.com)机，B(域名server.yiming.com)机，两机均为solaris情况，A机在防火墙保护中，B机在防火墙以外，防火墙的办理员控制了拜访规矩，仅ALLOW80和53端口的收支数据包。而我们的任务是要利用Httptunnel从A机telnet到B机上，穿过防火墙的限制。操作如下：
起首我们在A上启动client端，下令很简单：
client.yiming.com#htc -F 1234 server.yiming.com:80，
体系回到提示符下，此刻我们用netstat -an 可以看到体系内多出了1234端口的侦听
*.1234 *.* *.* *.* *.* *.* 0 0 0 0 LISTEN
然后我们在B机上启动server端，下令如下：
server.yiming.com#hts -F localhost:23 80
体系回到提示符下，此刻我们用netstat看 *.80 *.* *.* *.* *.* 0 0 0 0 LISTEN
80端口处于侦听状态，需要注意的是，如果体系本身跑的有web服务（80端口本身处于侦听），并不会影响Httptunnel的事情。
Ok,server以及client端都启动了，我们可以开端我们的"通道"试验了，在client.yiming.com上实行一下如下下令看看：
Client.yiming.com#telnet localhost 1234
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
SunOS 5.7
This is yiming's private box! Any question,contact me with yiming@security.zz.ha.cn
login:
看到B机的登录提示符了,输入账号密码看看是否事情正常？
OK! 事情正常，和正常的telnet没有什么差异。
细致观察整个历程，会发明在最开端的地方显示的是Trying 0.0.0.0...，Connected to 0.而不是Trying server.yiming.com…,Connect to server.yiming.com，这就很直观的可以看出来client端是转发1234数据包到本机80端口的。（然后再转发到远端）而不是直连续接远端的B机。
上面是比力直观的测试，为了进一步验证server和client之间不是经过23端口通讯，我们抓取数据包来看看。我们在server起个抓包工具tcpdump（请参阅参考资料）瞧瞧。
server.yiming.com#tcpdump host client.yiming.com
tcpdump: listening on hme0
14:42:54.213699 client.yiming.com.51767 > server.yiming.com.80: S 1237977857:1237977857(0) win 8760 (DF)
14:42:54.213767server.yiming.com.80 > client.yiming.com.51767: S 1607785698:1607785698(0) ack 1237977858 win 8760 (DF)
14:42:54.216186 client.yiming.com.51768 > server.yiming.com.80: . ack 1 win 8760 (DF)
14:42:54.218661 client.yiming.com.51768 > server.yiming.com.80: P 1:44(43) ack 1 win 8760 (DF)
14:42:54.218728 client.yiming.com.51768 > server.yiming.com.80: P 44:48(4) ack 1 win 8760 (DF)
篇幅所限，上面只是截取告终果中的一点点数据包，但已经可以阐明问题了，我们看到server和client之间顺利的完成了三次握手，然后开端push数据，并且通讯的确走的是80端口。有点意思噢。
看是看出来了，但太不直白，究竟在搞什么呀，我们再轻微改动一下tcpdump的运行方法，进一步在来看看telnet的数据是否被封装在80端口的数据包内传输？
server.yiming.com#tcpdump -X host client.yiming.com
14:43:05.246911 server.yiming.com.80 > client.yiming.com.51768: . 2997:4457(1460) ack 89 win 8760 (DF)
0x0000 4500 05dc 3b23 4000 ff06 e2c2 yyyy yyyy E...;#@......f.D
0x0010 xxxx xxxx 0050 de42 5fd5 ac4f 39ac 016f .f.#.P.B_..O9..o
0x0020 5010 2238 98e4 0000 746f 7461 6c20 3636 P."8....total.66
0x0030 370d 0a64 7277 7872 2d78 722d 7820 2032 7..drwxr-xr-x..2
0x0040 3920 726f 6f74 2020 2020 2072 6f6f 7420 9.root.....root.
呵呵，这次明白多了，上面应该是一次ls下令的输入结果，可以明白的看到telnet的结果！果然telnet的数据是在80端口的数据包内！
--------------------------------------------------------------------------------
Httptunnel带来的安全问题
写到这里，我们可以想象一下，如果办理员完全信任防火墙，那么在一个有这样隐患的的局域网中，会发生什么样的结果？
我们可以看到，多年以来，对防火墙的依赖也一直列在SANS的Top10安全问题中。
既然云云，就很天然的会孕育发生一个问题是：这种httptunnel行为能被发明吗？
起首我们想到的是利用入侵检测体系，在如今的网络安全计划中，防火墙加入侵检测体系是一种比力流行的安全联动设置装备摆设，既然httptunnel绕过了防火墙，那么IDS体系呢？我们来测测看看。
在上面的测试中，我们将利用IDS体系是Snort，版本1.8.2。（请参阅参考资料）这但是台甫鼎鼎的开放源代码的IDS体系，在它的阐明中，被描述为一个轻量级的，可跨平台事情的入侵检测体系，在2001年12月英国的独立测试实行室NSS的评测中（请参阅参考资料），击败了包括商用IDS体系的所有敌手，这些商用软件但是包括ISS，CISCO SECURE IDS，CA ETRUST，CYBERSAFE CENTRAX，NFR。有兴味的读者还可以看这篇名为Open source mounts IDS challenge 的报道（请参阅参考资料）。
好，对Snort的大致介绍终了，我们来看看结果吧，Snort对整个试验历程抓获的数据包产成了告警，如下：
[**] WEB-MISC whisker splice attack [**]
12/02-14:42:54.389175 client.yiming.com:51767-> server.yiming.com:80
TCP TTL:251 TOS:0x0 ID:3327 IpLen:20 DgmLen:42 DF
***AP*** Seq: 0x49CA0BA7 Ack: 0x5FD4DCE3 Win: 0x2238 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[**] WEB-MISC whisker splice attack [**]
12/02-14:43:03.195006 client.yiming.com:51767 -> server.yiming.com:80
TCP TTL:251 TOS:0x0 ID:3439 IpLen:20 DgmLen:41 DF
***AP*** Seq: 0x49CA0C20 Ack: 0x5FD4DCE3 Win: 0x2238 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[**] WEB-MISC whisker splice attack [**]
12/02-14:43:04.630268 client.yiming.com:51768-> server.yiming.com:80
TCP TTL:251 TOS:0x0 ID:3496 IpLen:20 DgmLen:41 DF
***AP*** Seq: 0x49CA0C4E Ack: 0x5FD4DCE3 Win: 0x2238 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
我们看到snort对抓获的数据包孕育发生了WEB-MISC whisker splice attack的告警，然而这种打击并没有发生，同时snort对tunnel数据包没有察觉。这样snort就同时呈现了IDS体系的两个问题，false positive，false negative。
这也很正常，由于这也是基于签名的IDS体系的通病，如今决大数IDS体系包括著名的商用软件ISS,NFR等都是基于签名的，也就是说体系维护着一套特定打击数据包的数据形式签名。体系事情时，检查经过的数据包的内容，和本身数据库内数据形式签名对比，如果和某种打击形式签名相同，那么就判断发生了某种打击。
由此我们可以看出很显着的存在若干问题：如对签名的依赖不行避免的导致两个结果，false negative ,false positive。也就是说会孕育发生漏报和误报，这一点很容易理解，当新呈现一种打击形式时，由于IDS体系内没有相应的数据签名，那么就不行能捕获相应的打击数据包，false negative由此发生。同时，过于依赖签名形式也很容易误报，就象我们上面的例子。同时，对数据签名的依赖会在一定程度上降低体系功能-经过的数据包都需要和IDS体系的签名比较。（请参阅参考资料）
别的，基于签名的IDS体系本身有大概由于根据签名这一特性而被打击，一个例子是stick ，这个程序的作者利用IDS体系进行签名立室事情原理，发送大量带有打击特征的数据包给IDS体系，使IDS体系本身处置惩罚能力凌驾极限，从而导致IDS体系无法响应。按照作者Coretez Giovanni的说法，运行2秒钟stick就能使著名的商用IDS体系ISS real secure瓦解。由上我们看到，对IDS体系的完全依赖同样是有风险的。（请参阅参考资料）
一些解决思绪
- 文章作者: 福州军威计算机技术有限公司
军威网络是福州最专业的电脑维修公司,专业承接福州电脑维修、上门维修、IT外包、企业电脑包年维护、局域网网络布线、网吧承包等相关维修服务。
版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和声明。否则将追究法律责任。
TAG:
|
评论加载中...
|
