企業網路的終極門神—應用層防火牆

新的安全缺口- 應用層攻擊
市場調查與研究機構Gartner估計，大約有75%的攻擊手法是發生在應用層程式(application layer)。駭客攻擊應用層漏洞不僅因它比網路邊界防護設備(像是stateful防火牆、IDS)還要容易，攻破應用層能讓他們竊取更有價值的資料，像是存放在應用層軟體中的客戶資料、信用卡資料。如果損失這些資料，將會嚴重損害企業名聲，更可能導致企業失去商機。
應用層程式的攻擊通常能讓入侵者獲得系統控制權，所以更加危險。
目前多數企業所採用stateful 防火牆，已經無法抵禦這類型的攻擊，而讓攻擊穿過。大多數的stateful 防火牆主要是依據封包的第四層資訊(Transport層)來過濾封包，甚至有些為了效率而僅檢視更下層的資訊。這些防火牆僅檢視起始連線封包的第七層資訊，而後接下來同一連線的封包都利用state table紀錄的第四層資訊(或更下層)來檢驗。
雖然這樣可以讓檢驗網路封包更有效率，但是對於整個連線中的其他第七層資訊，卻無法一一檢驗。在起始封包過後的第七層連線行為，也無法有效掌握。應用層的攻擊便是利用這種缺陷，攻擊行為可藏在正常通訊協定中，偽裝成正常應用程式流量，而不被邊界防護設備偵測到。舉例來說，如果我們為了安全，只想允許對外HTTP流量，也就是對外 Port 80的封包都允許，但是某個後門仍然可以將對外祕密通訊連線改成port 80，來突破我們的設定。
另外應用程式亦可能因本身程式碼中邏輯的錯誤而被駭客找出缺失，進行攻擊。

如何建構新的防禦措施
企業中的網路安全必須考量機密性、完整性、以及可用性。如果沒有針對應用層流量來進行保護，就無法達到安全。藉由配置應用層防火牆，管理者得以深入檢視、分析整個連線封包內容，而不像以前，僅能檢視個別封包資訊。應用層防火牆(ALF , Application-Layer Firewall)已經可以抓到以前stateful 防火牆抓不到的惡意流量了，並且仍然具備stateful 防火牆的功能，來過濾整個網路流量。 另外，應用層防火牆也可以拿來監控及捕捉攻擊來源。這個任務原本應該是IDS(Intrusion Detection System)的責任，但stateful防火牆卻無法捕捉到這類型的惡意應用層流量，所以這個重責大任也可由ALF來執行。
目前已經有許多網路安全產品內含深層封包檢視技術(Deep-packet inspection)，像是IDS、IPS、以及某些防毒軟體。IDS產品採被動監控，當有惡意行為發生時便會告警，而防毒軟體在執行惡意程式之前會提出告警，IPS則是IDS的進階，會阻擋惡意行為經過。IPS大多安裝在網路邊界上，作為進階的安全設備。但是卻無法像防火牆一樣，將網路分隔成不同區域。
ALF具備IDS特徵資料庫以及異常通訊協定(protocol anomaly detection)偵測資料庫，並具有IPS應用層阻擋能力，這些功能都整合在一個專門處理網路流量的引擎，並且具有分隔網路(Network segmentation)的功能。目前許多廠商朝著整合IPS、IDS、防火牆、以及防毒功能到一部機器中，這樣一來也方便系統管理者進行管理。

規劃防禦架構
事實上，如何規劃及設計企業中的網路安全架構，乃是要取決所欲保護的企業資源的價值。譬如說，拿一部stateful防火牆的處理速度以及能力來保護一個純文件網站就綽綽有餘了，因為這類型的網站也沒有複雜的使用者互動。但是若是要保護一個電子商務網站，也許還需要其他更好的安全產品。
另外，還有一個困難處是，除了維護網路安全之外，你必須考量到使用者的需求。舉例來說，把所有內送郵件的附件檔案都自動移除也許是避免電子郵件病毒傳播的最好辦法，但是，在企業中實行起來卻很不合理。此外，每個部門的資訊機密性都不太一樣，所以應該適當的考量安全、預算、效能，來訂立出一個分層防禦措施(Layered defense)。
使用防火牆來部署一個有效的防禦架構必須獨立且界定清楚，如圖一，使用了高效能stateful防火牆、以及ALF來部署一個能夠依據資源重要性來區隔網路的防禦架構。
由於Corporate網路與Web subnet有不同的安全需求，使用stateful防火牆，依據所保護的對象擬定防火牆政策來保護內部網路。另外使用防禦層級較為高但是效率比較低的ALF來保護Web subnet。而敏感資料區(sensitive data subnet)則再使用另一部stateful 的inline防火牆來保護，以確保只有web subnet能夠存取這個區域。如果說主機前面有過多的Inline防火牆，有可能造成瓶頸，並且管理上可能不太方便，但是這可以藉由一個整合的console來進行管理。像是Cisco的PIX， Check Point的FireWall-1都有這個能力。
在corporate subnet 中，依據資源重要性分成兩大部分，internal workstations 以及internal 伺服器，由internal router將兩區域區隔開來。並且再使用一部ALF來保護內部不受無線網路(Wireless zone)或來賓電腦區域的攻擊。通常，無線網路與來賓電腦區域都與辦公室網路互接，我們必須確定這塊區域的安全性，避免攻擊者在此區域發動針對應用層程式的攻擊。記住，就算是你的電腦已經處在防火牆的保護之後，你還是得按時更新、強化系統，以確保安全性。
最後，邊界路由器(border router)的封包過濾能力可以減少網路上不必要的攻擊封包(background noise)，但是也不能阻擋的太過嚴謹，不然無法從防火牆的記錄裡進行完整的分析。
某些情況下，如果某個防火牆的效能可能成為瓶頸，將系統放在這個防火牆之後可能不是那麼恰當。就像圖一例子，如果data server並沒有重要敏感的資料，可以將data server放置在跟Web server同一個區域。另外，如果想要增進網頁速度，可以將靜態網頁伺服器放置在stateful firewall之後，而將電子商務主機放置在ALF之後，並使用SSL加密通訊。

