宮一鳴 (yiming@security.zz.ha.cn)
中國電信網(wǎng)絡(luò)安全小組核心成員
2001 年 12 月

通過本文的httptunnel 技術(shù)同時逃過了防火墻的屏蔽以及系統(tǒng)的追蹤試驗，我們可以看到網(wǎng)絡(luò)安全僅僅依靠某種或某幾種手段是不可靠的，同時對安全系統(tǒng)的盲目性依賴往往會造成巨大的安全隱患。希望通過本文能引起管理員對網(wǎng)絡(luò)安全防護(hù)系統(tǒng)的思考。
什么是http暗藏通道
什么是局域網(wǎng)安全，系統(tǒng)管理員怎樣才能保障局域網(wǎng)的安全？這是一個不斷變化的安全概念，很長的一個時期以來，在局域網(wǎng)與外界互聯(lián)處放置一個防火墻，嚴(yán)格控制開放的端口，就能在很大程度上掌握安全的主動權(quán)，方便的控制網(wǎng)內(nèi)外用戶所能使用的服務(wù)。比如，在防火墻上僅僅開放80，53兩個端口，那么無論是內(nèi)部還是外面的惡意人士都將無法使用一些已經(jīng)證明比較危險的服務(wù)。

但要注意一點(diǎn)，防火墻在某種意義上是很愚蠢的，管理員對防火墻的過分依賴以及從而產(chǎn)生的懈怠情緒將不可避免的形成安全上的重大隱患，作為一個證明，"通道"技術(shù)就是一個很好的例子，這也是本文要討論的。

那么什么是通道呢？這里所謂的通道，是指一種繞過防火墻端口屏蔽的通訊方式。防火墻兩端的數(shù)據(jù)包封裝在防火墻所允許通過的數(shù)據(jù)包類型或是端口上，然后穿過防火墻與對端通訊，當(dāng)封裝的數(shù)據(jù)包到達(dá)目的地時，再將數(shù)據(jù)包還原，并將還原后的數(shù)據(jù)包交送到相應(yīng)的服務(wù)上。舉例如下：

A主機(jī)系統(tǒng)在防火墻之后，受防火墻保護(hù)，防火墻配置的訪問控制原則是只允許80端口的數(shù)據(jù)進(jìn)出，B主機(jī)系統(tǒng)在防火墻之外，是開放的�，F(xiàn)在假設(shè)需要從A系統(tǒng)Telnet到B系統(tǒng)上去，怎么辦？使用正常的telnet肯定是不可能了，但我們知道可用的只有80端口，那么這個時候使用Httptunnel通道，就是一個好的辦法，思路如下：

在A機(jī)器上起一個tunnel的client端，讓它偵聽本機(jī)的一個不被使用的任意指定端口，如1234，同時將來自1234端口上的數(shù)據(jù)指引到遠(yuǎn)端（B機(jī)）的80端口上（注意，是80端口，防火墻允許通過），然后在B機(jī)上起一個server，同樣掛接在80端口上，同時指引80端口的來自client的轉(zhuǎn)發(fā)到本機(jī)的telnet服務(wù)端口23，這樣就ok了�，F(xiàn)在在A機(jī)上telnet本機(jī)端口1234，根據(jù)剛才的設(shè)置數(shù)據(jù)包會被轉(zhuǎn)發(fā)到目標(biāo)端口為80的B機(jī)，因為防火墻允許通過80端口的數(shù)據(jù)，因此數(shù)據(jù)包暢通的穿過防火墻，到達(dá)B機(jī)。此時B機(jī)在80端口偵聽的進(jìn)程收到來自A的數(shù)據(jù)包，會將數(shù)據(jù)包還原，再交還給telnet進(jìn)程。當(dāng)數(shù)據(jù)包需要由B到A返回時，將由80端口再回送，同樣可以順利的通過防火墻。

實際上tunnel概念已經(jīng)產(chǎn)生很久了，而且很有可能讀者使用過類似的技術(shù)，比如下面的網(wǎng)址http://www.http-tunnel.com。它是一個專業(yè)提供tunnel服務(wù)的公司，通過他們的在線tunnel server,局域網(wǎng)內(nèi)的用戶可以使用被防火墻所屏蔽的ICQ，E-MAIL，pcanywhere， AIM，MSN， Yahoo，Morpheus，Napster等等諸多軟件。我們看到，這里有ICQ,Napster等軟件，相信我們的讀者很多都使用過走proxy的ICQ,OICQ等等，其實他們的原理是差不多的。

