什麼是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
然後我們在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
yiming@security.zz.ha.cn
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 的報導。