網頁應用程式防火牆

網頁應用程式防火牆(Web Application Firewal, WAF)的設計宗旨是防禦針對web應用程式的常見攻擊,諸如跨網站攻擊(cross-site scripting)以及SQL injection攻擊。網路防火牆負責防禦網路的邊界,而WAF則位於網頁瀏覽者與網頁伺服器間,專責分析「應用層」的網路流量內容,並依據事先設計好的安全政策,發掘違反安全政策的封包;安全顧問公司Cobweb Applications創辦人Michael Cobb如是表示。

雖然傳統防火牆在某些程度上可以辨識「應用層」的封包內容,但他們在這方面的功能不如WAF來的細緻及針對性;Security Curve顧問公司創辦人Diana Kelley表示。譬如,當應用程式的行為不符其原本設計,WAF可以偵測這樣的狀況。同時你可以為WAF撰寫特定的規則,以防止類似的攻擊再度發生。

WAF與入侵防禦系統(Intrusion Prevention Systems, IPS)亦有差別。「WAF採用相當不同的技術 – 它不是依據特徵碼辨識攻擊(signature-based),而是分析網路行為,而且它可以保護你自己「不小心」所製造出的漏洞」,Gartner分析師Greg Young表示。

驅使人們採用WAF的主因源自於「支付卡行業資料安全標準」(Payment Card Industry Data Security Standard,PCI DSS)的產生,此標準訂出兩項符合標準的方法:安裝WAF,以及施行「源碼檢測」(code review)。但是除了法規要求外,大眾對於「攻擊目標已由網路轉至應用程式」的認知亦有推波助瀾之效。WhiteHat Security公司在2006年1月至2008年12月針對877個網站所做的研究報告顯示,有百分之82的網站至少有一個屬於高度、重大、或緊急的安全問題。

WAF市場目前定義不清,仍有許多性質不同的產品歸類於WAF的範疇。「許多產品所提供的功能已超越一般人員對於防火牆的既有認知,」Burton Group分析師Ramon Krikken表示,「這讓評估和比較產品的工作變得困難。」此外,新的廠商藉由將現存的「非WAF」產品擴充至「整合式」產品線,而伺機跨足WAF市場。以下為WAF應該有的特性列表。此列表依據Xiom顧問公司創辦人Ofer Shezaf所提供的列表而製:

.能夠充分瞭解HTTP通訊協定:WAF需要能夠充分解析HTTP協定才能夠發揮實效。 

.提供「正向安全模型」(positive security model) 

(positiveBsecurityBmodel):「正向安全模型」只允許合法的網路傳輸通過。此機制有時被稱作「正面表列」(white-listing),它為應用程式外部增加了一個「輸入驗證」(input validation)的保護層。(註:軟體安全的一項基礎工作就是輸入驗證,以檢查由外部輸入的字串是否合法,這項檢查通常是由程式設計師撰寫於應用程式中。駭客也常藉由應用程式的輸入驗證工作沒做好而入侵得逞。WAF的正向安全模型協助加強輸入驗證的工作。) .提供「應用層」等級的安全規則:由於「正向安全模型」會耗用較多系統效能,因此需輔以「特徵碼辨識系統」(signatured-based system)以辨識攻擊。但由於Web應用程式是使用者自行所開發,因此傳統依據已知漏洞而撰寫的攻擊特徵碼便成效有限。WAF的安全規則必須具備通泛性(generic),如此才可以偵測攻擊所衍生的任何變種。(註:特徵碼辨識運作效率高,但傳統上以偵測已知攻擊為主;正向安全模型可防止未知攻擊,但運作效率相對較低。) 

.以網路連線為基礎的保護(session-based protection):HTTP最大的缺點之一在於其缺乏可靠的連線管理機制,因此WAF必須補足HTTP的不足,做好HTTP連線管理機制。

.提供「政策微調」的管理機制:當例外情形發生時,要讓例外狀況僅套用於應用程式發生例外狀況部分,而非全面套用整個應用程式。否則當誤報(false positives)發生,就需放寬例外條件導致降低安全保護。 

OWASP(Open Web Application Security Project)是一個致力於加強應用程式安全的公開社群,其建議以下WAF的評選標準:

* 誤報情形(盡可能不攔截正常封包)。

* 預設安全規則的健全度(預設的安全規則能否阻擋基本攻擊?是否需要另作許多調校?)。 

* 效能、是否易於學習。

* 保護的漏洞種類是否齊全。

* 是否能夠限定每一位使用者,只看到他們所連線範圍的資料。

* 只否能經過設定就可以保護特定的安全問題/漏洞,其效能如同安裝了緊急修補程式。

* 軟體式或硬體式WAF(一般較偏愛硬體式)。

