防火牆規則審查清單與清理步驟

簡短回答：每條防火牆規則至少每年審查一次，面向互聯網和遙距訪問的規則每季審查一次，有變更的規則在變更當時就審查。逐條檢查：有沒有負責人、理由，來源、目的和服務是否足夠窄，有沒有開日誌，最近有沒有被用到。不要一步刪除：先停用，觀察，再刪除，並保留可以還原的配置備份。

本文寫給負責防火牆的 IT 經理和工程師，無論這部防火牆是你自己建的，還是前任留下的。看完後，你會得到一份審查週期、一份逐條檢查清單、一套帶回退的清理步驟，以及一頁可以反覆使用的記錄表。

防火牆規則應該多久審查一次？

NIST SP 800-41 第 1 版（Revision 1，2009 年 9 月）《Guidelines on Firewalls and Firewall Policy》指出，防火牆規則集會隨時間越來越複雜，政策應按固定間隔審查，不要只在審計或出事時才看。它還建議審查自上次以來的所有變更，包括誰改的、在什麼情況下改的，並且偶爾由常規審查團隊以外的人來審計規則集。它沒有規定具體日數（2026 年 10 月 28 日核對）。

所以下面的週期是我們建議的起點，不是 NIST 的數字。請按你的風險和變更頻率調整。

每次變更時：新規則上線前由第二個人覆核。規則要有註解、負責人和工單編號。
每月（輕量）：看上個月新增的規則、即將到期的臨時規則，以及日誌裡命中或拒絕量突然變大的規則。
每季：審查所有允許來自互聯網、合作夥伴，以及 VPN 或遙距訪問用戶組的規則。
每年：審查並測試整個規則集。條件許可時，請常規團隊以外的人來審。
出現事件之後：發生保安事故、併購或搬遷、重大應用程式變更，或更換防火牆之後，再審一次。

開始之前

備份配置，防火牆提供幾種格式就備份幾種。NIST 建議定期備份；如果設備同時有二進制格式和可讀格式，兩種都保存。
匯出規則及命中計數或日誌查詢結果，週期至少涵蓋一個完整業務週期（月底、季底的工作也算）。
取得最新的網絡圖和地址清單。如果沒有，參考網絡文檔模板。
找出規則負責人。沒有已知負責人的規則，最先要質疑。
檢查固件版本和修補狀態。升級本身見網絡固件升級檢查清單。
為審查和清理開一張變更記錄，寫明維護時段和審批人。

逐條審查清單

對每條規則回答下面的問題。任何「否」或「不知道」都是一個發現項。

註解裡有明確的負責人和業務理由嗎？
有工單或變更編號，能看出誰在何時批准的嗎？
來源盡量窄了嗎（具體地址、群組或子網），而不是「任意」？
目的盡量窄了嗎，而不是「任意」？
服務是明確的端口或協定清單，而不是「任意」嗎？
方向對嗎？規則是用於入站、出站還是內部流量，是否清楚？
對到達敏感系統的允許規則，以及邊界上的拒絕規則，日誌開了嗎？
審查週期內它命中過流量嗎？（命中計數或日誌查詢可以看到。計數器在重啟、故障切換或策略重新安裝後常常會歸零，把「零命中」當作未使用之前，先確認計數器已運行多久。這是通行做法，不是 NIST 的內容。）
如果是臨時規則，有到期日嗎？到期日還沒過嗎？
它是否被上方規則遮蔽或重複，導致永遠匹配不到？
次序合理嗎？許多防火牆由上到下逐條匹配，直到命中為止，所以靠前的寬泛規則會蓋住下面的一切（有些產品會先評估拒絕規則，請核對你的產品）。
它是否把管理介面（防火牆本身、交換器、服務器主控台、遙距桌面或 SSH）暴露到互聯網？
有加密協定可用時，它是否還允許未加密協定（例如 telnet 或 FTP）？
最後一條規則是拒絕嗎，使得未明確允許的流量被阻止？NIST 稱之為「預設拒絕（deny by default）」，並指出它比「允許所有未明確禁止的流量」更安全。

還要審查規則周邊的設定：誰能登入防火牆並修改規則，管理員帳戶是否一人一個，管理介面是否限制在受信任的網絡，時間是否同步使各系統的日誌能對上。NIST 建議限制誰、從哪裡可以修改規則集。

用一頁紙的記錄讓審查有據可查：

防火牆：______  型號/固件：______  審查日期：______
審查人：______  覆核人：______  變更編號：______
配置備份儲存位置：______  已審查規則：___ / ___
每條規則：編號 | 負責人 | 理由 | 來源 | 目的 | 服務
 | 日誌 是/否 | 週期內命中 | 臨時？到期日 | 發現
每條規則的決定：保留 / 收窄 / 停用 / 刪除
停用日期：______  計劃刪除日期：______
接受的例外（規則、風險、批准人、覆核日期）：______
下次審查日期：______

每個發現項怎樣處理

每條規則選一個結果。

保留：有負責人、有理由、範圍窄、近期有命中。記錄審查日期。
收窄：能用但比需要的更寬。把「任意」換成真實的地址或服務，測試，然後去掉寬泛的版本。
先停用再刪除：沒有負責人、整個業務週期內沒命中、已過期或被遮蔽。先停用，暫不刪除。
立即刪除：僅限完全重複的規則，或已停用並觀察滿保留期的規則。
升級處理：規則暴露管理介面、使用未加密協定，或允許「任意到任意」。當作風險，指定負責人和期限，而不是當作日常整理。

清理步驟

儲存一份最新的配置備份，並記下位置。
與規則負責人和業務方商定變更清單和維護時段。
先收窄寬泛的規則，一次一條，每條改完後測試受影響的應用程式。
停用未使用和已過期的規則。在註解裡寫上日期和工單編號。
在你選定的保留期內觀察日誌。保留期要長到包含你最長的一次例行工作；起點可定為至少一個完整的月底，通常是 30 至 35 日。留意新出現的拒絕和用戶反映。
保留期結束且無人投訴後，刪除已停用的規則，並記錄刪除。
更新網絡圖、規則註解和審查記錄。
安排下一次審查，把日期放進某個人的日曆。

回退手段是第 1 步的配置備份，以及停用的規則可以在幾秒內重新啟用。保留期結束之前，兩者都要留著。

常見錯誤

觀察窗口很短，就刪掉零命中的規則。月底、季度和年度工作之後會失敗。解決：用完整業務週期，並且先停用後刪除。
只審規則，不審誰能修改規則。解決：每次審查都包括管理員帳戶、訪問來源和變更日誌。
沒有註解。沒人知道規則為什麼存在，也就沒人敢刪。NIST 指出給規則寫註解「花不了多少力氣」，並有助於日後審計的人。解決：建立時強制填寫負責人、理由和工單編號。
臨時規則變成永久規則。解決：每條臨時規則都有到期日，每月檢查時查看已過期的。
忽略出站規則。解決：既審進來的，也審出去的。
只在危機時才審。解決：把日期放進日曆，像修補時段一樣對待。