擬定過濾策略
只要能知道是哪個通訊協定(通訊埠)，其實靠packet-filter也可以阻擋應用層攻擊。但是，因為我們就是得讓這類的通訊協定通過，沒辦法阻擋整個通訊協定，才需要ALP。舉個例子，你想阻擋除了HTTP以外的通訊協定從Internet進入你的網路，但是在你的內部網路卻允許某些通訊協定像是NetBIOS 或SMTP通過，此時一個email帶檔的病毒就有可能趁虛而入。
另外，阻擋攻擊來源IP的方式也比阻擋特定通訊埠來的好。舉例來說，疾風病蟲(Blaster worm)藉由Remote Procedure Call (RPC)協定來攻擊，藉由檢驗RPC 通訊協定中的可疑行為，可以阻擋RPC攻擊，就算是沒有攻擊特徵碼或是已有某台未修補的系統被攻擊了。
另外一個例子是SIP協定(Session Initiation Protocol)，用來傳輸語音或是即時訊息通訊協定，利用HTTP或是SMTP來散發廣告信的手段可能很快就會運用在使用SIP的應用程式了，駭客們已經開始研究如何攻擊網路電話，所以如何在應用層過濾SIP通訊協定是將來很重要的課題，不然很快駭客們不需授權就可撥打電話，或者你將會接到未知的來電。
如果你使用SSL加密網路封包，則必須先解密，你的應用層檢驗機制才得以運作。這需要額外的運算能力，否則會造成網路延遲，所以除非必要不然就別使用SSL加密。

安全vs.效率
ALF會影響網路效能，但是你還是得了解，究竟會造成多大影響。這取決於網路設備與應用軟體彼此的運作。在增加硬體資源像是RAM或是硬體加速器之前，先調整系統設定，看看會不會增加系統效能。也許只是後端的資料庫系統沒有最佳化以致於回傳資料太慢，或者是SSL快取連線設定不佳。如果你在網路上增加了一條VPN連線，重新檢視現有設備或伺服器是否能夠處理這些多餘的負擔。另外像是一對多的多點傳播協定或是線上教學影像傳送都需要大量的頻寬，所以，最好適當地阻擋這些不必要的流量，避免造成ALF額外的負擔，而讓網路擁塞，並在非尖峰時段進行一些例行性的對外傳輸動作。
由於ALF在即時處理攻擊時會有許多負擔，像是寫記錄檔、發送告警、阻擋攻擊等，所以必須做良好的配置才能達到最佳效能。有所謂的Layer 7 的dispatcher可以將不同的通訊協定導至適當的伺服器，這樣一來就可以將ALF做適當的配置。另外使用Load balancing的方式來將流量分散，也是個方法，這個方法也比較具有擴充性，只不過架構會比較複雜，花費也較多。尤其是使用SSL時，系統負擔較為大時，這些方法都可以有效地解決效能問題。
如果環境需要較高的網路效能，確定你使用Windows 2000或是Linux kernels 2.1.9或是更新版本，這些作業系統支援RFC 1323 且使用OSPF (Open Shortest Path First)路由協定，而不是使用舊的RIP協定(Routing Information Protocol)。這樣網路會較有效率及穩定。但是如果沒有預算或是技術支援的話，就在進入介面卡上設定ACL避免路由器做沒效率的路由設定。

最終解決方案
由於越來越多的應用程式設計缺陷，促使駭客們找漏洞更加熟練。針對應用層程式的攻擊，將會是企業安全的最大漏洞。而隨著電子商務與網頁技術日益複雜，弱點也越來越多。要將這些弱點一一解決必須從應用軟體的撰寫開始，好好的檢視程式碼是否撰寫不當或設計缺陷。但是在這之前，應用軟體的保護仍然是企業中最脆弱的部份，靠著應用層防火牆的保護，我們得以保護這脆弱的一環。 Michael Cobb, CISSP-ISSAP, MCDBA，是Cobweb Applications顧問公司的創始人與總經理，也是IIS Security的作者之一。如果有任何建議請來信至 iseditor@asmag.com