由於WAF只能即時保護應用程式,而不能修復應用程式的漏洞,所以在過去曾遭受一些批評。有些廠商對於WAF一詞謹慎保留,反而還比較偏愛「應用程式辨識」(application awareness)或「應用層智慧」(application-layer intelligence)等術語;Kelly表示。然而,如今大眾共識已逐漸形成:當WAF被正確建置,它便可在多層次安全架構中扮演一個重要的角色,原因是WAF在防禦攻擊的同時,讓你有緩衝時間修復應用程式的漏洞。

WhiteHat Security公司創辦人Jeremiah Grossman在其部落格中表示:應用程式漏洞太多,修復工作根本無法跟上程式開發進度。他倡議,在檢查應用程式時所發現的漏洞,可以採客製化規則的形式納入WAF,如此不但可以立即防止攻擊,還可以於日後再從程式碼著手,修補安全問題。

Gartner研究機構則建議客戶考慮「修補應用程式漏洞」的相關技術。Young表示:「在花掉你的第一塊錢之前,請思考你是否是透過一套更強大的「系統開發生命週期」,以及使用像「源碼掃描」等工具,來執行修復漏洞的工作。」對於那些很難修改、不可能修改、或高度動態的應用程式而言,WAF便顯得更為有用。 

他說,對於大部分的公司而言,在WAF以及「源碼檢測」兩者間擇一採用便已足夠;雖然有少部分的公司難以承受風險,需要同時採用兩項技術。

對Jack Nelson而言,選用Check Point公司兼具web智慧(web intelligence)技術的VPN-1/FireWall-1的閘道器的主因,是該產品同時提供硬體及軟體的兩個選項設定;Nelson是Jarden Consumer Solutions公司全球網路服務及維運的IT協理。Jarden的部分遠端辦公室並沒有IT人員,因此Nelson使用軟體版本的WAF可讓事情變得簡單,當上線的WAF故障,遠端辦公室經理只要重新設定任何一台PC,讓其成為WAF就可以繼續防護。「與需要再購買第二台防火牆相較,此舉提供更多的彈性;與購買「快速修復」服務所需成本相較,則更為划算。」Nelson說。操作介面非常簡單,不需要防火牆專家,而且透過鍵盤輸入授權碼便可啟用系統,因此你在遠端就可操作。Nelson在北美部分的小公司則採用Check Point的小型硬體設備,因為他發現這樣作會更好管理以及支援。 

 Inline或out-of-band的部署方式 

在最開始,一項重要的工作是需決定要將WAF部署成inline模式或者out-of-band模式,因為並非所有的WAF都支援這兩種模式。Young說:「我常會看到少數可以支援不同部署模式的產品,有時也會看到有些產品不支援這些先進的部署方式。」 

以下列出一些企業在評估WAF時的一些基本要點:

 確實瞭解獨立式(stand-alone)與整合式(integrated)產品間的差異 

有些廠商會將WAF的功能加入他們現有的「應用程式遞送」(application delivery)產品或網路安全產品中;有些廠商則專注於應用軟體安全 — 你需要充分瞭解這兩類產品的差別。產品合適與否,取決於多重因素,包括:你已安裝了哪些產品;你需要的安全等級;你比較喜歡專精特定功能的產品,或是廣泛涵蓋各種功能的產品。(譯注:「應用程式遞送」指:平衡負載、網路快取、網路加速)

Krikken提到,主要功能為「應用程式遞送」的WAF產品由於需要達到「線速」(wire speed),因此產品不會內建需耗用大量CPU資源的模組;這些模組諸如:「學習引擎」以及「連線辨識」(session awareness)。他說:「這類整合式WAF多數功能非常受限,僅有『正面列表』/『反面列表』,以及單純檢查進出內容的功能。」「學習引擎」可以讓WAF學習應用程式的行為,並且產生建議政策。「連線辨識」讓WAF即時建立「以連線為基礎」、動態的安全規則,而且可立即利用這些規則決定後續的網路封包是否合法。(譯注:當WAF處於inline模式,就必須達到「線速」,否則會拖垮網路的速度。整合式WAF一般而言較專屬式硬體WAF執行效能差,欲達到「線速」無法同時涵蓋太多功能。)

Nelson為公司的VPN以及外部的Web應用程式選用Check Point的整合式產品。此產品不單獨僅擔任應用程式防火牆,它同時還處理眾多網路安全問題,這對公司非常重要。他說:「我們需要能同時聚集各種功能,而且不讓『執行效能』及『管理方便性』打折扣的產品。」

另一方面,汽車零件供應商AutoAnything.com則利用Breach Security公司的獨立式WAF,保護公司的電子商務系統。CTO Parag Patel採用與Nelson完全相反的策略,他說:「一個安全產品能包山包海作好每個環節,非常罕見。」

許多公司因為需要符合PCI規範而安裝WAF。這些公司將「安裝WAF」作為一個應付用的檢查項目,分析師對此提出警訊。

