tcp和udp包穿透防⽕墙-Httptunnel
什么是局域⽹安全，系统管理员怎样才能保障局域⽹的安全？这是⼀个不断变化的安全概念，很长的⼀个时期以来，在局域⽹与外界互联处放置⼀个防⽕墙，严格控制开放的端⼝，就能在很⼤程度上掌握安全的主动权，⽅便的控制⽹内外⽤户所能使⽤的服务。⽐如，在防⽕墙上仅仅开放80，53两个端⼝，那么⽆论是内部还是外⾯的恶意⼈⼠都将⽆法使⽤⼀些已经证明⽐较危险的服务。
但要注意⼀点，防⽕墙在某种意义上是很愚蠢的，管理员对防⽕墙的过分依赖以及从⽽产⽣的懈怠情绪将不可避免的形成安全上的重⼤隐患，作为⼀个证明，"通道"技术就是⼀个很好的例⼦，这也是本⽂要讨论的。
那么什么是通道呢？这⾥所谓的通道，是指⼀种绕过防⽕墙端⼝屏蔽的通讯⽅式。防⽕墙两端的数据包封装在防⽕墙所允许通过的数据包类型或是端⼝上，然后穿过防⽕墙与对端通讯，当封装的数据包到达⽬的地时，再将数据包还原，并将还原后的数据包交送到相应的服务国民革命
上。举例如下：
A 主机系统在防⽕墙之后，受防⽕墙保护，防⽕墙配置的访问控制原则是只允许80端⼝的数据进出，B主机系统在防⽕墙之外，是开放的。现在假设需要从A系统 Telnet到B系统上去，怎么办？使⽤正常的telnet肯定是不可能了，但我们知道可⽤的只有80端⼝，那么这个时候使⽤Httptunnel通道，就是⼀个好的办法，思路如下：
在A机器上起⼀个tunnel的client端，让它侦听本机的⼀个不被使⽤的任意指定端⼝，如1234，同时将来⾃1234端⼝上的数据指引到远端（B机）的80端⼝上（注意，是80端⼝，防⽕墙允许通过），然后在B机上起⼀个rver，同样挂接在80 端⼝上，同时指引80端⼝的来⾃client的转发到本机的telnet服务端⼝23，这样就ok了。现在在A机上telnet本机端⼝1234，根据刚才的设置数据包会被转发到⽬标端⼝为80的B机，因为防⽕墙允许通过80端⼝的数据，因此数据包畅通的穿过防⽕墙，到达B机。此时B机在80端⼝侦听的进程收到来⾃A的数据包，会将数据包还原，再交还给telnet进程。当数据包需要由B到A返回时，将由80端⼝再回送，同样可以顺利的通过防⽕墙。
实际上tunnel概念已经产⽣很久了，⽽且很有可能读者使⽤过类似的技术，⽐如下⾯的⽹址。它是⼀个专业提供tunnel服务的公司，通过他们的在线tunnel rver，局域⽹内的⽤户可以使⽤被防⽕墙所屏蔽的ICQ，E-MAIL，
pcanywhere， AIM，MSN， Yahoo，Morpheus，Napster等等诸多软件。我们看到，这⾥有ICQ,Napster等软件，相信我们的读者很多都使⽤过⾛proxy的ICQ,OICQ等等，其实他们的原理是差不多的。
什么是Httptunnel
作为⼀个实际的例⼦，我们下⾯来介绍⼀个在"⾮公开领域"使⽤的的通道软件，httptunnel。在httptun
nel主页（请参阅参考资料）上有这么⼀端话，
httptunnel creates a bidirectional virtual data connection tunnelled in HTTP requests.
The HTTP requests can be nt via an HTTP proxy if so desired.
This can be uful for urs behind restrictive firewalls. If WWW access is allowed
The HTTP requests can be nt via an HTTP proxy if so desired.
This can be uful for urs behind restrictive firewalls. If WWW access is allowed
through a HTTP proxy, it's possible to u 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是rver(s)端，我们来看看具体怎么使⽤的。
假设有A（域名)机，B(域名)机，两机均为solaris环境，A机在防⽕墙保护中，B机在防⽕墙以外，防⽕墙的管理员控制了访问规则，仅ALLOW 80和53端⼝的进出数据包。⽽我们的任务是要利⽤Httptunnel从A机 telnet到B机上，穿过防⽕墙的限制。操作如下：
⾸先我们在A上启动client端，命令很简单：
#htc -F 1234 :80，
系统回到提⽰符下，此刻我们⽤netstat -an 可以看到系统内多出了1234端⼝的侦
听 *.1234 *.* 0 0 0 0 LISTEN
然后我们在B机上启动rver端，命令如下：
#hts -F localhost:23 80
系统回到提⽰符下，此刻我们⽤netstat看 *.80 *.* 0 0 0 0 LISTEN
80端⼝处于侦听状态，需要注意的是，如果系统本⾝跑的有web服务（80端⼝本⾝处于侦听），并不会影响Httptunnel的⼯作。
Ok,rver以及client端都启动了，我们可以开始我们的"通道"试验了，在上执⾏⼀下如下命令看看：
#telnet localhost 1234
Trying 0.0.
Connected to 0.
Escape character is '^]'.
SunOS 5.7
This is yiming's private box! Any question,contact me with <script language="JavaScript" type="text/javascript"> </script> login:
看到B机的登录提⽰符了，输⼊账号密码看看是否⼯作正常？
Login:yiming
Password: (omit here;) )
# ls
bak check go httpd lost+found mrtg run soft wg
OK! ⼯作正常，和正常的telnet没有什么差别。
仔细观察整个过程，会发现在最开始的地⽅显⽰的是Trying 0.0.，Connected to 0.⽽不是
Trying …,Connect to ，这就很直观的可以看出来client 端是转发1234数据包到本机80端⼝的。（然后再转发到远端）⽽不是直接连接远端的B机。
上⾯是⽐较直观的测试，为了进⼀步验证rver和client之间不是通过23端⼝通讯，我们抓取数据包来看看。我们在rver起个抓包⼯具tcpdump（请参阅参考资料）瞧瞧。
#tcpdump host
tcpdump: listening on hme0
14:42:54.213699 51767 >
80: S 1237977857:1237977857(0) win 8760 (DF)
14:42:54.80 >
51767: S 1607785698:1607785698(0) ack 1237977858 win 8760 (DF)
14:42:54.216186 51768 > 80: . ack 1 win 8760 (DF)
14:42:54.218661 51768 > 80: P 1:44(43) ack 1 win 8760 (DF)
14:42:54.218728 51768 > 80: P 44:48(4) ack 1 win 8760 (DF)
篇幅所限，上⾯只是截取了结果中的⼀点点数据包，但已经可以说明问题了，我们看到rver和client之间顺利的完成了三次握⼿，然后开始push数据，⽽且通讯确实⾛的是80端⼝。有点意思噢。
看是看出来了，但太不直⽩，到底在搞什么呀，我们再稍微改动⼀下tcpdump的运⾏⽅式，进⼀步在来看看telnet的数据是否被封装在80端⼝的数据包内传输？
#tcpdump -X host
14:43:05.246911 80 > 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 ot.
呵呵，这次清楚多了，上⾯应该是⼀次ls命令的输出结果，可以清楚的看到telnet的结果！果然telnet的数据是在80端⼝的数据包内！
Httptunnel带来的安全问题
写到这⾥，我们可以想象⼀下，如果管理员完全信赖防⽕墙，那么在⼀个有这样隐患的的局域⽹中，会发⽣什么样的后果？
我们可以看到，多年以来，对防⽕墙的依赖也⼀直列在SANS的Top 10安全问题中。
既然如此，就很⾃然的会产⽣⼀个问题是：这种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 :51767-> :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 :51767 -> :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 :51768-> :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系统的两个问题，fal positive，fal negative。
这也很正常，因为这也是基于签名的IDS系统的通病，⽬前决⼤数IDS系统包括著名的商⽤软件ISS,NFR等都是基于签名的，也就是说系统维护着⼀套特定攻击数据包的数据模式签名。系统⼯作时，检查经过的数据包的内容，和⾃⼰数据库内数据模式签名对⽐，如果和某种攻击模式签名相同，那么就判断发⽣了某种攻击。
由此我们可以看出很明显的存在若⼲问题：如对签名的依赖不可避免的导致两个结果，fal negative , fal positive。也就是说会产⽣漏报和误报，这⼀点很容易理解，当新出现⼀种攻击模式时，由于IDS系统内没有相应的数据签名，那么就不可能捕获相应的攻击数据
包，fal negative由此发⽣。同时，过于依赖签名模式也很容易误报，就象我们上⾯的例⼦。同时，对数据签名的依赖会在⼀定程度上降低系统性能-经过的数据包都需要和IDS系统的签名对照。（请参阅参考资料）
此外，基于签名的IDS系统本⾝有可能由于依据签名这⼀特性⽽被攻击，⼀个例⼦是stick ，这个程序的作者利⽤IDS系统进⾏签名匹配⼯作原理，发送⼤量带有攻击特征的数据包给IDS系统，使 IDS系统本⾝处理能⼒超过极限，从⽽导致IDS系统⽆法响应。按照作者
Coretez Giovanni的说法，运⾏2秒钟stick就能使著名的商⽤ IDS系统ISS real cure崩溃。由上我们看到，对IDS系统的完全依赖同样是有风险的。（请参阅参考资料）
⼀些解决思路
看来依靠⼿头的IDS是⽆法察觉这种⾏为了，那么有其它办法吗？我们仔细分析⼀下事件过程中截获的httptunnel数据包再说吧。
仔细观察截获的httptunnel数据包，可以发现紧跟着三次握⼿完成后的第⼀个数据包包含着⼀个POST动作，是由htc（client端）发送到hts(rver端)的。如下： 14:55:39.128908 51767 >
80: S 3521931836:3521931836(0) win 8760 (DF)
0x0000 4500 002c d3cc 4000 fb06 53c9 xxxx xxxx E.., <script language="JavaScript" type="text/javascript">
</script> #
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 80 >
51767: S 2946004964:2946004964(0) ack 3521931837 win 8760 (DF)
0x0000 4500 002c cb85 4000 ff06 5810 yyyy yyyy E.., <script language="JavaScript" type="text/javascript">
</script>
0x0010 xxxx xxxx 0050ahci模式
ca37 af98 77e4 d1ec 6a3d .f.#.P.7..w...j=
0x0020 6012 2238 ef79 0000 0204 05b4 `."
14高纤
:55:39.131002 51767 > 80: . ack 1 win 8760 (DF)
0x0000 4500 0028 d3cd 4000 fb06 53cc xxxx xxxx E..( <script language="JavaScript" type="text/javascript">
</script> #
0x0010 yyyy yyyy ca37 0050 d1ec 6a3d af98 77e5 .f.D.7.P..j=..w.
0x001990年属马是什么命
20 5010 2238 0737 0000 0000 0000 0000 P."
14:55:39.132841 80 > 51767: . ack 44 win 8760 (DF)
0x0000 4500 0028 cb86 4000 ff06 5813 yyyy yyyy &nbsageing
p; E..( <script language="JavaScript" type="text/javascript">
</script>
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 51767 > 80: P 1:44(43) ack 1 win 8760 (DF)
0x0000 4500 0053 d3ce 4000 fb06 53a0 xxxx xxxx E..S <script language="JavaScript" type="text/javascript">
</script> #
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端的数据包到rver端的，那么rver有什么反应呢？我们往下看，在上⾯这个过程完成后，htc和hts⼜发⽣了⼀次握⼿（注意，⼜⼀次握⼿），如下：
14:55:39.134301 51768 >
80: S 2851199448:2851199448(0) win 8760 (DF)
0x0000 4500 002c d3df 4000 fb06 53b6 xxxx xxxx E.., <script language="JavaScript" type="text/javascript">
</script> #
0x0010 yyyy yyyy ca38 0050 a9f1 d9d8 0000 0000 .f.D.
0x0020 6002 2238 cf65 0000 0204 05b4 0000 `."
14:55:39.134389 80 >
51768: S 2946060449:2946060449(0) ack 2851199449 win 8760 (DF)
0x0000 4500 002c cb8f 4000 ff06 5806 yyyy yyyy E.., <script language="JavaScript" type="text/javascript">
</script>
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 51768 > 80: . ack 1 win 8760 (DF)
0x0000 4500 0028 d3e0 4000 fb06 53b9 xxxx xxxx E..( <script language="JavaScript" type="text/javascript">
</script> #
0x0010 yyyy yyyy ca38 0050 a9f1 d9d9 af99 50a2 .f.D.P.
0x0020 5010 2238 e6d6 0000 0000 0000 0000 P."8..........
14:55:39.137333 51768 > 80: P 1:43(42) ack 1 win 8760 (DF)
0x0000 4500 0052 d3e1 4000 fb06 538e xxxx xxxx E..R <script language="JavaScript" type="text/javascript">
</script> #
0x0010 yyyy yyyy ca38 0050 a9f1 d9d9 af99 50a2 .f.D.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 80 > 51768: . ack 43 win 8718 (DF)
0x0000 4500 0028 cb90 4000 ff06 5809 yyyy yyyy E..( <script language="JavaScript" type="text/javascript">
</script>
0x0010 xxxx xxxx 0050 ca38 af99 50a2 a9f1 da03 .f.#.P.8..P.....
0x0020 5010 220e e6d6 0000 P.".....
14:55:39.139733 51768 > 80: P 43:89(46) ack 1 win 8760 (DF)
0x0000 4500 0056 d3e2 4000 fb06 5389 xxxx xxxx E..V <script language="JavaScript" type="text/javascript">
</script> #
0x0010 yyyy yyyy ca38 0050 a9f1 da03 af99 50a2 .f.D.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 ....
14:55:39.151300 80 >个人工作证明
51768: P 1:170(169) ack 89 win 8760 (DF)
0x0000 4500 00d1 cb91 4000 ff06 575f yyyy yyyy <script language="JavaScript" type="text/javascript"> </script> _.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 ..Pragma:.no-c
