麻豆小视频在线观看_中文黄色一级片_久久久成人精品_成片免费观看视频大全_午夜精品久久久久久久99热浪潮_成人一区二区三区四区

首頁 > 學院 > 開發設計 > 正文

如何使tcp包和udp包穿透防火墻

2019-11-17 05:32:31
字體:
來源:轉載
供稿:網友

  通過本文的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

然后我們在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 [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

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 久久久久久艹 | 91在线视频观看 | 中文字幕在线观看二区 | 在线免费观看毛片视频 | 毛片免费视频播放 | 九色免费视频 | 午夜影视一区二区 | chinesexxxx刘婷hd 国产91在线播放九色 | 嗯~啊~用力~高h | 欧美久久一区二区 | 国产成年人视频 | 久久久久久久久久久久久久久久久久 | 日韩精品羞羞答答 | 久久久婷婷一区二区三区不卡 | 国产一级桃视频播放 | 成人免费看视频 | 国产黄网| 黄色羞羞视频在线观看 | 精品国产高清一区二区三区 | 麻豆视频在线观看 | 9999久久久久久 | 男人的天堂毛片 | 丁香天堂网 | 护士hd欧美free性xxxx | 欧美一区在线观看视频 | 国内精品一级毛片免费看 | 亚洲成人福利电影 | 看片一区二区三区 | 九九久久视频 | 欧美一级美国一级 | 国产精品1区,2区,3区 | 亚洲精品一区二区三区在线看 | bt 自拍 另类 综合 欧美 | 欧美日韩专区国产精品 | 成人在线免费观看视频 | 国产精品久久久久久婷婷天堂 | 亚洲第一页综合 | 国产色爱综合网 | av在线一区二区三区四区 | 精品国产99久久久久久宅男i | 91精品久久久久久久 |