基于TCP/IP協議的服務很多,人們比較熟悉的有WWW服務、FTP服務、電子郵件服務,不太熟悉的有TFTP服務、NFS服務、Finger服務等等。這些服務都存在不同程度上的安全缺陷,當用戶構建安全可信網絡時,就需要考慮,應該提供哪些服務,應該禁止哪些服務。同時,在使用這些服務的時候,你可能沒有想到,TCP/IP從一開始設計的時候就沒有考慮到安全設計。
TCP/IP存在脆弱性
IP層的主要曲線是缺乏有效的安全認證和保密機制,其中最主要的因素就是IP地址問題。TCP/IP協議用IP地址來作為網絡節點的惟一標識,許多TCP/IP服務,包括Berkeley中的R命令、NFS、X Window等都是基于IP地址對用戶進行認證和授權。當前TCP/IP網絡的安全機制主要是基于IP地址的包過濾(Packet Filtering)和認證(Authentication)技術,它的有效性體現在可以根據IP包中的源IP地址判斷數據的真實性和安全性。然而IP地址存在許多問題,協議的最大缺點就是缺乏對IP地址的保護,缺乏對IP包中源IP地址真實性的認證機制與保密措施。這也就是引起整個TCP/IP協議不安全的根本所在。
由于UDP是基于IP協議之上的,TCP分段和UDP協議數據包是封裝在IP包中在網絡上傳輸的,因此同樣面臨IP層所遇到的安全威脅。現在人們一直在想辦法解決,卻仍然無法避免的就是根據TCP連接建立時“三次握手”機制的攻擊(如圖1)。這些攻擊總結起來包括:
源地址欺騙(Source Address Spoofing)或IP欺騙(IP Spoofing);
源路由選擇欺騙(Source Routing Spoofing);
路由選擇信息協議攻擊(RIP Attacks);
鑒別攻擊(Authentication Attacks);
TCP序列號欺騙(TCP Sequence number spoofing);
TCP/IP協議數據流采用明文傳輸;
TCP序列號轟炸攻擊(TCP SYN Flooding Attack),簡稱SYN攻擊;
易欺騙性(Ease of spoofing)。

比如網管員都熟悉的因特網控制信息協議(ICMP),它是TCP/IP協議組的一個基本網絡管理工具,在幫助網絡管理人員排除網絡故障中立下了汗馬功勞,同時ICMP攻擊卻十分猖狂。最明顯的是ICMP重定向報文,它被網關用來為主機提供好的路由,卻不能被用來給主機的路由表進行主動的變化。如果入侵者已經攻破一個對目標主機來說可利用的次要網關,而不是基本網關,入侵者就可以通過有危險的次要網關給信任主機設置一個錯誤的路由。多數的服務主機在TCP重定向報文上不實行有效檢查,這種攻擊的影響和基于RIP的攻擊相似。
另外,ICMP也可以被用來進行拒絕服務攻擊(如圖2)。個別的報文如目標不可達或者超時,就可以用來重置目前的連接,如果入侵者知道TCP 連接的本地及遠端的端口號,將生成該連接的ICMP 報文。有時這樣的信息可以通過NETSTAT服務來實現。一個更普遍的拒絕服務攻擊是發送偽造的子網掩碼回應報文。無論主機是否查詢,它們都將接受該報文,一個錯誤的報文就可能阻塞目標主機的所有連接。

