建立毫無意義的防火墻組

一個防火墻管理員可能在超過半數(shù)的規(guī)則中都包含有一個特定的網絡對象。我們假定這個對象名字叫"Joe_Montana".每次當這個對象需要訪問網絡時，管理員就為這個對象添加一個IP地址，而這個地址是很多許可規(guī)則里列出的被許可的地址。這看上去沒什么問題，因為沒有任何一個規(guī)則里包含了ANY范圍，但實際上這是個大漏洞。它使得防火墻規(guī)則變得毫無意義，而徹底梳理防火墻規(guī)則庫來解決這個問題，可能需要耗時幾個月。

從不升級防火墻軟件

很多公司的防火墻設備所采用的軟件都是過時的。在問到為什么會出現(xiàn)這種情況時，大部分企業(yè)的防火墻管理員都會說是為了保證防火墻的穩(wěn)定，或者不允許防火墻因為升級而出現(xiàn)暫時關閉現(xiàn)象。而實際上，防火墻產品廠商決定升級防火墻軟件都是有一定原因的。即使企業(yè)不一定必須更新到最新版的軟件，但如果還是運行著五六年前的舊版軟件，或者是距離最新版本老15-20個版本舊軟件，那么就應該考慮立刻開始升級了。

使用錯誤的技術

之前，有個網絡安全管理員與監(jiān)管人員發(fā)生了爭執(zhí)，因為該管理員在公司的安全web服務器前端放置了一個防火墻，作為第二層防護屏障。按照他的想法，這就構成了一個雙重驗證機制：一個用戶密碼加一個防火墻。可以說這個管理員在創(chuàng)新性上可以得滿分，但是防火墻本身并不算是一個雙重驗證的解決方案。雙重驗證需要你的用戶擁有兩件可驗證對象，即所知的和所擁有的兩個對象。比如知道密碼，并擁有令牌。

偶然停電

曾經發(fā)生過這樣一件事，有個防火墻管理員為某個項目而在防火墻服務器上進行數(shù)據收集。這個管理員在調整網線的時候不小心碰了幾下鼠標，這時候鼠標指針正好在"開始"的位置，然后，鬼使神差的鼠標指針又指到了屏幕中央彈出來的關機確認窗口，并且點到了中間的關機按鈕。于是這個財務公司的防火墻就在這種情況下突然關閉了。

不良的文檔

大家肯定經常聽說防火墻管理員抱怨無法理解全部的防火墻規(guī)則。如果管理員在建立防火墻規(guī)則時圖省事，沒有進行詳細的文檔說明，看似節(jié)省下來的時間和精力，以后必然會花費到去理解這些規(guī)則上。因此肯定有人聽過這樣的話"恐怕我們要重新修改防火墻設置了，以前的管理員設置的那些防火墻規(guī)則沒有注釋，所以我們很難搞清楚它們的作用。"

過度使用丟棄Drop規(guī)則

一般來說，如果時間比較緊迫，我們都會建立一些屬于過度訪問的規(guī)則，然后再在這些規(guī)則的基礎上，建立丟棄規(guī)則，將不允許的數(shù)據連接丟棄。之所以這樣，是因為我們很多管理員都不愿意去設置一個精確的防火墻規(guī)則。比如："allow All DMZ devices to All Internal devices ACCEPT",然后在這個規(guī)則之上再建立一個"All DMZ devices to Secure Network device DROP".這兩個規(guī)則看上去沒什么問題，但是實際上卻包含了很多的后患，原因是我們沒有在第一條規(guī)則中表現(xiàn)出建立該規(guī)則的目的。

如果長此以往的話，我們的防火墻規(guī)則庫就會出現(xiàn)很多"成對兒"的規(guī)則，而在記錄規(guī)則日志或修改規(guī)則時，也很容易出現(xiàn)更多的風險，或者會導致必要的數(shù)據被攔截。最終，我們就不得不重新改寫整個防火墻規(guī)則庫中的全部規(guī)則。

使用路由作為安全策略