什么是Httptunnel
作為一個實際的例子，我們下面來介紹一個在"非公開領(lǐng)域"使用的的通道軟件，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技術(shù)的一個證明，我們下面大致介紹一下它的使用。

httptunnel目前比較穩(wěn)定的版本是3.0.5, 支持各種常見的unix系統(tǒng)，包括window平臺�？梢詮南嚓P(guān)站點(diǎn)（請參閱參考資料）下載，它的安裝是比較簡單的，照INSTALL文件做就可以了，這里不介紹。

整個軟件安裝完畢后，我們會得到兩個關(guān)鍵文件，htc和hts,其中htc是客戶端（c），而hts是server(s)端，我們來看看具體怎么使用的。

假設(shè)有A（域名client.yiming.com)機(jī)，B(域名server.yiming.com)機(jī)，兩機(jī)均為solaris環(huán)境，A機(jī)在防火墻保護(hù)中，B機(jī)在防火墻以外，防火墻的管理員控制了訪問規(guī)則，僅ALLOW 80和53端口的進(jìn)出數(shù)據(jù)包。而我們的任務(wù)是要利用Httptunnel從A機(jī)telnet到B機(jī)上，穿過防火墻的限制。操作如下：

首先我們在A上啟動client端，命令很簡單：
client.yiming.com#htc -F 1234 server.yiming.com:80，

系統(tǒng)回到提示符下，此刻我們用netstat -an 可以看到系統(tǒng)內(nèi)多出了1234端口的偵聽 *.1234 *.*00 00 LISTEN



然后我們在B機(jī)上啟動server端，命令如下：
server.yiming.com#hts -F localhost:23 80

系統(tǒng)回到提示符下，此刻我們用netstat看 *.80*.*00 00 LISTEN



80端口處于偵聽狀態(tài)，需要注意的是，如果系統(tǒng)本身跑的有web服務(wù)（80端口本身處于偵聽），并不會影響Httptunnel的工作。

Ok,server以及client端都啟動了，我們可以開始我們的"通道"試驗了，在client.yiming.com上執(zhí)行一下如下命令看看：
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機(jī)的登錄提示符了,輸入賬號密碼看看是否工作正常？
Login:yiming
Password: (omit here;) )
sever.yiming.com# ls
bak check gohttpd lost+foundmrtgrun softwg




OK! 工作正常，和正常的telnet沒有什么差別。

仔細(xì)觀察整個過程，會發(fā)現(xiàn)在最開始的地方顯示的是Trying 0.0.0.0...，Connected to 0.而不是Trying server.yiming.com…,Connect to server.yiming.com，這就很直觀的可以看出來client端是轉(zhuǎn)發(fā)1234數(shù)據(jù)包到本機(jī)80端口的。（然后再轉(zhuǎn)發(fā)到遠(yuǎn)端）而不是直接連接遠(yuǎn)端的B機(jī)。

上面是比較直觀的測試，為了進(jìn)一步驗證server和client之間不是通過23端口通訊，我們抓取數(shù)據(jù)包來看看。我們在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)
幅所限，上面只是截取了結(jié)果中的一點(diǎn)點(diǎn)數(shù)據(jù)包，但已經(jīng)可以說明問題了，我們看到server和client之間順利的完成了三次握手，然后開始push數(shù)據(jù)，而且通訊確實走的是80端口。有點(diǎn)意思噢。

看是看出來了，但太不直白，到底在搞什么呀，我們再稍微改動一下tcpdump的運(yùn)行方式，進(jìn)一步在來看看telnet的數(shù)據(jù)是否被封裝在80端口的數(shù)據(jù)包內(nèi)傳輸？


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 yyyyE...;#@......f.D
0x0010 xxxx xxxx 0050 de42 5fd5 ac4f 39ac 016f.f.#.P.B_..O9..o
0x0020 5010 2238 98e4 0000 746f 7461 6c20 3636P."8....total.66
0x0030 370d 0a64 7277 7872 2d78 722d 7820 20327..drwxr-xr-x..2
0x0040 3920 726f 6f74 2020 2020 2072 6f6f 74209.root.....root.




呵呵，這次清楚多了，上面應(yīng)該是一次ls命令的輸出結(jié)果，可以清楚的看到telnet的結(jié)果！果然telnet的數(shù)據(jù)是在80端口的數(shù)據(jù)包內(nèi)！

Httptunnel帶來的安全問題
寫到這里，我們可以想象一下，如果管理員完全信賴防火墻，那么在一個有這樣隱患的的局域網(wǎng)中，會發(fā)生什么樣的后果？

