我們每個人在職業生涯中都犯過錯誤。這里所說的錯誤，是那種會使你馬上丟掉工作的錯誤。舉例來說，曾經有過一個學校的網絡管理員犯過這樣的錯誤，直接導致了校園里的所有路由器同時重啟，而不是一個接一個。這個管理員本來是寫了個腳本，對路由器進行安全升級，計劃中是打算一個一個的升級并重啟的，但是結果卻是同時重啟了。他經過重新檢查腳本，才發現錯誤出在沒有等待路由器重啟，就直接命令下一個路由器進行升級。

像出現這種情況幾乎肯定要被學校開除了，但很幸運，學校并沒有這樣做。不過，對于任何涉及到一場大災難的人來說，都應該從災難中學到些什么。我們都學過一些危機管理的知識，在網絡重新恢復后，我們有必要花上幾個小時來學習該如何檢查網絡是否工作正常。

所幸是大多數時候，大家所面對的錯誤并不是那么嚴峻。而不幸的是我們犯的錯誤不見得馬上會被發現，這意味著這個錯誤可能潛伏數周，數月，甚至數年時間，直到有一天造成嚴重的后果，或者監管部門發現問題后把我們叫去盤問。在網絡安全陣地的前沿，防火墻管理是一個很重要的區域，任何簡單的錯誤規則或配置，都可能給我們帶來無盡的后患。下面就讓我們大家一起來了解一些最常見的錯誤：

建立毫無意義的防火墻組

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

從不升級防火墻軟件

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

使用錯誤的技術

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

偶然停電

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

不良的文檔

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

過度使用丟棄Drop規則

一般來說，如果時間比較緊迫，我們都會建立一些屬于過度訪問的規則，然后再在這些規則的基礎上，建立丟棄規則，將不允許的數據連接丟棄。之所以這樣，是因為我們很多管理員都不愿意去設置一個精確的防火墻規則。比如：“allow All DMZ devices to All Internal devices ACCEPT”，然后在這個規則之上再建立一個“All DMZ devices to Secure Network device DROP”。這兩個規則看上去沒什么問題，但是實際上卻包含了很多的后患，原因是我們沒有在第一條規則中表現出建立該規則的目的。如果長此以往的話，我們的防火墻規則庫就會出現很多“成對兒”的規則，而在記錄規則日志或修改規則時，也很容易出現更多的風險，或者會導致必要的數據被攔截。最終，我們就不得不重新改寫整個防火墻規則庫中的全部規則。

使用路由作為安全策略

大家平時會遇到過很多類似的情況，當防火墻規則庫需要修改時，路由規則也要跟著修改。當然，如果涉及到新的網絡，那么這種現象是可以理解的。一般導致這種情況的錯誤有兩種。首先，防火墻沒有默認路由。所有路由都是手工輸入防火墻的，同時如果防火墻沒有策略，會使用最小子網掩碼，防止數據流向無關設備。這聽起來很不錯，但卻是完全沒必要的，因為如果從現代的防火墻上刪除策略，防火墻會恢復為DENY ANY。這個設計會因此變得難以管理，最終使整個IT團隊都不敢去修改防火墻設置了。如果每個改變都需要工程師檢查路由設置，那么會導致耗費過多的時間，影響企業正常業務的運轉，這對企業來說很不值得。

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

在規則中使用DNS對象

作為一個選項，很多防火墻都會嵌入一個源地址或目的地址作為DNS對象，如www.google.com。這么做看似錯，因為google.com 使用了相當多的IP地址，就算google.com 改變了IP地址，防火墻也會放行google.com的數據流。但是這種做法會導致相當嚴重的安全隱患，相信任何企業都無法接受。首先，這么做會使你的防火墻更容易遭受DoS攻擊。如果連google.com都無法解析會怎么樣呢?其次，你的防火墻會浪費CPU，內存以及網絡IO來判斷每一個數據包是否屬于google.com這個域名。第三，如果你設置的DNS被黑客攻擊，包含有惡意地址的命令和控制數據中帶有google.com的地址，會怎么樣呢?在這種情況下，你的防火墻會允許僵尸網絡發送的命令和控制數據，并作為google.com記錄在防火墻日志中。

危急時刻所作的改動

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

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

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