大家平時會遇到過很多類似的情況，當防火墻規(guī)則庫需要修改時，路由規(guī)則也要跟著修改。當然，如果涉及到新的網絡，那么這種現(xiàn)象是可以理解的。一般導致這種情況的錯誤有兩種。

首先，防火墻沒有默認路由。所有路由都是手工輸入防火墻的，同時如果防火墻沒有策略，會使用最小子網掩碼，防止數(shù)據流向無關設備。這聽起來很不錯，但卻是完全沒必要的，因為如果從現(xiàn)代的防火墻上刪除策略，防火墻會恢復為DENY ANY.這個設計會因此變得難以管理，最終使整個IT團隊都不敢去修改防火墻設置了。如果每個改變都需要工程師檢查路由設置，那么會導致耗費過多的時間，影響企業(yè)正常業(yè)務的運轉，這對企業(yè)來說很不值得。

第二種情況最常出現(xiàn)在Cisco設備中，管理員通過訪問控制列表管理兩個源或目標均為ANY的接口。實際上這個規(guī)則里的ANY并不是所有地址，而是指端口后的所有地址。只有在知道路由表與防火墻關聯(lián)的前提下，管理員才可能理解防火墻規(guī)則庫中的規(guī)則，這對于管理員來說太復雜了。

在規(guī)則中使用DNS對象

作為一個選項，很多防火墻都會嵌入一個源地址或目的地址作為DNS對象，如google.com.這么做看似錯，因為google.com 使用了相當多的IP地址，就算google.com 改變了IP地址，防火墻也會放行google.com的數(shù)據流。但是這種做法會導致相當嚴重的安全隱患，相信任何企業(yè)都無法接受。

首先，這么做會使你的防火墻更容易遭受DoS攻擊。如果連google.com都無法解析會怎么樣呢？

其次，你的防火墻會浪費CPU,內存以及網絡IO來判斷每一個數(shù)據包是否屬于google.com這個域名。

第三，如果你設置的DNS被黑客攻擊，包含有惡意地址的命令和控制數(shù)據中帶有google.com的地址，會怎么樣呢？在這種情況下，你的防火墻會允許僵尸網絡發(fā)送的命令和控制數(shù)據，并作為google.com記錄在防火墻日志中。

危急時刻所作的改動

可以想象一下，如果服務器上的RAID陣列壞了，一塊硬盤報廢。你換了一塊硬盤，在重建RAID的過程中，服務器無法提供正常的服務，但是你沒有意識到這個問題。此時，你的客戶已經被拒絕服務長達40小時了，每一分鐘你都在遭受損失。而且不斷有客戶放棄你的服務，卻選擇了競爭對手。

當情況陷入危急時，我們往往會開始改變各種設備的配置：交換機，路由器，負載平衡服務器和防火墻，任何你懷疑導致服務不正常的環(huán)節(jié)都被調整了一翻。可能又過了很長一段時間后，團隊中終于有人發(fā)現(xiàn)了問題所在。因此你又需要把所有一改過的配置從新恢復回來，但問題是沒有人會記得之前的配置，原因是之前的情況太過緊張，導致沒人去做修改配置的文檔。最終的結果是，你不得不再花上三天時間將各個設備的配置調試到以前的狀態(tài)。

相信所有的企業(yè)都不希望以上這種情況發(fā)生。但是事實證明這種情況卻時有發(fā)生。即使那些運轉最好的企業(yè)也會出現(xiàn)類似問題，尤其是在防火墻配置上。不過通過自動化恢復機制，這些依靠經驗很難實現(xiàn)的工作變得越來越容易實現(xiàn)了。而要想知道你的企業(yè)是否具有這種針對網絡安全設置或其它安全設置的自動恢復功能，就要看企業(yè)是否對投資回報率進行過明確且詳細的量化設計。畢竟，如果對于安全投入沒有明確的投資回報量化統(tǒng)計，誰能相信這個企業(yè)在安全性上是值得信賴的呢？

防火墻安全管理是保證網絡正常安全運行的關鍵關卡，所以每一個管理員都應該拿出負責認真的態(tài)度對待，否則也許一個小小的失誤就會釀成大錯。