《跟踪HTTP通道分析网络中安全隐患 电脑资料》由会员分享，可在线阅读，更多相关《跟踪HTTP通道分析网络中安全隐患 电脑资料（5页珍藏版）》请在金锄头文库上搜索。
1、跟踪HTTP通道分析网络中安全隐患 电脑资料 什么是局域网安全，系统 _ _保障局域网的安全？这是一个不断变化的安全概念，很长的一个时期以来，在局域网与外界互联处放置一个防火墙，严格控制开放的端口，就能在很大程度上掌握安全的主动权，方便的控制网内外用户所能使用的服务， 跟踪通道 _网络中安全隐患 。比如，在防火墙上仅仅开放80，53两个端口，那么无论是内部还是外面的恶意人士都将无法使用一些已经 证明比较危险的服务。 但要注意一点，防火墙在某种意义上是很愚蠢的， _对防火墙的过分依赖以及从而产生的懈怠情绪将不可避免的形成安全上的重大隐患，作为一个证明，通道技术就是一个很好的例子，这也是本文要讨论
2、的。 那么什么是通道呢？这里所谓的通道，是指一种绕过防火墙端口屏蔽的通讯方式。防火墙两端的数据包封装在防火墙所允许通过的数据包类型或是端口上，然后穿过防火墙与对端通讯，当封装的数据包到达目的地时，再将数据包还原，并将还原后的数据包交送到相应的服务上。举例如下： A主机系统在防火墙之后，受防火墙保护，防火墙配置的访问控制原则是只允许80端口的数据进出，B主机系统在防火墙之外，是开放的。现在假设需要从A系统Tel到B系统上去，怎么办？使用正常的tel肯定是不可能了，但我们知道可用的只有80端口，那么这个时候使用Httptunnel通道，就是一个好的办法，思路如下： 在A机器上起一个tunnel的c
3、lient端，让它侦听本机的一个不被使用的任意指定端口，如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端口再回送，同样可以顺利的通过
4、防火墙。 实际上tunnel概念已经产生很久了，而且很有可能读者使用过类似的技术，比如下面的网址.-tunnel.。它是一个专业提供tunnel服务的 _，通过他们的在线tunnelserver,局域网内的用户可以使用被防火墙所屏蔽的ICQ，E-MAIL，pcanywhere，AIM， _，Yahoo，Morpheus，Napster等等诸多软件。我们看到，这里有ICQ,Napster等软件，相信我们的读者很多都使用过走proxy的ICQ,OICQ等等，其实他们的原理是差不多的。 什么是Httptunnel 作为一个实际的例子，我们下面来介绍一个在非公开领域使用的的通道软件，tunnel。在t
5、unnel主页上有这么一段话： tunnel creates a bidirectional virtual data connection tunnelled in requests. The requests can be sent via an proxy if so desired. This can be useful for users behind restrictive firewalls. If aess is allowed through a proxy, its possible to use tunnel and, say, tel or PPP to connect
6、 to a puter outside the firewall. 从这段说明中我们可以看出来它就是我们今天说要介绍的tunnel技术的一个证明，我们下面大致介绍一下它的使用， 电脑资料 跟踪通道 _网络中安全隐患( s:/ )。 tunnel目前比较稳定的版本是3.0.5, 支持各种常见的unix系统，包括window平台。可以从相关站点（请参阅参考资料）下载，它的安装是比较简单的，照INSTALL文件做就可以了，这里不介绍。 整个软件安装完毕后，我们会得到两个关键文件，htc和hts,其中htc是客户端（c），而hts是server(s)端，我们来看看具体怎么使用的。 假设有A（域名cli
7、ent.yiming.)机，B(域名server.yiming.)机，两机均为solaris环境，A机在防火墙保护中，B机在防火墙以外，防火墙的 _控制了访问规则，仅ALLOW80和53端口的进出数据包。而我们的任务是要利用Httptunnel从A机tel到B机上，穿过防火墙的限制。操作如下： 首先我们在A上启动client端，命令很简单： client.yiming.#htc -F 1234 server.yiming.:80， 系统回到提示符下，此刻我们用stat -an 可以看到系统内多出了1234端口的侦听 *.1234 *.* *.* *.* *.* *.* 0 0 0 0 LIST
8、EN 然后我们在B机上启动server端，命令如下： server.yiming.#hts -F localhost:23 80 系统回到提示符下，此刻我们用stat看 *.80 *.* *.* *.* *.* 0 0 0 0 LISTEN 80端口处于侦听状态，需要注意的是，如果系统本身跑的有web服务（80端口本身处于侦听），并不会影响Httptunnel的工作。 Ok,server以及client端都启动了，我们可以开始我们的通道试验了，在client.yiming.上执行一下如下命令看看： Client.yiming.#tel localhost 1234 Trying 0.0.0.0
9、. Connected to 0. Escape character is . SunOS 5.7 This is yimings private box! Any question,contact me with yimingsecurity.zz.ha. login: 看到B机的提示符了,输入账号 _看看是否工作正常？ OK! 工作正常，和正常的tel没有什么差别。 仔细观察整个过程，会发现在最开始的地方显示的是Trying 0.0.0.0.，Connected to 0.而不是Trying server.yiming.,Connect toserver.yiming.，这就很直观的可以看出来client端是转发1234数据包到本机80端口的。（然后再转发到远端）而不是直接连接远端的B机。 模板,内容仅供参考