「我曾看過許多不當的花費及錯誤,」Young說道,「大部分的人認為,只要買了WAF,稽核人員就會閃人;但這仍有不足。你必須客製化WAF的應用程式防禦規則,才能讓WAF融入現存的網路環境中。」 

Krikken表示,雖然WAF的傳統客戶以安全人員為大宗,但由於許多WAF提供分析功能、支援單一簽入、以及可與Web服務安全整合,因此這些多功能的WAF產品已獲更多人員的青睞。Krikken建議,評估WAF同時,需要一併考量WAF在支援:企業架構、應用程式遞送、以及軟體開發流程方面的功能。「這樣將會增加我們對於解決方案在處理安全方面的信心,同時消除我們對WAF在可用性以及執行效能方面的疑慮。」他說。

以某間跨國能源公司為例,這家公司因先有「服務導向架構」(Service-Oriented Architecture, SOA)的安全服務的需求,才決定使用WAF。此公司的首席架構師早期決定採用Reactivity XML加速安全設備,後來Cisco公司併購此設備,再將此設備轉變成Cisco ACE WAF。當這家能源公司決定要採用可直接阻擋來自Internet攻擊的WAF時,Cisco向這家公司擔保,此能源公司一方面可利用ACE WAF滿足內部SOA的安全需求,另一方面可利用它保護web應用程式。

「應用程式監控」是WAF的非傳統功能、而且已經漸漸普遍的應用。而WAF可以偵測應用程式效能面的問題,以及檢查應用程式是否因存在殘破連結(broken links)而呈現錯誤網頁。

雖然你可以使用WAF預設提供的「負面表列」規則,以達到基本的安全要求,但你仍需對所有的web應用程式投注持續的時間以及努力(超簡單web應用程式除外)。「即使搭配『規則範本』以及『學習引擎』,常常,你仍需要期初的調校以及後續不間斷的客製化工作,才能優化系統的實效性以及減少誤判。」Krikken表示。

之前提到跨國能源公司的首席建構師便提到,他的公司有能力在兩個小時之內利用Cisco WAF完成一項use case的設定,然而,他更樂見廠商能提供更多的「最佳實踐指南」以說明如何完成像「字元過濾」(character filtering)的設定,而非讓他們自己艱難的拼湊出自己的設定。 

有了「學習引擎」,WAF就可以瞭解應用程式的行為,並建立規則,然後利用這些規則強化安全。Krikken表示,在高度動態的環境中,當發現了異常可疑行為,讓WAF警示你,比讓WAF直接攔阻這些異常行為,還要好。

Patel利用Breach公司WAF的學習引擎,在數個月間為其web應用程式建立了的輪廓狀態(profile)。在WAF的自我學習期間,發現了不尋常的行為,並供Patel的團隊檢視。「你需要某種程度的放心,就是WAF能夠做出正確的動作。」Patel說。然而,過了一段時間,Patel想要讓WAF自動攔截攻擊封包。「關鍵是,我們已透過WAF分析/學習了大量流經網站的封包,因此WAF能辨識不正常的情況,並在不正常情況發生時就立即攔阻,而非在事後才作補救的工作。」他說。

譬如,WAF現在可以攔阻我們的競爭對手從我們的網站大量擷取產品的資訊,這些資訊包含數以百萬計的SKU資訊以及價格資料。「假如有人每週或每月不停的探詢我們的資料,這代表我們將損失大量的競爭產品資訊。」Patel說。(譯注:SKU為Stock Keeping Unit的簡稱,是供倉庫儲存記錄用的零件編號)

Jarden公司的Nelson選用Check Point公司產品的部分原因,在於該產品具備企業等級的主控台(console),該主控台對所有Jarden公司的防火牆提供集中控管的服務。他特別喜歡的一項功能,就是他能夠將不同的防火牆,依據不同的分類置於不同的container(容器)中,然後再於各個container中下達不同的安全政策。

此外,一位任職於營養補充品生產公司的安全工程師表示,採用Barracuda WAF的最大優點是它的延展擴充性。這家公司位於全球的使用者透過web介面收發e-mail。安裝WAF的最主要原是需要保護此web介面的安全。此公司亦利用WAF防禦針對應用層的攻擊。

這位安全工程師希望能為處於各地的使用者提供單一URL以存取e-mail。他也希望能在系統不中斷的情形之下擴充系統。他每新增一個新的WAF,都不需要為WAF另新增一個IP位址,足見此WAF具備高度的透通性。「假如現有WAF不勝負載,我們所需作的是再拿另一個WAF,將其安裝至機架中,並與現有的WAF作好叢集(cluster)設定,如此WAF的承載度便提升兩倍。」他說。

各WAF的功能差異頗大,且大部分的WAF都各有其擅長解決特定問題的領域。瞭解WAF產品市場的其中一個方法,是將WAF產品區隔為三個基本的種類,如下