跟踪HTTP通道流程分析网络安全隐患

作者：用户投稿来源：网络发布时间： 12/12/17

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端口的数据包内！
[page]
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
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =