史萊姆論壇

返回   史萊姆論壇 > 教學文件資料庫 > 應用軟體使用技術文件
忘記密碼?
論壇說明 標記討論區已讀

歡迎您來到『史萊姆論壇』 ^___^

您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的!

請點擊這裡:『註冊成為我們的一份子!』

Google 提供的廣告


 
 
主題工具 顯示模式
舊 2006-04-20, 02:19 PM   #1
psac
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設 教學 - 不要以為裝了防火牆。我就治不了你!!

不要以為裝了防火牆。我就治不了你!!

--如何使tcp包和udp包穿透防火牆
通過本文的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 server,區域網路內的用戶可以使用被防火牆所遮閉的ICQ,E-MAIL,pcanywhere, AIM,MSN, Yahoo,Morpheus,Napster等等諸多軟體N頤強吹劍萊捍薷磷Q,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

然後我們在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連接阜通訊,我們抓取資料?]純純礎N頤竊趕erver起個抓包工具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
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+




我們看到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..,..@...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 _.f.D">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..快取-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
快取-Control: no-cache, no-store, must-revalidate
Expires: 0
Content-Type: text/html

這裡應該是定義資料包傳輸最大值等參數的。

作者察覺,經由了這三次htc和hts之間的作用後,httptunnel才真正的建立起來,後面的工作才能正常開展,而且很有意思的是,自此以後所有後續的資料包一律沒有80連接阜經常走的GET,PUT,POST之類的內容!!這裡看來可以想點辦法。

上面說過,正常走80連接阜的資料包應該是web行為,那麼就資料包中就應該少不了get等正常的動作內容,如果在80連接阜經過的資料總是沒有這些東東,那麼就肯定有問題了,

那麼這種問題就有了一種解決方案,就是手動式檢查通過80連接阜通過的資料包,如果資料包是明文傳送,那麼就很容易發現這種行為。但這種行為也只能在理論上可行。在實際上的操作是不可能的,有沒有比較成熟的這種產品呢?按照這個思法檢索網上的資料,果然發現有種入侵檢測e-Gap系統可以確實察覺及遮閉httptunnel等通道軟體的存在,它工作在tcp/ip的套用層,在套用層一級檢測資料包的確切性,比如,檢測80連接阜的資料包,如果看起來資料包中總是沒有有效的資料(URL,get,put等參數),那麼e-Gap系統就會報警,並中斷連接行為。(請參閱參考資料)

需要注意的是,這種偵測方法僅對明文傳送的有效,如果資料被加密,那麼也就無計可施了。那麼再進去一步,如果加密了呢?目前作者掌握的情況來看,StealthWatch硬體產品可能是一種比較好的選項,它完全擯棄了關於簽名的工作模式,而是採用一種正在申請專利的關於flow-base構架原則,按照幾家評測實驗室的結果來看,可以有效的察覺已經公開和未公開的各種攻擊,Dos,蠕蟲,病毒等,甚至包括加密的通訊!但是,它的價錢也遠遠的超出了普通的商用IDS系統,一套齊備的設施需4萬美元!具體效果作者目前沒有條件測試。(請參閱參考資料)

總結
在我們的試驗中,httptunnel同時逃過了防火牆的遮閉以及入侵檢測系統的追蹤,這是值得思考的。我們可以看到,網路安全僅僅依靠某種或某幾種手段是不可靠的,尤其是對安全性要求很高的套用系統,同時對安全系統的盲目依賴往往會造成巨大的安全隱患。
__________________
http://bbsimg.qianlong.com/upload/01/08/29/68/1082968_1136014649812.gif
psac 目前離線  
送花文章: 3, 收花文章: 1631 篇, 收花: 3205 次
有 4 位會員向 psac 送花:
10235237 (2010-03-27),amos50 (2006-10-17),Julian_Wu99 (2006-09-27),可以餵食請勿拍打 (2006-11-01)
感謝您發表一篇好文章
舊 2006-09-27, 09:46 PM   #2 (permalink)
註冊會員
榮譽勳章
UID - 49983
在線等級: 級別:7 | 在線時長:90小時 | 升級還需:6小時級別:7 | 在線時長:90小時 | 升級還需:6小時
註冊日期: 2003-03-19
VIP期限: 2011-06
文章: 639
精華: 0
現金: 6261 金幣
資產: 11261 金幣
預設

謝謝大大的熱心 , 我就收下了...感恩
Julian_Wu99 目前離線  
送花文章: 348, 收花文章: 13 篇, 收花: 14 次
 


主題工具
顯示模式

發表規則
不可以發文
不可以回覆主題
不可以上傳附加檔案
不可以編輯您的文章

論壇啟用 BB 語法
論壇啟用 表情符號
論壇啟用 [IMG] 語法
論壇禁用 HTML 語法
Trackbacks are 禁用
Pingbacks are 禁用
Refbacks are 禁用


所有時間均為台北時間。現在的時間是 12:06 AM


Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2024, Jelsoft Enterprises Ltd.


SEO by vBSEO 3.6.1