由http暗藏通道探讨开–转自黑白网络

原文链接：
http://www.cnblogs.com/linyawen/archive/2011/10/26/2224883.html


由http暗藏通道探讨开–转自黑白网络

转自  http://www.heibai.net/article/info/info.php?infoid=1565

什么是局域网安全，系统管理员怎样才能保障局域网的安全？这是一个不断变化的安全概念，很长的一个时期以来，在局域网与外界互联处放置一个防火墙，严格控制开放的端口，就能在很大程度上掌握安全的主动权，方便的控制网内外用户所能使用的服务。比如，在防火墙上仅仅开放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等等诸多软件。读者是不是可以由此想想自己是否接触及使用过这一概念？ 

好了，下面来介绍一个在“非公开领域”使用的的通道软件，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. 
怎么样，很清楚吧，我们下面大致介绍一下它的使用。 
1：httptunnel的使用 

httptunnel目前比较稳定的版本是3.0.5, 支持各种常见的unix系统，包括window平台。可以从ftp://ftp.nocrew.org/pub/nocrew/unix/httptunnel-3.0.5.tar.gz下载，它的安装是比较简单的，照INSTALL文件做就可以了，这里不介绍。 
整个软件安装完毕后，我们会得到两个关键文件，htc和hts,其中htc是客户端（c），而hts是server(s)端，我们来看看具体怎么使用的。 
假设有A（域名client.yiming.com)机，B(域名server.yiming.com)机，两机均为solaris环境，A机在防火墙保护中，B机在防火墙以外，防火墙的管理员控制了访问规则，仅ALLOW 80和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 [email protected] 
login: 
^_^，看到B机的登录提示符了,输入账号密码看看是否工作正常？ 
Login:yiming 
Password: (omit here;) ) 
sever.yiming.com# ls 
bak         check       go          httpd       lost+found  mrtg        run         soft        wg 
呵呵，工作正常呀，和正常的telnet没有什么差别哟。 
仔细观察整个过程，会发现在最开始的地方显示的是Trying 0.0.0.0…，Connected to 0.而不是Trying server.yiming.com…,Connect to server.yiming.com，这就很直观的可以看出来client端是转发1234数据包到本机80端口的。（然后再转发到远端）而不是直接连接远端的B机。 

上面是比较直观的测试，ommmm,我还有点怀疑，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端口的数据包内！ 

问题： 
由上面的内容，我们可以想象一下，如果单纯的信赖防火墙，会产生什么样的后果？ 

检测： 
这种行为不能被发现吗？使用入侵检测系统来看看，先用snort，这可是大名鼎鼎的open free IDS啦，我使用了snort 1.8.2，算是比较高的版本了，它对整个过程抓获的数据包产成了告警，如下： 
[**] 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。是snort这个入侵检测系统水平太低吗？不是，作者本人使用snort已经将近一年了，感觉好极了。而且snort可是刚刚（2001年12月）被一家英国的独立测试实验室NSS评为THE BEST的，它的对手可是包括ISS，CISCO SECURE IDS，CA ETRUST，CYBERSAFE CENTRAX，NFR等诸多高档的商用IDS系统呢。 
同样，作者试了试手头其他的IDS系统，没有能够察觉的（包括商用的）。 
这也很正常，因为这也是基于签名的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是无法察觉这种行为了，有其它办法吗？我们仔细分析一下截获的httptunnel数据包再说吧。 
仔细观察截获的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..,..@…S..f.# 
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..,..@…X..f.D 
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..(..@…S..f.# 
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..(..@…X..f.D 
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        E..S..@…S..f.# 
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..,..@…S..f.# 
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..,..@…X..f.D 
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..(..@…S..f.# 
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        E..R..@…S..f.# 
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..(..@…X..f.D 
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        E..V..@…S..f.# 
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        E…..@…W_.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 
我们看到果然，起了两个socketm，为什么会起两个？不得而知。可以问他（[email protected]）;) 

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端口经过的数据总是没有这些东东，那么就肯定有问题了， 
那么这种问题就有了一种解决方案，就是用人工来检测通过的数据包，那么这种行为从理论上可以被发现的，但是实际上的操作是不可能的，有没有这种产品呢？按照这个思路检索网上的数据，果然发现有种入侵检测e-Gap系统可以确实察觉及屏蔽httptunnel等通道软件的存在，它工作在tcp/ip的应用层，在应用层一级检测数据包的确切性，比如，检测80端口的数据包，如果看起来数据包中总是没有有效的数据（URL,get,put等参数），那么e-Gap系统就会报警，并中断连接行为。 
有兴趣的可以参见如下网址 
http://www.whalecommunications.com/fr_030008.htm 
因为费用问题，作者本人没有试验过，；） 

需要注意的是，这种侦测方法仅对明文传送的有效，如果数据被加密，那么也就无计可施了。那么再进一步，如果加密了呢？ 

目前作者掌握的情况来看，StealthWatch硬件产品可能是一种比较好的选择，它完全摈弃了基于签名的工作模式，而是采用一种正在申请专利的基于flow-base构架策略，按照几家评测实验室的结果来看，可以有效的察觉已经公开和未公开的各种攻击，Dos，蠕虫，病毒等，甚至包括加密的通讯！但是，它的价钱也远远的超出了普通的商用IDS系统，一套齐备的设施需4万美元！有兴趣的可以参见如下网址： 
http://www.lancope.com/products/ 

好了，是结束的时候了，通过上面的这个httptunnel例子，能使大家学到一些东西，并对防火墙，ids等有点点感觉，放羊啦~~~~~ ；）

posted on
2011-10-26 10:54
linyawen 阅读(
…) 评论(
…)
编辑
收藏

转载于:https://www.cnblogs.com/linyawen/archive/2011/10/26/2224883.html