由http暗藏通道看网络安全(2)

2024-07-21 02:24:31

字体：大中小

来源：转载

供稿：网友

最大的网站源码资源下载站，

    仔细观察截获的httptunnel数据包，可以发现紧跟着三次握手完成后的第一个数据包包含着一个post动作，是由htc（client端）发送到hts(server端)的。如下： 14:55:39.128908 client.yiming.com.51767 > server.yiming.com.80: s 3521931836:3521931836(0) win 8760  (df)
0x0000   4500 002c d3cc 4000 fb06 53c9 xxxx xxxx        e..,[email protected]#
0x0010   yyyy yyyy ca37 0050 d1ec 6a3c 0000 0000        .f.d.7.p..j<....
0x0020   6002 2238 1708 0000 0204 05b4 0000             `."8..........
14:55:39.128945 server.yiming.com.80 > client.yiming.com.51767: s 2946004964:2946004964(0) ack 3521931837 win 8760  (df)
0x0000   4500 002c cb85 4000 ff06 5810 yyyy yyyy        e..,[email protected]
0x0010   xxxx xxxx 0050 ca37 af98 77e4 d1ec 6a3d        .f.#.p.7..w...j=
0x0020   6012 2238 ef79 0000 0204 05b4                  `."8.y......
14:55:39.131002 client.yiming.com.51767 > server.yiming.com.80: . ack 1 win 8760 (df)
0x0000   4500 0028 d3cd 4000 fb06 53cc xxxx xxxx        e..([email protected]#
0x0010   yyyy yyyy ca37 0050 d1ec 6a3d af98 77e5        .f.d.7.p..j=..w.
0x0020   5010 2238 0737 0000 0000 0000 0000             p."8.7........
14:55:39.132841 server.yiming.com.80 > client.yiming.com.51767: . ack 44 win 8760 (df)
0x0000   4500 0028 cb86 4000 ff06 5813 yyyy yyyy        e..([email protected]
0x0010   xxxx xxxx 0050 ca37 af98 77e5 d1ec 6a68        .f.#.p.7..w...jh
0x0020   5010 2238 070c 0000                            p."8....
14:55:39.132860 client.yiming.com.51767 > server.yiming.com.80: p 1:44(43) ack 1 win 8760 (df)
0x0000   4500 0053 d3ce 4000 fb06 53a0 xxxx xxxx        [email protected]#
0x0010   yyyy yyyy ca37 0050 d1ec 6a3d af98 77e5        .f.d.7.p..j=..w.
0x0020   5018 2238 d23a 0000 504f 5354 202f 696e        p."8.:..post./in
0x0030   6465 782e 6874 6d6c 3f63 7261 703d 3130        dex.html?crap=10
0x0040   3037 3838 3034 3836 2048 5454 502f 312e        07880486.http/1.
0x0050   310d 0a                                        1..
                                    1..

看起来是发送client端的数据包到server端的，那么server有什么反应呢？我们往下看,在上面这个过程完成后，htc和hts又发生了一次握手（注意，又一次握手），如下：
14:55:39.134301 client.yiming.com.51768 > server.yiming.com.80: s 2851199448:2851199448(0) win 8760  (df)
0x0000   4500 002c d3df 4000 fb06 53b6 xxxx xxxx        e..,[email protected]#
0x0010   yyyy yyyy ca38 0050 a9f1 d9d8 0000 0000        .f.d.8.p........
0x0020   6002 2238 cf65 0000 0204 05b4 0000             `."8.e........
14:55:39.134389 server.yiming.com.80 > client.yiming.com.51768: s 2946060449:2946060449(0) ack 2851199449 win 8760  (df)
0x0000   4500 002c cb8f 4000 ff06 5806 yyyy yyyy        e..,[email protected]
0x0010   xxxx xxxx 0050 ca38 af99 50a1 a9f1 d9d9        .f.#.p.8..p.....
0x0020   6012 2238 cf19 0000 0204 05b4                  `."8........
14:55:39.136527 client.yiming.com.51768 > server.yiming.com.80: . ack 1 win 8760 (df)
0x0000   4500 0028 d3e0 4000 fb06 53b9 xxxx xxxx        e..([email protected]#
0x0010   yyyy yyyy ca38 0050 a9f1 d9d9 af99 50a2        .f.d.8.p......p.
0x0020   5010 2238 e6d6 0000 0000 0000 0000             p."8..........
14:55:39.137333 client.yiming.com.51768 > server.yiming.com.80: p 1:43(42) ack 1 win 8760 (df)
0x0000   4500 0052 d3e1 4000 fb06 538e xxxx xxxx        [email protected]#
0x0010   yyyy yyyy ca38 0050 a9f1 d9d9 af99 50a2        .f.d.8.p......p.
0x0020   5018 2238 25ce 0000 4745 5420 2f69 6e64        p."8%...get./ind
0x0030   6578 2e68 746d 6c3f 6372 6170 3d31 3030        ex.html?crap=100
0x0040   3738 3830 3438 3620 4854 5450 2f31 2e31        7880486.http/1.1
0x0050   0d0a                                           ..
14:55:39.137379 server.yiming.com.80 > client.yiming.com.51768: . ack 43 win 8718 (df)
0x0000   4500 0028 cb90 4000 ff06 5809 yyyy yyyy        e..([email protected]
0x0010   xxxx xxxx 0050 ca38 af99 50a2 a9f1 da03        .f.#.p.8..p.....
0x0020   5010 220e e6d6 0000                            p.".....
14:55:39.139733 client.yiming.com.51768 > server.yiming.com.80: p 43:89(46) ack 1 win 8760 (df)
0x0000   4500 0056 d3e2 4000 fb06 5389 xxxx xxxx        [email protected]#
0x0010   yyyy yyyy ca38 0050 a9f1 da03 af99 50a2        .f.d.8.p......p.
0x0020   5018 2238 e156 0000 486f 7374 3a20 3230        p."8.v..host:.20
0x0030   322e 3130 322e 3232 372e 3638 3a38 300d        2.102.227.68:80.
0x0040   0a43 6f6e 6e65 6374 696f 6e3a 2063 6c6f        .connection:.clo
0x0050   7365 0d0a 0d0a                                 se....
14:55:39.151300 server.yiming.com.80 > client.yiming.com.51768: p 1:170(169) ack 89 win 8760 (df)
0x0000   4500 00d1 cb91 4000 ff06 575f yyyy yyyy        [email protected]_.f.d
0x0010   xxxx xxxx 0050 ca38 af99 50a2 a9f1 da31        .f.#.p.8..p....1
0x0020   5018 2238 e721 0000 4854 5450 2f31 2e31        p."8.!..http/1.1
0x0030   2032 3030 204f 4b0d 0a43 6f6e 7465 6e74        .200.ok..content
0x0040   2d4c 656e 6774 683a 2031 3032 3430 300d        -length:.102400.
0x0050   0a43 6f6e 6e65 6374 696f 6e3a 2063 6c6f        .connection:.clo
0x0060   7365 0d0a 5072 6167 6d61 3a20 6e6f 2d63        se..pragma:.no-c
0x0070   6163 6865 0d0a 4361 6368 652d 436f 6e74        ache..cache-cont
0x0080   726f 6c3a 206e 6f2d 6361 6368 652c 206e        rol:.no-cache,.n
0x0090   6f2d 7374 6f72 652c 206d 7573 742d 7265        o-store,.must-re
0x00a0   7661 6c69 6461 7465 0d0a 4578 7069 7265        validate..expire
0x00b0   733a 2030 0d0a 436f 6e74 656e 742d 5479        s:.0..content-ty
0x00c0   7065 3a20 7465 7874 2f68 746d 6c0d 0a0d        pe:.text/html...

从数据包中可以看到，本次通讯中hts(server)端向htc(client)端发送了一个get的标识包，估计是去"取"刚才client端发来的数据包，而且是一次新的握手！为了验证，我们分别在client,server端，执行netstat -an，结果证明了我们的观察是正确的，如下：
client.yiming.com.51767        server.yiming.com.80     8760      0  8760      0 established
client.yiming.com.51768        server.yiming.com.80     8760      0  8760      0 established

在server端，执行netstat -an，结果如下：
server.yiming.com.80    client.yiming.com.51767  8760      0  8760      0 established
server.yiming.com.80    client.yiming.com.51768  8760      0  8760      0 established

果然，防火墙两边的系统都起了两个socket，和一般程序不同，这是个比较特殊的现象。

get动作完成后，server端又向client端发送了一个数据包，内容是
http/1.1 200 ok content-length: 102400
connection: close
pragma: no-cache
cache-control: no-cache, no-store, must-revalidate
expires: 0
content-type: text/html

这里应该是定义数据包传输最大值等参数的。

作者察觉，经由了这三次htc和hts之间的作用后，httptunnel才真正的建立起来，后面的工作才能正常开展，而且很有意思的是，自此以后所有后续的数据包一律没有80端口经常走的get,put,post之类的内容！！这里看来可以想点办法。

上面说过，正常走80端口的数据包应该是web行为，那么就数据包中就应该少不了get等正常的动作内容，如果在80端口经过的数据总是没有这些东东，那么就肯定有问题了，

那么这种问题就有了一种解决方案，就是手工检查通过80端口通过的数据包，如果数据包是明文传送，那么就很容易发现这种行为。但这种行为也只能在理论上可行。在实际上的操作是不可能的，有没有比较成熟的这种产品呢？按照这个思路检索网上的数据，果然发现有种入侵检测e-gap系统可以确实察觉及屏蔽httptunnel等通道软件的存在，它工作在tcp/ip的应用层，在应用层一级检测数据包的确切性，比如，检测80端口的数据包，如果看起来数据包中总是没有有效的数据（url,get,put等参数），那么e-gap系统就会报警，并中断连接行为。（请参阅参考资料）

需要注意的是，这种侦测方法仅对明文传送的有效，如果数据被加密，那么也就无计可施了。那么再进一步，如果加密了呢？目前作者掌握的情况来看，stealthwatch硬件产品可能是一种比较好的选择，它完全摈弃了基于签名的工作模式，而是采用一种正在申请专利的基于flow-base构架策略，按照几家评测实验室的结果来看，可以有效的察觉已经公开和未公开的各种攻击，dos，蠕虫，病毒等，甚至包括加密的通讯！但是，它的价钱也远远的超出了普通的商用ids系统，一套齐备的设施需4万美元！具体效果作者目前没有条件测试。（请参阅参考资料）

总结
在我们的试验中，httptunnel同时逃过了防火墙的屏蔽以及入侵检测系统的追踪，这是值得思考的。我们可以看到，网络安全仅仅依靠某种或某几种手段是不可靠的，尤其是对安全性要求很高的应用系统，同时对安全系统的盲目依赖往往会造成巨大的安全隐患。

参考资料

httptunnel主页
http://www.nocrew.org/software/httptunnel.html
httptunnel程序下载
ftp://ftp.nocrew.org/pub/nocrew/unix/httptunnel-3.0.5.tar.gz
tcpdump主页及相关资源
http://www.tcpdump.org
snort主页及相关资源
http://www.snort.org
nss关于ids系统的评测报告
http://www.nss.co.uk/ids/index.htm
open source mounts ids challenge 的报道
http://www.vnunet.com/news/1127283
文章"insertion, evasion, and denial of service: eluding network intrusion detection"
http://secinf.net/info/ids/idspaper/idspaper.html
stick作者主页
http://www.eurocompton.net/stick/projects8.html
e-gap产品
http://www.whalecommunications.com
stealthwatch产品
http://www.lancope.com/products

关于作者
宫一鸣，男，26 岁，河南电信网络关键设备高级系统管理员，主任工程师，中国电信国家级跨世纪人才，中国电信网络安全小组核心成员，河南电信网络安全小组成员。您可以通过e-mail :[email protected]或网站http://security.zz.ha.cn联系他!

上一篇：密码的故事（转自MSDN）

下一篇：常用加密字符串的class,转自OSLeague啊，作者：bigeagle