我們可以看到，多年以來，對防火墻的依賴也一直列在SANS的Top 10安全問題中。

既然如此，就很自然的會產(chǎn)生一個問題是：這種httptunnel行為能被發(fā)現(xiàn)嗎？

首先我們想到的是使用入侵檢測系統(tǒng)，在目前的網(wǎng)絡(luò)安全設(shè)計中，防火墻加入侵檢測系統(tǒng)是一種比較流行的安全聯(lián)動配置，既然httptunnel繞過了防火墻，那么IDS系統(tǒng)呢？我們來測測看看。

在下面的測試中，我們將使用IDS系統(tǒng)是Snort，版本1.8.2。（請參閱參考資料）這可是大名鼎鼎的開放源代碼的IDS系統(tǒng)，在它的說明中，被描述為一個輕量級的，可跨平臺工作的入侵檢測系統(tǒng)，在2001年12月英國的獨(dú)立測試實驗室NSS的評測中（請參閱參考資料），擊敗了包括商用IDS系統(tǒng)的所有對手，這些商用軟件可是包括ISS，CISCO SECURE IDS，CA ETRUST，CYBERSAFE CENTRAX，NFR。有興趣的讀者還可以看這篇名為Open source mounts IDS challenge 的報道（請參閱參考資料）。

好，對Snort的大致介紹完畢，我們來看看結(jié)果吧，Snort對整個試驗過程抓獲的數(shù)據(jù)包產(chǎn)成了告警，如下：
[**] 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: 0x49CA0BA7Ack: 0x5FD4DCE3Win: 0x2238TcpLen: 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: 0x49CA0C20Ack: 0x5FD4DCE3Win: 0x2238TcpLen: 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: 0x49CA0C4EAck: 0x5FD4DCE3Win: 0x2238TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+




我們看到snort對抓獲的數(shù)據(jù)包產(chǎn)生了WEB-MISC whisker splice attack的告警，然而這種攻擊并沒有發(fā)生，同時snort對tunnel數(shù)據(jù)包沒有察覺。這樣snort就同時出現(xiàn)了IDS系統(tǒng)的兩個問題，false positive，false negative。

這也很正常，因為這也是基于簽名的IDS系統(tǒng)的通病，目前決大數(shù)IDS系統(tǒng)包括著名的商用軟件ISS,NFR等都是基于簽名的，也就是說系統(tǒng)維護(hù)著一套特定攻擊數(shù)據(jù)包的數(shù)據(jù)模式簽名。系統(tǒng)工作時，檢查經(jīng)過的數(shù)據(jù)包的內(nèi)容，和自己數(shù)據(jù)庫內(nèi)數(shù)據(jù)模式簽名對比，如果和某種攻擊模式簽名相同，那么就判斷發(fā)生了某種攻擊。

由此我們可以看出很明顯的存在若干問題：如對簽名的依賴不可避免的導(dǎo)致兩個結(jié)果，false negative ,false positive。也就是說會產(chǎn)生漏報和誤報，這一點(diǎn)很容易理解，當(dāng)新出現(xiàn)一種攻擊模式時，由于IDS系統(tǒng)內(nèi)沒有相應(yīng)的數(shù)據(jù)簽名，那么就不可能捕獲相應(yīng)的攻擊數(shù)據(jù)包，false negative由此發(fā)生。同時，過于依賴簽名模式也很容易誤報，就象我們上面的例子。同時，對數(shù)據(jù)簽名的依賴會在一定程度上降低系統(tǒng)性能-經(jīng)過的數(shù)據(jù)包都需要和IDS系統(tǒng)的簽名對照。（請參閱參考資料）

此外，基于簽名的IDS系統(tǒng)本身有可能由于依據(jù)簽名這一特性而被攻擊，一個例子是stick ，這個程序的作者利用IDS系統(tǒng)進(jìn)行簽名匹配工作原理，發(fā)送大量帶有攻擊特征的數(shù)據(jù)包給IDS系統(tǒng)，使IDS系統(tǒng)本身處理能力超過極限，從而導(dǎo)致IDS系統(tǒng)無法響應(yīng)。按照作者Coretez Giovanni的說法，運(yùn)行2秒鐘stick就能使著名的商用IDS系統(tǒng)ISS real secure崩潰。由上我們看到，對IDS系統(tǒng)的完全依賴同樣是有風(fēng)險的。（請參閱參考資料）

一些解決思路
看來依靠手頭的IDS是無法察覺這種行為了，那么有其它辦法嗎？我們仔細(xì)分析一下事件過程中截獲的httptunnel數(shù)據(jù)包再說吧。