IP欺騙技術介紹(1) (轉)

subid發表於2007-08-12
IP欺騙技術介紹(1) (轉)[@more@]IP欺騙技術介紹(1)


即使是很好的實現了,由於它本身有著一些不的地方,從而可以對TCP/IP進行  
 
。這些攻擊包括序列號欺騙,攻擊,源地址欺騙和授權欺騙。本文除了介紹IP欺騙攻擊方法外,還介紹怎樣防止這個攻擊手段。

上述攻擊是建立在攻擊者的(包括路由)是連在INTE上的。這裡的攻擊方法是針對TCP/IP本身的缺陷的,而不是某一具體的實現。

實際上,欺騙不是進攻的結果,而是進攻的手段。進攻實際上是信任關係的破壞。


IP欺騙原理


信任關係
在 領域中,信任關係能夠很容易得到。假如在主機A和B上各有一個帳戶,在使用當中會發現,在主機A上使用時需要輸入在A上的相應帳戶,在主機B上使用時必須輸入在B上的帳戶,主機A和B把你當作兩個互不相關的,顯然有些不便。為了減少這種不便,可以在主機A和主機B中建立起兩個帳戶的相互信任關係。在主機A和主機B上你的home目錄中建立.rhosts 。從主機A上,在你的home目錄中輸入'echo " B username " > ~/.rhosts' ;從主機B上,在你的home目錄中輸入'echo " A username " >~/.rhosts' 。至此,你能毫無阻礙地使用任何以r*開頭的命令,如:rlogin,rcall,rsh等,而無口令驗證的煩惱。這些命令將允許以地址為基礎的驗證,或者允許或者拒絕以為基礎的存取服務。

這裡的信任關係是基於IP地址的。


Rlogin
Rlogin 是一個簡單的客戶/,它利用TCP傳輸。Rlogin 允許使用者從一臺主機登入到另一臺主機上,並且,如果目標主機信任它,Rlogin 將允許在不應答口令的情況下使用目標主機上的資源。安全驗證完全是基於源主機的IP 地址。因此,根據以上所舉的例子,我們能利用Rlogin 來從B遠端登入到A,而且不會被提示輸入口令。


TCP 序列號預測
IP只是傳送資料包,並且保證它的完整性。如果不能收到完整的IP資料包,IP會向源地址傳送一個ICMP 錯誤資訊,希望重新處理。然而這個包也可能丟失。由於IP是非面向連線的,所以不保持任何連線狀態的資訊。每個IP資料包被鬆散地傳送出去,而不關心前一個和後一個資料包的情況。由此看出,可以對IP堆疊進行修改,在源地址和目的地址中放入任意滿足要求的IP地址,也就是說,提供虛假的IP地址。

TCP提供可靠傳輸。可靠性是由資料包中的多位控制字來提供的,其中最重要的是資料序列和資料確認,分別用SYN和ACK來表示。TCP 向每一個資料位元組分配一個序列號,並且可以向已成功接收的、源地址所傳送的資料包表示確認(目的地址ACK 所確認的資料包序列是源地址的資料包序列,而不是自己傳送的資料包序列)。ACK在確認的同時,還攜帶了下一個期望獲得的資料序列號。顯然,TCP提供的這種可靠性相對於IP來說更難於愚弄。


序列編號、確認和其它標誌資訊
由於TCP是基於可靠性的,它能夠提供處理資料包丟失,重複或是順序紊亂等不良情況的機制。實際上,透過向所傳送出的所有位元組分配序列編號,並且期待接收端對傳送端所發出的資料提供收訖確認,TCP 就能保證可靠的傳送。接收端利用序列號確保資料的先後順序,除去重複的資料包。TCP 序列編號可以看作是32位的計數器。它們從0至2^32-1 排列。每一個TCP連線(由一定的標示位來表示)的資料都是順序編號的。在TCP資料包中定義序列號(SYN)的標示位位於資料段的前端。確認位(ACK)對所接收的資料進行確認,並且指出下一個期待接收的資料序列號。

TCP透過滑動視窗的概念來進行流量控制。設想在傳送端傳送資料的速度很快而接收端接收速度卻很慢的情況下,為了保證資料不丟失,顯然需要進行流量控制,協調好通訊雙方的工作節奏。所謂滑動視窗,可以理解成接收端所能提供的緩衝區大小。TCP利用一個滑動的視窗來告訴傳送端對它所傳送的資料能提供多大的緩衝區。由於視窗由16位bit所定義,所以接收端TCP 能最大提供65535個位元組的緩衝。由此,可以利用視窗大小和第一個資料的序列號計算出最大可接收的資料序列號。

其它TCP標示位有RST(連線復位,Reset the connection)、PSH(壓入功能,Push function)和FIN (傳送者無資料,No more data from sender)。如果RST 被接收,TCP連線將立即斷開。RST 通常在接收端接收到一個與當前連線不相關的資料包時被髮送。有些時候,TCP模組需要立即傳送資料而不能等整段都充滿時再傳。一個高層的程式將會觸發在TCP頭部的PSH標示,並且告訴TCP模組立即將所有排列好的資料發給資料接收端。FIN 表示一個應用連線結束。當接收端接收到FIN時,確認它,認為將接收不到任何資料了。

