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

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

2、的檢測(cè)和控制。 關(guān)鍵詞:狀態(tài)檢測(cè);應(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)檢測(cè)和應(yīng)用層代理是防火墻的兩種基本形式。 長(zhǎng)期以來(lái)有這樣一種認(rèn)識(shí):只有應(yīng)用層代理才能進(jìn)行應(yīng)用層 的控制。事實(shí)上,無(wú)論從 Checkpoint 公司關(guān)于狀態(tài)檢測(cè)技術(shù) 的白皮書(shū) 1, 還是從 Linux 內(nèi)核防火墻 Netfilter 2來(lái)看, 為了支 持 FTP 協(xié)議動(dòng)態(tài)打開(kāi)端口的特性 (一個(gè) FTP 應(yīng)用分為控制連接 和數(shù)據(jù)連接兩部分,這兩個(gè)連接使用不同的端口進(jìn)行數(shù)據(jù)傳 輸,而且數(shù)據(jù)連接的端口是動(dòng)態(tài)分配的 ,狀態(tài)檢測(cè)防火墻都 需要對(duì)數(shù)據(jù)

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

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

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

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

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

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

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

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

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

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

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

16、Linux 的 TCP/IP協(xié)議棧,定義自己的 ARP 包、 IP 包 處 理 函 數(shù) 。 Linux 網(wǎng) 絡(luò) 部 分 代 碼 中 有 一 個(gè) packet_ptype_base16 ( net/core/dev.c第 164行 數(shù)組, 這個(gè)數(shù) 組包含了需要接收數(shù)據(jù)包的協(xié)議,以及它們的接收函數(shù)的入 口 。 如 果 有 協(xié) 議 想 把 自 己 添 加 到 這 個(gè) 數(shù) 組 , 可 以 通 過(guò) dev_add_pack( (net/core/dev.c,第 233行 函數(shù)把要處理的數(shù)據(jù) 報(bào)協(xié)議和處理函數(shù)加到這里面來(lái)。本文就是通過(guò)這種方法, 重新定義了 ARP 、 IP 協(xié)議的結(jié)構(gòu)體來(lái)定義自己的 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)檢測(cè)模塊;第 3 狀態(tài)檢測(cè)圖 2 系統(tǒng)模塊劃分3.1 IP層的構(gòu)建ARP 包處理模塊用來(lái)實(shí)現(xiàn) ARP 協(xié)議,解決計(jì)算機(jī)的 MAC 地址與 IP 地址的映射。IP 包的處理模塊包含以下部分:(1碎片重組在所有被分片后的 IP 包中, 只有第 1個(gè)分片包含完整的 TCP 頭部信息,其他分片只有 IP 地址信息。只有對(duì)其重組, 狀態(tài)檢測(cè)模塊才能識(shí)別后續(xù)的數(shù)據(jù)包是否屬

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

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

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