詳解TCP/IP協議棧面臨的五大網絡安全問題
在本文中，筆者重點解析了TCP/IP協議棧面臨的五大網絡安全問題，也介紹到企業網絡安全管理人員在面臨問題時所能采取的應對措施。
1. IP欺騙
IP Spoof即IP 電子欺騙，可以理解為一臺主機設備冒充另外一臺主機的IP地址與其他設備通信，從而達到某種目的技術。早在1985年，貝爾實驗室的一名工程師Robbert Morris在他的一篇文章“A weakness in the 4.2bsd UNIX TCP/IP software”中提出了IP Spoof的概念，有興趣的讀者可參見原文：http://www.coast.net/~emv/tubed/archives/Morris_weakness_in_ TCPIP.txt 。
但要注意：單純憑借IP Spoof技術不可能很好地完成一次完整的攻擊，因為現有IP Spoof技術是屬于一種“盲人”式的入侵手段。
一般來說，IP欺騙攻擊有6個步驟：
(1)首先使被信任主機的網絡暫時癱瘓，以免對攻擊造成干擾;
(2)然后連接到目標機的某個端口來猜測ISN基值和增加規律;
(3)接下來把源地址偽裝成被信任主機，發送帶有SYN標志的數據段請求連接;
(4)然后等待目標機發送SYN+ACK包給已經癱瘓的主機;
(5)最后再次偽裝成被信任主機向目標機發送的ACK，此時發送的數據段帶有預測的目標機的ISN+1;
(6)連接建立，發送命令請求。
下面是它的兩個關鍵步驟：
(1)使被信任主機失去工作能力
為了偽裝成被信任主機而不露餡，需要使其完全失去工作能力。由于攻擊者將要代替真正的被信任主機，他必須確保真正的被信任主機不能收到任何有效的網絡數據，否則將會被揭穿。有許多方法可以達到這個目的(如SYN洪水攻擊、Land等攻擊)。
(2)序列號取樣和猜測
對目標主機進行攻擊，必須知道目標主機的數據包序列號。通常如何進行預測呢?往往先與被攻擊主機的一個端口(如25端口)建立起正常連接。通常，這個過程被重復N次，并將目標主機最后所發送的ISN存儲起來。然后還需要估計他的主機與被信任主機之間的往返時間，這個時間是通過多次統計平均計算出來的。如果往返連接增加64,000，則現就可以估計出ISN的大小是128,000乘以往返時間的一半，如果此時目標主機剛剛建立過一個連接，那么再加上64,00。一旦估計出ISN的大小，就開始著手進行攻擊，當然你的虛假TCP數據包進入目標主機時，如果剛才估計的序列號是準確的，進入的數據將被放置在目標機的緩沖區中。但是在實際攻擊過程中往往沒這么幸運，如果估計的序列號小于正確值，那么將被放棄。而如果估計的序列號大于正確值，并且在緩沖區的大小之內，那么該數據被認為是一個未來的數據，TCP模塊將等待其他缺少的數據。如果估計序列號大于期待的數字且不在緩沖區之內，TCP將會放棄它并返回一個期望獲得的數據序列號。偽裝成被信任的主機IP后，此時該主機仍然處在癱瘓狀態，然后向目標主機的被攻擊端口(如25)發送連接請求。目標主機立刻對連接請求作出反應，發更新SYN+ACK確認包給被信任主機，因為此時被信任主機仍然處于癱瘓狀態，它當然無法收到這個包，緊接著攻擊者向目標主機發送ACK數據包，該數據包使用前面估計的序列號加1。如果攻擊者估計正確的話，目標主機將會接收該ACK。連接就正式建立起了，可以開始數據傳輸了。
對于來自網絡外部的欺騙，防范的方法很簡單，只需要在局域網的對外路由器上加一個限制設置就可以實現了，在路由器的設置里面禁止運行聲稱來自于網絡內部的信息包。
對于來自局域網外部的IP欺騙攻擊的防范則可以使用防火墻進行防范，但是對于來自內部的攻擊通過設置防火墻則起不到什么作用，這個時候應該注意內部網的路由器是否支持內部接口。如果路由器支持內部網絡子網的兩個接口，則必須提高警惕，因為它很容易受到IP欺騙。
通過對信息包的監控來檢查IP欺騙攻擊將是非常有效的方法，使用netlog等信息包檢查工具對信息的源地址和目的地址進行驗證，如果發現了信息包來自兩個以上的不同地址，則說明系統有可能受到了IP欺騙攻擊，防火墻外面正有黑客試圖入侵系統。#p#
2. SYN Flooding
SYN Flooding是最為有效和流行的一種DoS攻擊形式。它利用TCP三次握手協議的缺陷，向目標主機發送大量的偽造源地址的SYN連接請求，消耗目標主機的資源，從而不能夠為正常用戶提供服務。
在TCP會話初期，有所謂的“三次握手”過程：對每次發送的數據量是怎樣跟蹤進行協商使數據段的發送和接收同步，根據所接收到的數據量而確定的數據確認數及數據發送、接收完畢后何時撤消聯系，并建立虛連接。為了提供可靠的傳送，TCP在發送新的數據之前，以特定的順序將數據包進行編號，并需要等待這些包傳送給目標機之后的確認消息。TCP總是用來發送大批量的數據。當應用程序在收到數據后要做出確認時也要用到TCP。由于TCP要時刻跟蹤，這需要額外開銷，使得TCP的格式有些顯得復雜。
TCP三次握手的步驟如下：
(1)設主機A要與主機B通信，要建立一個TCP連接。首先，主機B(在這兒是服務器)，必須先運行一個服務器進程，發出一個“被動找開”命令給TCP。之后服務器進程便不斷探測端口，看是否有客戶進程有連接請求。并處于“聽”狀態。客戶端主機A的應用進程，向其TCP發“主動打開”命令，指明要與某個IP地址的某個端口建立TCP連接。第一次主機A的TCP便向主機B的TCP發出連接請求報文。TCP報文中指明了要連接的IP地址(隱含TP數據報指明)和端口號，設置能夠接受的TCP數據段最大值，以及一些用戶數據，SYN=1，ACK=0。這稱為“第一次握手”。
(2)主機A的連接請求到達主機B后，主機B的TCP查看是否有進程在偵聽該端口，如沒有，就發送一個RST=1的應答，拒絕連接，否則將到達TCP數據段留給“偵聽”進程。“偵聽”進程將發回一個應答TCP報文段，其中SYN=1，ACK=1，確認序號ACKSEQ=X+1，同時自己選一個發送序號SEQ=Y。這是“第二次握手”。
(3)主機A收到主機B的確認報文后，再向主機B發出一個確認TCP報文段，其中SYN=1，ACK=1，SEQ=X+1，ACKSEQ=Y+1，這就完成了“第三次握手”。
在SYN Flooding攻擊中，黑客機器向受害主機發送大量偽造源地址的TCP SYN報文，受害主機分配必要的資源，然后向源地址返回SYN+ACK包，并等待源端返回ACK包，如圖1所示。由于源地址是偽造的，所以源端永遠都不會返回ACK報文，受害主機繼續發送SYN+ACK包，并將半連接放入端口的積壓隊列中，雖然一般的主機都有超時機制和默認的重傳次數，但是由于端口的半連接隊列的長度是有限的，如果不斷地向受害主機發送大量的TCP SYN報文，半連接隊列就會很快填滿，服務器拒絕新的連接，將導致該端口無法響應其他機器進行的連接請求，最終使受害主機的資源耗盡。
目前在防御SYN Flooding攻擊方面有2種比較有效的技術。
(1)SYN-cookie技術
一般情況下，當服務器收到一個TCP SYN報文后，馬上為該連接請求分配緩沖區，然后返回一個SYN+ACK報文，這時形成一個半連接。SYN Flooding正是利用了這一點，發送大量的偽造源地址的SYN連接請求，而不完成連接。這樣就大量地消耗服務器的資源。
SYN-cookie技術針對標準TCP連接建立過程資源分配上的這一缺陷，改變了資源分配的策略。當服務器收到一個SYN報文后，不立即分配緩沖區，而是利用連接的信息生成一個cookie，并將這個cookie作為將要返回的SYN+ACK報文的初始序列號。當客戶端返回一個ACK報文時，根據包頭信息計算cookie，與返回的確認序列號(初始的序列號+1)的前24位進行對比，如果相同，則是一個正常連接，然后，分配資源，建立連接。
該技術的巧妙之點在于避免了在連接信息未完全到達前進行資源分配，使SYN Flooding攻擊的資源消耗失效。實現的關鍵之處在于cookie的計算。cookie的計算應該做到包含本次連接的狀態信息，使攻擊者不能偽造cookie。cookie的計算過程如下。
① 服務器收到一個SYN包后，計算一個消息摘要mac：
mac = MAC(A，k)
MAC是密碼學中的一個消息認證碼函數，也就是滿足某種安全性質的帶密鑰的hash函數，它能夠提供cookie計算中需要的安全性。A為客戶和服務器雙方的IP地址和端口號以及參數t的串聯組合：A = SOURCE_IP || SOURCE_PORT || DST_IP || DST_PORT || t;K為服務器獨有的密鑰;時間參數t為32比特長的時間計數器，每64秒加1;
② 生成cookie：
cookie = mac(0:24)：表示取mac值的第0到24比特位;
③ 設置將要返回的SYN+ACK報文的初始序列號，設置過程如下：
· 高24位用cookie代替;
· 接下來的3比特位用客戶要求的最大報文長度MMS代替;
· 最后5比特位為t mod 32。
客戶端收到來自服務器SYN+ACK報文后，返回一個ACK報文，這個ACK報文將帶一個cookie(確認號為服務器發送過來的SYN ACK報文的初始序列號加1，所以不影響高24位)，在服務器端重新計算cookie，與確認號的前24位比較，如果相同，則說明未被修改，連接合法，然后，服務器完成連接的建立過程。
SYN-cookie技術由于在連接建立過程中不需要在服務器端保存任何信息，實現了無狀態的三次握手，從而有效地防御了SYN Flooding攻擊。但是該方法也存在一些弱點。由于cookie的計算只涉及了包頭的部分信息，在連接建立過程中不在服務器端保存任何信息，所以失去了協議的許多功能，比如超時重傳。此外，由于計算cookie有一定的運算量，增加了連接建立的延遲時間，因此，SYN-cookie技術不能作為高性能服務器的防御手段。通常采用動態資源分配機制，即分配了一定的資源后再采用cookie技術，Linux系統中的SYN-cookie就是這樣實現的。還有一個問題是，當我們避免了SYN Flooding攻擊的同時，也提供了另一種拒絕服務攻擊方式，攻擊者發送大量的ACK報文，使服務器忙于計算驗證。盡管如此，在預防SYN Flooding攻擊方面，SYN-cookie技術仍然是一種有效的技術。#p#
(2)地址狀態監控的解決方法
地址狀態監控的解決方法是利用監控工具對網絡中的有關TCP連接的數據包進行監控，并對監聽到的數據包進行處理。處理的主要依據是連接請求的源地址。
每個源地址都有一個狀態與之對應，總共有四種狀態：
· 初態：任何源地址剛開始的狀態;
· NEW狀態：第一次出現或出現多次也不能斷定存在的源地址的狀態;
· GOOD狀態：斷定存在的源地址所處的狀態;
· BAD狀態：源地址不存在或不可達時所處的狀態。
具體的動作和狀態轉換根據TCP頭中的位碼值決定。
① 監聽到SYN包，如果源地址是第一次出現，則置該源地址的狀態為NEW狀態;如果是NEW狀態或BAD狀態;則將該包的RST位置1然后重新發出去，如果是GOOD狀態不作任何處理。
② 監聽到ACK或RST包，如果源地址的狀態為NEW狀態，則轉為GOOD狀態;如果是GOOD狀態則不變;如果是BAD狀態則轉為NEW狀態;如果是BAD狀態則轉為NEW狀態。
③ 監聽到從服務器來的SYN ACK報文(目的地址為addr)，表明服務器已經為從addr發來的連接請求建立了一個半連接，為防止建立的半連接過多，向服務器發送一個ACK包，建立連接，同時，開始計時，如果超時，還未收到ACK報文，證明addr不可達，如果此時addr的狀態為GOOD則轉為NEW狀態;如果addr的狀態為NEW狀態則轉為BAD狀態;如果為addr的狀態為BAD狀態則不變。
地址狀態的轉換圖如圖2所示。
圖2 地址狀態轉換圖
下面分析一下基于地址狀態監控的方法如何能夠防御SYN Flooding攻擊。
對于一個偽造源地址的SYN報文，若源地址第一次出現，則源地址的狀態為NEW狀態，當監聽到服務器的SYN+ACK報文，表明服務器已經為該源地址的連接請求建立了半連接。此時，監控程序代源地址發送一個ACK報文完成連接。這樣，半連接隊列中的半連接數不是很多。計時器開始計時，由于源地址是偽造的，所以不會收到ACK報文，超時后，監控程序發送RST數據包，服務器釋放該連接，該源地址的狀態轉為BAD狀態。之后，對于每一個來自該源地址的SYN報文，監控程序都會主動發送一個RST報文。
對于一個合法的SYN報文，若源地址第一次出現，則源地址的狀態為NEW狀態，服務器響應請求，發送SYN+ACK報文，監控程序發送ACK報文，連接建立完畢。之后，來自客戶端的ACK很快會到達，該源地址的狀態轉為GOOD狀態。服務器可以很好地處理重復到達的ACK包。#p#
3. ACK Flooding
ACK Flooding攻擊是在TCP連接建立之后，所有的數據傳輸TCP報文都是帶有ACK標志位的，主機在接收到一個帶有ACK標志位的數據包的時候，需要檢查該數據包所表示的連接四元組是否存在，如果存在則檢查該數據包所表示的狀態是否合法，然后再向應用層傳遞該數據包。如果在檢查中發現該數據包不合法，例如該數據包所指向的目的端口在本機并未開放，則主機操作系統協議棧會回應RST包告訴對方此端口不存在。
這里，服務器要做兩個動作：查表、回應ACK/RST。這種攻擊方式顯然沒有SYN Flooding給服務器帶來的沖擊大，因此攻擊者一定要用大流量ACK小包沖擊才會對服務器造成影響。按照我們對TCP協議的理解，隨機源IP的ACK小包應該會被Server很快丟棄，因為在服務器的TCP堆棧中沒有這些ACK包的狀態信息。但是實際上通過測試，發現有一些TCP服務會對ACK Flooding比較敏感，比如說JSP Server，在數量并不多的ACK小包的打擊下，JSP Server就很難處理正常的連接請求。對于Apache或者IIS來說，10kbps的ACK Flooding不會構成危脅，但是更高數量的ACK Flooding會造成服務器網卡中斷頻率過高，負載過重而停止響應。可以肯定的是，ACK Flooding不但可以危害路由器等網絡設備，而且對服務器上的應用有不小的影響。
如果沒有開放端口，服務器將直接丟棄，這將會耗費服務器的CPU資源。如果端口開放，服務器回應RST。
利用對稱性判斷來分析出是否有攻擊存在。所謂對稱性判斷，就是收包異常大于發包，因為攻擊者通常會采用大量ACK包，并且為了提高攻擊速度，一般采用內容基本一致的小包發送。這可以作為判斷是否發生ACK Flooding的依據，但是目前已知情況來看，很少有單純使用ACK Flooding攻擊，通常都會和其他攻擊方法混合使用，因此，很容易產生誤判。
一些防火墻應對的方法是：建立一個hash表，用來存放TCP連接“狀態”，相對于主機的TCP協議棧實現來說，狀態檢查的過程相對簡化。例如，不作sequence number的檢查，不作包亂序的處理，只是統計一定時間內是否有ACK包在該“連接”(即四元組)上通過，從而“大致”確定該“連接”是否是“活動的”。#p#
4. UDP Flooding
UDP Flooding是日漸猖厥的流量型DoS攻擊，原理也很簡單。常見的情況是利用大量UDP小包沖擊DNS服務器，或Radius認證服務器、流媒體視頻服務器。100kbps的UDP Flooding經常將線路上的骨干設備例如防火墻打癱，造成整個網段的癱瘓。由于UDP協議是一種無連接的服務，在UDP Flooding攻擊中，攻擊者可發送大量偽造源IP地址的小UDP包。但是，由于UDP協議是無連接性的，所以只要開了一個UDP的端口提供相關服務的話，那么就可針對相關的服務進行攻擊。
正常應用情況下，UDP包雙向流量會基本相等，而且大小和內容都是隨機的，變化很大。出現UDP Flooding的情況下，針對同一目標IP的UDP包在一側大量出現，并且內容和大小都比較固定。
UDP協議與TCP 協議不同，是無連接狀態的協議，并且UDP應用協議五花八門，差異極大，因此針對UDP Flooding的防護非常困難。其防護要根據具體情況對待。
· 判斷包大小：如果是大包攻擊則使用防止UDP碎片方法。根據攻擊包大小設定包碎片重組大小，通常不小于1500。在極端情況下，可以考慮丟棄所有UDP碎片。
· 攻擊端口為業務端口：根據該業務UDP最大包的長度設置檢測UDP最大包以過濾異常流量。
· 攻擊端口為非業務端口：一個是丟棄所有UDP包，可能會誤傷正常業務;另一個是建立UDP連接規則，要求所有去往該端口的UDP包，必須首先與TCP端口建立TCP連接。不過這種方法需要很專業的防火墻或其他防護設備支持。
在網絡的關鍵之處使用防火墻對來源不明的有害數據進行過濾，可以有效減輕UDP Flooding攻擊。此外，在用戶的網絡中還應采取如下的措施。
· 禁用或過濾監控和響應服務。
· 禁用或過濾其他的 UDP 服務。
· 如果用戶必須提供一些 UDP 服務的外部訪問，那么需要使用代理機制來保護那種服務，保證它不會被濫用。
· 對用戶的網絡進行監控以了解哪些系統在使用這些服務，并對濫用的跡象進行監控。
· 對于一些小型的服務器，可以直接用防火墻添加規則的方法屏蔽掉。#p#
5. Connection Flooding
Connection Flooding是典型的并且非常的有效的利用小流量沖擊大帶寬網絡服務的攻擊方式，這種攻擊方式目前已經越來越猖獗。這種攻擊的原理是利用真實的IP地址向服務器發起大量的連接，并且建立連接之后很長時間不釋放，占用服務器的資源，造成服務器上殘余連接(WAIT狀態)過多，效率降低，甚至資源耗盡，無法響應其他客戶所發起的連接。
其中一種攻擊方法是每秒鐘向服務器發起大量的連接請求，這類似于固定源IP的SYN Flooding攻擊，不同的是采用了真實的源IP地址。通常這可以在防火墻上限制每個源IP地址每秒鐘的連接數來達到防護目的。但現在已有工具采用慢速連接的方式，也即幾秒鐘才和服務器建立一個連接，連接建立成功之后并不釋放并定時發送垃圾數據包給服務器使連接得以長時間保持。這樣一個IP地址就可以和服務器建立成百上千的連接，而服務器可以承受的連接數是有限的，這就達到了拒絕服務的效果。
另外，蠕蟲大規模爆發的時候，由于蠕蟲代碼比較簡單，傳播過程中會出現大量源IP地址相同的包，對于 TCP 蠕蟲，則表現為大范圍掃描行為。這是在判斷Connection Flooding時需要注意的。
該攻擊的一般表現形式是：在受攻擊的服務器上使用netstat –an命令來查看，會發現大量連接狀態來自少數的幾個源。如果統計的話，可以看到連接數對比平時出現異常。并且增長到某一閾值之后開始波動，說明此時可能已經接近性能極限。因此，對這種攻擊的判斷原則為：在流量上體現并不大，甚至可能會很小;出現大量的ESTABLISH狀態;新建的ESTABLISH狀態總數有波動。
防范該攻擊主要有如下方法。
· 主動清除殘余連接。
· 對惡意連接的IP進行封禁。
· 限制每個源IP的連接數。
· 可以對特定的URL進行防護。
· 反查Proxy后面發起HTTP Get Flood的源。
