如何使tcp包和udp包穿透防火墙
副标题#e#
通过本文的httptunnel 技能同时逃过了防火墙的屏蔽以及系统的追踪试验，我们可以看到网络安详仅仅依靠某种或某几种手段是不行靠的，同时对安详系统的盲目性依赖往往会造成庞大的安详隐患。但愿通过本文能引起打点员对网络安详防护系统的思考。
什么是http潜伏通道
什么是局域网安详，系统打点员奈何才气保障局域网的安详？这是一个不绝变革的安详观念，很长的一个时期以来，在局域网与外界互联处安排一个防火墙，严格节制开放的端口，就能在很洪流平上把握安详的主动权，利便的节制网表里用户所能利用的处事。好比，在防火墙上仅仅开放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等等诸多软件。我们看到，这里有ICQ,Napster等软件，相信我们的读者许多都利用过走proxy的ICQ,OICQ等等，其实他们的道理是差不多的。
什么是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.
从这段说明中我们可以看出来它就是我们本日说要先容的tunnel技能的一个证明，我们下面大抵先容一下它的利用。
httptunnel今朝较量不变的版本是3.0.5, 支持各类常见的unix系统，包罗window平台。可以从相关站点（请参阅参考资料）下载，它的安装是较量简朴的，照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
#p#副标题#e#
然后我们在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上执行一下如下呼吁看看：
#p#分页标题#e#
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
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端口的数据包内！
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 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
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
#p#分页标题#e#
我们看到snort对抓获的数据包发生了WEB-MISC whisker splice attack的告警，然而这种进攻并没有产生，同时snort对tunnel数据包没有察觉。这样snort就同时呈现了IDS系统的两个问题，false positive，false negative。
这也很正常，因为这也是基于签名的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系统的完全依赖同样是有风险的。（请参阅参考资料）
一些办理思路
看来依靠手头的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..,[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又产生了一次握手（留意，又一次握手），如下：
#p#分页标题#e#
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端口颠末的数据老是没有这些东东，那么就必定有问题了，
#p#分页标题#e#
那么这种问题就有了一种办理方案，就是手工查抄通过80端口通过的数据包，假如数据包是明文传送，那么就很容易发明这种行为。但这种行为也只能在理论上可行。在实际上的操纵是不行能的，有没有较量成熟的这种产物呢？凭据这个思路检索网上的数据，公然发明有种入侵检测e-Gap系统可以确实察觉及屏蔽httptunnel等通道软件的存在，它事情在tcp/ip的应用层，在应用层一级检测数据包简直切性，好比，检测80端口的数据包，假如看起来数据包中老是没有有效的数据（URL,get,put等参数），那么e-Gap系统就会报警，并间断毗连行为。（请参阅参考资料）
需要留意的是，这种侦测要领仅对明文传送的有效，假如数据被加密，那么也就无计可施了。那么再进一步，假如加密了呢？今朝作者把握的环境来看，StealthWatch硬件产物大概是一种较量好的选择，它完全摈弃了基于签名的事情模式，而是回收一种正在申请专利的基于flow-base构架计策，凭据几家评测尝试室的功效来看，可以有效的察觉已经果真和未果真的各类进攻，Dos，蠕虫，病毒等，甚至包罗加密的通讯！可是，它的价格也远远的超出了普通的商用IDS系统，一套齐备的设施需4万美元！详细结果作者今朝没有条件测试。（请参阅参考资料）
总结
在我们的试验中，httptunnel同时逃过了防火墙的屏蔽以及入侵检测系统的追踪，这是值得思考的。我们可以看到，网络安详仅仅依靠某种或某几种手段是不行靠的，尤其是对安详性要求很高的应用系统，同时对安详系统的盲目依赖往往会造成庞大的安详隐患。