TCP序列號預測最早是由Morris對這一安全進行闡述的。他使用TCP序列號預測,即使是沒有從伺服器得到任何響應, 來產生一個TCP包序列。這使得他能欺騙在本地網路上的主機。

通常TCP連線建立一個包括3次握手的序列。客戶選擇和傳輸一個初始的序列號(SEQ標誌)ISN C,並設定標誌位SYN=1,告訴伺服器它需要建立連線。伺服器確認這個傳輸,併傳送它本身的序列號ISN S,並設定標誌位ACK,同時告知下一個期待獲得的資料序列號是ISN=1。客戶再確認它。在這三次確認後,開始傳輸資料。整個過程如下所示:(C:Client S:Server)
C---S: SYN(ISN C )
S---C: SYN(ISN S ) ,ACK(ISN C )
C---S: ACK(ISN S )
C---S:資料 或S---C:資料

也就是說對一個會話,C必須得到ISN S確認。ISN S可能是一個隨機數。

瞭解序數編號如何選擇初始序列號和如何根據時間變化是很重要的。似乎應該有這種情況,當主機啟動後序列編號初始化為1,但實際上並非如此。初始序列號是由tcp_init確定的。ISN每秒增加128000,如果有連線出現,每次連線將把計數器的數值增加64000。很顯然,這使得用於表示ISN的32位計數器在沒有連線的情況下每9.32 小時復位一次。之所以這樣,是因為這樣有利於最大限度地減少舊有連線的資訊干擾當前連線的機會。這裡運用了2MSL 等待時間的概念(不在本文討論的範圍之內)。如果初始序列號是隨意選擇的,那麼不能保證現有序列號是不同於先前的。假設有這樣一種情況,在一個路由迴路中的資料包最終跳出了迴圈,回到了“舊有”的連線(此時其實是不同於前者的現有連線),顯然會發生對現有連線的干擾。

假設一個者X有一種方法,能預測ISN S。在這種情況下,他可能將下列序號送給主機T來模擬客戶的真正的ISN S:
X---S: SYN(ISN X ) ,SRC = T
S---T: SYN(ISN S ) ,ACK(ISN X )
X---S: ACK(ISN S ) ,SRC =T

儘管訊息S*T並不到X,但是X能知道它的內容,因此能傳送資料。如果X要對一個連線實施攻擊,這個連線允許命令,那麼另外的命令也能執行。

那麼怎樣產生隨機的ISN?在Berkeley,最初的序列號變數由一個常數每秒加一產生,等到這個常數一半時,就開始一次連線。這樣,如果開始了一個合法連線,並觀察到一個ISN S在用,便可以計算,有很高可信度,ISN S 用在下一個連線企圖。

Morris 指出,回覆訊息
S---T:SYN(ISN S ) ,ACK(ISN X )
事實上並不消失,真正主機將收到它,並試圖重新連線。這並不是一個嚴重的障礙。

Morris發現,透過模仿一個在T上的埠,並向那個埠請求一個連線,他就能產生序列,從而讓它看上去S*T訊息丟失了。另外一個方法,可以等待知道T關機或重新啟動。

IP欺騙
IP欺騙由若干步驟組成,這裡先簡要地描述一下,隨後再做詳盡地解釋  
 
。先做以下假定:首先,目標主機已經選定。其次,信任已被發現,並找到了一個被目標主機信任的主機。為了進行IP欺騙,進行以下工作:使得被信任的主機喪失工作能力,同時取樣目標主機發出的TCP 序列號,猜測出它的資料序列號。然後,偽裝成被信任的主機,同時建立起與目標主機基於地址驗證的應用連線。如果成功,駭客可以使用一種簡單的命令放置一個系統,以進行非授權操作。


使被信任主機喪失工作能力
一旦發現被信任的主機,為了偽裝成它,往往使其喪失工作能力。由於攻擊者將要代替真正的被信任主機,他必須確保真正被信任的主機不能接收到任何有效的網路資料,否則將會被揭穿。有許多方法可以做到這些。這裡介紹“TCP SYN 淹沒”。

前面已經談到,建立TCP連線的第一步就是客戶端向伺服器傳送SYN請求。 通常,伺服器將向客戶端傳送SYN/ACK 訊號。這裡客戶端是由IP地址確定的。客戶端隨後向伺服器傳送ACK,然後資料傳輸就可以進行了。然而,TCP處理模組有一個處理並行SYN請求的最上限,它可以看作是存放多條連線的佇列長度。其中,連線數目包括了那些三步握手法沒有最終完成的連線,也包括了那些已成功完成握手,但還沒有被應用程式所呼叫的連線。如果達到佇列的最上限,TCP將拒絕所有連線請求,直至處理了部分連線鏈路。因此,這裡是有機可乘的。

駭客往往向被進攻目標的TCP埠傳送大量SYN請求,這些請求的源地址是使用一個合法的但是虛假的IP地址(可能使用該合法IP地址的主機沒有開機)。而受攻擊的主機往往是會向該IP地址傳送響應的,但可惜是杳無音信。與此同時IP包會通知受攻擊主機的TCP:該主機不可到達,但不幸的是TCP會認為是一種暫時錯誤,並繼續嘗試連線(比如繼續對該IP地址進行路由,發出SYN/ACK資料包等等),直至確信無法連線。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10796304/viewspace-952179/,如需轉載,請註明出處,否則將追究法律責任。

相關文章