應(yīng)用層協(xié)議分析在狀態(tài)檢測防火墻中的應(yīng)用

1、2007年 2月February 2007 154 計 算 機 工 程 Computer Engineering第 33卷 第 3期Vol.33 No.3 ·安全技術(shù) ·文章編號:1000 3428(200703 0154 03文獻標(biāo)識碼:A中圖分類號:TP393.08應(yīng)用層協(xié)議分析在狀態(tài)檢測防火墻中的應(yīng)用郭錫泉(廣東番禺職業(yè)技術(shù)學(xué)院軟件學(xué)院,廣州 511483摘 要:闡述了狀態(tài)檢測技術(shù)的實現(xiàn),分析了 FTP 、 Web 和郵件服務(wù)的安全需求,在此基礎(chǔ)上把應(yīng)用層協(xié)議分析技術(shù)應(yīng)用到狀態(tài)檢測防火 墻中,給出了在 Linux 系統(tǒng)上的實現(xiàn)方案,使?fàn)顟B(tài)檢測防火墻能更有效地進行應(yīng)用層

2、的檢測和控制。 關(guān)鍵詞:狀態(tài)檢測;應(yīng)用層協(xié)議分析;防火墻; LinuxAdoption of Application Level Protocols Analysis on StatefulInspection FirewallsGUO Xiquan(School of Software, Panyu Polytechnic, Guangzhou 511483【 Abstract 】 The realization of stateful inspection technic and the security requirements of FTP, Web and E-mail servic

3、es are proposed. On the baseof the above analysis, the adoption of application level protocols analysis on stateful inspection firewalls with its implementation on Linux isdiscussed. It turns out to make stateful inspection firewalls to have more control on application level protocols. 【 Key words】

4、Stateful inspection; Application level protocols analysis; Firewall; Linux當(dāng)前, 狀態(tài)檢測和應(yīng)用層代理是防火墻的兩種基本形式。 長期以來有這樣一種認識:只有應(yīng)用層代理才能進行應(yīng)用層 的控制。事實上,無論從 Checkpoint 公司關(guān)于狀態(tài)檢測技術(shù) 的白皮書 1, 還是從 Linux 內(nèi)核防火墻 Netfilter 2來看, 為了支 持 FTP 協(xié)議動態(tài)打開端口的特性 (一個 FTP 應(yīng)用分為控制連接 和數(shù)據(jù)連接兩部分,這兩個連接使用不同的端口進行數(shù)據(jù)傳 輸,而且數(shù)據(jù)連接的端口是動態(tài)分配的 ,狀態(tài)檢測防火墻都 需要對數(shù)據(jù)

5、包應(yīng)用層的內(nèi)容進行分析。由此可見,狀態(tài)檢測 防火墻也能進行應(yīng)用層的檢測和控制。但是,到底狀態(tài)檢測 防火墻能在多大程度上進行應(yīng)用層檢測以及如何進行應(yīng)用層 檢測,仍然是一個模糊不清的問題。為了探究和解答這個問題,本文把應(yīng)用層協(xié)議分析技術(shù) 應(yīng)用到狀態(tài)檢測防火墻,即在實現(xiàn)狀態(tài)檢測技術(shù)時,不但分 析數(shù)據(jù)包網(wǎng)絡(luò)層、傳輸層的內(nèi)容,還對數(shù)據(jù)包應(yīng)用層的內(nèi)容 進行全面的分析。1 狀態(tài)檢測技術(shù)的實現(xiàn)狀態(tài)檢測是以色列 CheckPoint 公司提出的技術(shù),是動態(tài) 包過濾技術(shù)的一種改進。將簡單的包過濾孤立地看成一個個 的數(shù)據(jù)包,割裂了數(shù)據(jù)包之間的聯(lián)系。狀態(tài)檢測則以會話為 單位看待一個個的數(shù)據(jù)包,透過一個個的數(shù)據(jù)包看到的

6、是一 個個的“連接”。狀態(tài)檢測首先獲得數(shù)據(jù)包本身的狀態(tài),如果 這個狀態(tài)與該連接處的狀態(tài)不同,狀態(tài)檢測可以禁止這個數(shù) 據(jù)包通過。這種技術(shù)還試圖理解更高層協(xié)議 (應(yīng)用層協(xié)議 并 自動調(diào)整過濾規(guī)則來滿足協(xié)議的具體需要 (例如對 FTP 報 文 。 它也可應(yīng)用到 UDP 、 ICMP 協(xié)議中, 建立一個虛擬會話, 在一個不存在安全的地方提供一種安全狀態(tài)。1.1 TCP協(xié)議的狀態(tài)檢測TCP 協(xié)議是面向連接的傳輸層協(xié)議,建立連接之前要進 行“三次握手” ,關(guān)閉連接之前又有“四次握手” 。 TCP 頭的 字段很豐富,除了源端口、目的端口之外,還有序列號、窗 口值、標(biāo)志位等。對 TCP 協(xié)議進行狀態(tài)檢測的關(guān)鍵

7、是處理 TCP 的有限狀態(tài)機,處理流程如圖 1所示。圖 1 TCP協(xié)議的狀態(tài)檢測流程1.2 UDP協(xié)議的狀態(tài)檢測UDP 協(xié)議本身是沒有狀態(tài)的, 但仍然可以用與跟蹤 TCP 協(xié)議相類似的方法對它進行處理。其基本原理是:接收到 UDP 包后,如果它要發(fā)起一個新連接,那么要接受規(guī)則表的 檢查,規(guī)則允許的話則創(chuàng)建狀態(tài)表項、置定時器 (譬如定時 60s , 60s 后沒有相關(guān)的數(shù)據(jù)包通過,這個連接相應(yīng)的狀態(tài)表 項將被刪除 后給予放行,否則會被拋棄。如果該數(shù)據(jù)包從屬 于某個 UDP 連接, 那么要查找狀態(tài)表進行驗證, 匹配的話則作者簡介:郭錫泉 (1979- ,男,助教、碩士,主研方向:計算機通 信,網(wǎng)絡(luò)

8、安全, Linux 系統(tǒng)收稿日期:2006-02-23 E-mail :guoxq給予放行,并重置定時器。這樣,一個 UDP 連接從發(fā)起到關(guān) 閉,都在狀態(tài)檢測的控制之下。1.3 ICMP協(xié)議的狀態(tài)檢測ICMP ,即 Internet 控制報文協(xié)議,它傳遞差錯報文以及 其他需要注意的信息。 ICMP 報文是在 IP 數(shù)據(jù)報內(nèi)部被傳輸 的,第 1個字節(jié)為類型字段,第 2個字節(jié)為代碼字段,類型 字段的取值分別為 0、 3、 4、 5、 8至 18。對 ICMP 報文應(yīng)該 分類處理:(1有些報文是要丟棄的,分別是 4、 5類型。后者對防 火墻內(nèi)部的網(wǎng)絡(luò)而言是不需要的,只是對網(wǎng)絡(luò)上的路由器有 作用。前者

9、的作用是通知源站減緩發(fā)送數(shù)據(jù)報的速率,目的 站由于某種原因來不及處理報文。而現(xiàn)在的計算機有足夠的 能力來處理 IP 報文,網(wǎng)絡(luò)的瓶頸在于帶寬而不是主機。鑒于 第 4類的報文很容易會被用來做非法攻擊,而且在實際使用 中一般也很少,因此可以不處理這種報文。(2有些報文是通告情況的,由一方發(fā)出,另一方不用回 應(yīng)。這些類型的報文可以直接通過防火墻,包括 3、 9、 10、 11、 12類型的報文。(3剩下 4對報文都有請求回應(yīng)的關(guān)系,有必要對它們 實現(xiàn)狀態(tài)檢測。具體的做法為:對于請求型的報文,接受規(guī) 則表的檢查,規(guī)則允許的話則創(chuàng)建狀態(tài)表項;對于回應(yīng)型的 報文,直接和狀態(tài)表比較,匹配的話則予以放行。2

10、在狀態(tài)檢測之上實現(xiàn)應(yīng)用層協(xié)議分析目前,針對應(yīng)用層的攻擊越來越多,因此要求防火墻有 抵御應(yīng)用層攻擊的能力。很多防火墻產(chǎn)品都提供應(yīng)用層的內(nèi) 容過濾,但它們大都基于字符串匹配的方式進行。這種簡單 的方式缺乏對應(yīng)用層協(xié)議的深入分析,不能發(fā)現(xiàn)潛在的攻擊 行為。把應(yīng)用層協(xié)議分析技術(shù)應(yīng)用到狀態(tài)檢測防火墻中,可 使防火墻的檢測范圍更全面,而且有抵御未知攻擊的能力。 而狀態(tài)檢測技術(shù)是以包過濾的形態(tài)進行應(yīng)用層協(xié)議分析的, 所以效率和速率都相當(dāng)高。目前選擇了 FTP 、 SMTP 、 POP 、 HTTP 4種最常用的協(xié)議來實現(xiàn)應(yīng)用層的檢測。應(yīng)用層協(xié)議分析的難點是:(1要在包過濾的形式下實現(xiàn)應(yīng)用層的檢測;(2應(yīng)用層

11、協(xié)議復(fù)雜多樣;(3攻擊手段種類繁多?？偟膩碚f,應(yīng)用層協(xié)議分析的機制主要有以下 4方面:(1驗證是否遵循相關(guān)協(xié)議的標(biāo)準(zhǔn);(2驗證協(xié)議是否遵循預(yù)期用法;(3限制應(yīng)用程序攜帶惡意數(shù)據(jù)的能力;(4控制應(yīng)用層操作。以上機制在不同的應(yīng)用層協(xié)議中會有不同的體現(xiàn)。 2.1 FTP服務(wù)的安全需求(1支持動態(tài)打開端口在進行數(shù)據(jù)連接時,無論是主動模式還是被動模式,防 火墻都要識別出即將打開的端口,使得新的連接得以建立; 數(shù)據(jù)傳輸完成之后,防火墻要自動關(guān)閉新打開的端口。 (2控制 FTP 命令防火墻能夠識別 FTP 命令。用戶可以定義一些不安全的 命令,當(dāng)防火墻在數(shù)據(jù)包中發(fā)現(xiàn)這些不安全的命令時,應(yīng)當(dāng) 禁止數(shù)據(jù)包通過。

12、(3限制文件的傳輸在進行上傳、下載文件的操作時,防火墻能夠識別文件 名。用戶可以定義一些禁止傳輸?shù)奈募拿?。?dāng)防火墻發(fā) 現(xiàn)數(shù)據(jù)包中準(zhǔn)備傳輸?shù)奈募谟脩艚怪?應(yīng)當(dāng)禁止該數(shù) 據(jù)包通過。(2和 (3都立足于 FTP 服務(wù)器,為了防止 FTP 服務(wù)器受 到攻擊。2.2 Web服務(wù)的安全需求(1識別 HTTP 報文的各個字段,限制 URI 的最大長度、 請求頭信息的最大長度和響應(yīng)頭信息的最大長度。盡管 HTTP 協(xié)議沒有規(guī)定上述字段的最大長度, 但實際中 這些字段不應(yīng)該太長, 限制這些字段的最大長度是符合 HTTP 協(xié) 議 的 預(yù) 期 用 法 的 。 網(wǎng) 上 流 傳 的 Web 攻 擊 程 序 w

13、ebdav3.exe(作 者 isno 3在 利 用 微 軟 的 IIS 服 務(wù) 器 來 觸 發(fā) webdav 漏洞時就是通過發(fā)送超長報文來實現(xiàn)的,請求的報文 如下:SEARCH /buffer(>65513 bytes HTTP/1.0值得注意的是,在請求報文的請求行中,請求資源的 URI(即 buffer 出乎意料得長, 可是 IIS 并沒有理會這種異常, 于是這個攻擊程序就能夠長驅(qū)直入了。如果限制了某些字段 的最大長度,那么 webdav 攻擊將不能奏效,那些通過構(gòu)造 超長報文、 類似 webdav 的攻擊方法也將不能起作用, 這正是 協(xié)議分析能夠抵御未知攻擊的原因。(2識別并阻隔

14、動態(tài)文檔的執(zhí)行曾一度興風(fēng)作浪的尼姆達 (Nimda病毒, 其主要傳播方式 之一就是從 Web 服務(wù)器傳播到客戶端, 即當(dāng)客戶端瀏覽受影 響的站點時, 尼姆達會通過一個 Javascript 小程序使客戶端馬 上受到感染。由此可以體會到動態(tài)文檔的威力、腳本語言和 ActiveX 控件的可怕,而防火墻也有必要能夠阻隔動態(tài)文檔 的執(zhí)行。(3阻隔用戶定義的 URL在很多應(yīng)用場合中,都要求防火墻能夠阻隔用戶定義的 URL ,以保證網(wǎng)絡(luò)的安全或信息的健康。2.3 E-mail服務(wù)的安全需求電子郵件是 Internet 上使用最廣泛的服務(wù)之一, SMTP 、 POP 是郵件系統(tǒng)最常用的協(xié)議。電子郵件引發(fā)的安

15、全問題相 當(dāng)突出,垃圾郵件、病毒郵件是當(dāng)前最令用戶頭疼的問題。 嚴格說來,垃圾郵件已經(jīng)超出了網(wǎng)絡(luò)安全的范疇,很多反垃 圾郵件的措施不適宜、也沒必要在防火墻中部署。這里集中 分析病毒郵件的檢測。對病毒郵件的檢測可以采用基于特征 匹配的模式,即如果郵件具有一個或多個特征,那么就判定 它是病毒郵件。這些特征包括:(1特定類型的 MIME 附件。(2特定名稱的附件。(3郵件主體中的特定內(nèi)容。3 系統(tǒng)的實現(xiàn)系統(tǒng)選擇在開放源代碼的 Linux 上實現(xiàn)。一種方式是利 用 Linux 內(nèi)核防火墻 Netfilter 鉤子函數(shù)的機制,注冊自己的 應(yīng)用層協(xié)議分析模塊來實現(xiàn)。本文選擇了另外一種更徹底的 方式:放棄

16、Linux 的 TCP/IP協(xié)議棧,定義自己的 ARP 包、 IP 包 處 理 函 數(shù) 。 Linux 網(wǎng) 絡(luò) 部 分 代 碼 中 有 一 個 packet_ptype_base16 ( net/core/dev.c第 164行 數(shù)組, 這個數(shù) 組包含了需要接收數(shù)據(jù)包的協(xié)議,以及它們的接收函數(shù)的入 口 。 如 果 有 協(xié) 議 想 把 自 己 添 加 到 這 個 數(shù) 組 , 可 以 通 過 dev_add_pack( (net/core/dev.c,第 233行 函數(shù)把要處理的數(shù)據(jù) 報協(xié)議和處理函數(shù)加到這里面來。本文就是通過這種方法, 重新定義了 ARP 、 IP 協(xié)議的結(jié)構(gòu)體來定義自己的 AR

17、P 、 IP 155協(xié)議處理函數(shù)。防火墻系統(tǒng)工作在路由模式,有兩塊網(wǎng)卡:一塊與外部網(wǎng)絡(luò)相連,另一塊與內(nèi)部網(wǎng)絡(luò)相連。系統(tǒng)的模塊 劃分如圖 2所示, 第 1部分是 ARP 包處理模塊, IP 包接收及 攻擊防范模塊、發(fā)送模塊;第 2部分是狀態(tài)檢測模塊;第 3 狀態(tài)檢測圖 2 系統(tǒng)模塊劃分3.1 IP層的構(gòu)建ARP 包處理模塊用來實現(xiàn) ARP 協(xié)議,解決計算機的 MAC 地址與 IP 地址的映射。IP 包的處理模塊包含以下部分:(1碎片重組在所有被分片后的 IP 包中, 只有第 1個分片包含完整的 TCP 頭部信息,其他分片只有 IP 地址信息。只有對其重組, 狀態(tài)檢測模塊才能識別后續(xù)的數(shù)據(jù)包是否屬

18、于該次連接的一 部分。(2IP首部校驗和根據(jù) RFC1071(Computing the Internet Checksum計算 IP 首部校驗和,對數(shù)據(jù)包進行校驗。(3網(wǎng)關(guān)功能為數(shù)據(jù)包進行路由轉(zhuǎn)發(fā),使數(shù)據(jù)包從防火墻的一個網(wǎng)絡(luò) 接口進入,從另一個網(wǎng)絡(luò)接口轉(zhuǎn)發(fā)出去。(4攻擊防范使防火墻具備抵御拒絕服務(wù)攻擊 (DOS、端口掃描的能 力,增強防火墻的自身安全和抗攻擊能力。3.2 狀態(tài)檢測實現(xiàn)狀態(tài)檢測技術(shù)時,可在 Linux 內(nèi)核空間里維護兩張 表:規(guī)則表和狀態(tài)表。規(guī)則表是用戶根據(jù)需要定義的;狀態(tài) 表是程序動態(tài)生成和管理的。一個數(shù)據(jù)包來到,首先和狀態(tài) 表比較,如果它從屬于某個連接,這個數(shù)據(jù)包可獲得放行

19、。 如果狀態(tài)表里沒有相關(guān)的記錄,轉(zhuǎn)而與規(guī)則表進行比較。如 果該數(shù)據(jù)包要發(fā)起一個新連接而規(guī)則又允許的話,就在狀態(tài) 表里添加一項來標(biāo)識這個連接;規(guī)則不允許的話這個數(shù)據(jù)包 將被拋棄。具體實施時根據(jù)前面的分析對 TCP 、 UDP 、 ICMP 協(xié)議分類處理即可。3.3 應(yīng)用層協(xié)議分析應(yīng)用層協(xié)議分析也要分協(xié)議進行。首要的工作是識別應(yīng) 用層報文的各個字段。譬如, HTTP 報文的每一個字段都是 從一個新的行開始,并在字段名的后面加上冒號和該字段的 值;而且報文是以 ASCII 碼表示的。明確了這兩點,再配合 簡單的字符串匹配算法,就能準(zhǔn)確、快速地對 HTTP 報文進 行協(xié)議分析。另外,防火墻還需要提供一

20、個界面給用戶管理防火墻, 進行增加、刪除和保存規(guī)則等操作。表 1詳細說明了防火墻 系統(tǒng)的狀態(tài)檢測、應(yīng)用層協(xié)議分析的過濾功能。表 1 防火墻過濾功能列表ICMP(1能識別輸入設(shè)備、輸出設(shè)備、源地址、目的地 址、 ICMP 報文類型(2根據(jù)規(guī)則表進行過濾UDP(1能識別輸入設(shè)備、輸出設(shè)備、源地址、目的地 址、源端口、目的端口(2根據(jù)規(guī)則表進行過濾狀態(tài)檢測TCP(1能識別輸入設(shè)備、輸出設(shè)備、源地址、目的地 址、源端口、目的端口(2識別一個 TCP 連接中雙方所處的狀態(tài)(3根據(jù)規(guī)則表進行過濾FTP(1支持主動模式或被動模式下的動態(tài)打開端口(2能控制 FTP 命令的執(zhí)行(3限制文件的傳輸HTTP(1識別 HTTP 報文的各個字段, 限制 URI 的最大 長度、請求頭信