應用服務不容樂觀
1. 文件傳輸協議
FTP經久不衰的原因在于它可以在互聯網上進行與平臺無關的數據傳輸,它基于一個客戶機/服務器架構。FTP 將通過兩個信道(端口)傳輸,一個傳輸數據(TCP 端口 20),另一個傳輸控制信息(TCP 端口 21)。在控制信道之上,雙方(客戶機和服務器)交換用于發起數據傳輸的命令。一個 FTP 連接包含4個步驟:用戶鑒權→建立控制信道→建立數據信道→關閉連接。FTP 的連接控制使用 TCP (Transmission Control Protocol, 傳輸控制協議),它保障了數據的可靠傳輸。因此,FTP 在數據傳輸中不需要關心分組丟失和數據錯誤檢測。
匿名FTP作為互聯網上廣泛應用的服務,安全等級的低下受到了黑客的頻繁光顧。匿名FTP 是真的匿名,并沒有記錄誰請求了什么信息,誰下載了什么文件,上傳了什么東西(有可能是木馬)。FTP存在著致命的安全缺陷,FTP使用標準的用戶名和口令作為身份驗證,缺乏有效的訪問權限的控制機制,而其口令和密碼的傳輸也都是明文的方式。
2. Web服務
Web服務器位于宿主基礎結構的前端,它與Internet直接相連,負責接收來自客戶端的請求,創建動態Web頁并響應請求數據。最初WWW服務只提供靜態的HTML頁面,為改變人們對網絡互動請求的愿望,開始引入了CGI程序,CGI程序讓主頁活動起來。CGI程序可以接收用戶的輸入信息,一般用戶是通過表格把輸入信息傳給CGI程序的,然后CGI程序可以根據用戶的要求進行一些處理,一般情況下會生成一個HTML文件,并傳回給用戶。很多CGI程序都存在安全漏洞,很容易被黑客利用做一些非法的事情。現在很多人在編寫CGI程序時,可能對CGI軟件包中的安全漏洞并不了解,而且大多數情況下不會重新編寫程序的所有部分,只是對其加以適當的修改,這樣很多CGI程序就不可避免的具有相同的安全漏洞。很多SQL Server 開發人員并沒有在代碼編寫開始的時候就從安全防護基礎開始,這樣就無法確保您開發的代碼的安全性,其結果就造成了無法將應用程序的運行控制在所需的最低權限之內。
如果Web 服務需要輸出敏感的、受限的數據,或者需要提供受限的服務,則它需要對調用方進行身份驗證。如果客戶訪問都是在一個可信的域中,我們就完全可以放心使用,但在實際應用中是不可能實現的。所以,系統級的身份驗證也就無法實現,至少在現階段無法實現。例如:可以使用IIS為基本身份驗證配置Web服務的虛擬目錄。通過這種方式,使用者必須配置代理,并提供用戶名和密碼形式的憑據。然后在每次Web服務通過代理請求的時候由代理傳遞它們。這些憑據是以明文形式傳遞的,所以應該只在SSL中使用基本身份驗證(如圖3),但很少有管理員這樣做。

另外,Web服務本身不提供容錯機制。如果Web服務采用了軟件冗余技術,就可以保證一個版本出錯,另一個版本就很少有機會出現相同的錯誤。代碼的重復利用不能保證錯誤的完全避免,因此在某個模塊發生某個物理故障時,其他模塊也就完全癱瘓。
隨著Java Applet、ActiveX、Cookie等技術的大量應用,當用戶使用瀏覽器查看、編輯網絡內容時,采用了這些技術的應用程序會自動下載并在客戶機上運行,如果這些程序被惡意使用,就可能竊取、改變或刪除客戶機上的信息。對于惡意程序的侵害,用戶很難實時判斷程序性質,因此,在獲得高度交互的Web服務時,如何抵御這些安全威脅絕非簡單的客戶端設置就可以解決的。
提高網絡可信度
前面我們已經提到了IPv4存在的弊端,很多安全防范技術被忽略了,它不可避免地被新一代技術IPv6取代。IPsec安全協議就是事后發展的一種協議(如圖4),而NAT(網絡地址轉換,Network Address Translation)解決了IP地址短缺的問題,卻增加了安全風險,使真正的端到端的安全應用難以實現。端到端安全性的兩個基本組件——鑒權和加密都是IPv6協議的集成組件;而在IPv4中,它們只是附加組件,因此,采用IPv6安全性會更加簡便、一致。

在現在的網絡環境中,尤其是園區網當中,由于不存在NAT地址轉換的問題,所以IPSec具備允許部署可信計算基礎架構的基本特征。IPSec數據包驗證能夠確保整個IP報頭、下一層協議(例如TCP、UPD或ICMP)報頭以及數據包有效負載的數據完整性。
另外,針對數據包的單向Hash算法用以提供校驗和。通信發起方計算校驗和并在發送之前將其附加到數據包中;響應方則在收到數據包后為其計算校驗和。如果響應方所計算出的校驗和與數據包中附帶的校驗和完全匹配,則證明數據包在傳輸過程中未被修改。校驗和的單向計算特性意味著其取值無法在傳輸過程中進行修改,這也就保證了端到端的數據傳輸過程的可信程度。