“先临时放通，回头再改” ：防火墙上那些没人敢删的策略

前阵子帮一个朋友看他们单位的防火墙——接手还不到半年，他想摸摸底。登进去，策略列表往下翻，翻了快两分钟才翻到底。

3147 条。

他苦笑了一下，说：“这里面有多少还在用的，我真不知道。但我也不敢删。”

我说这事我太熟了。几乎每个干过几年的网工，电脑里都有一张防火墙截图——不是因为策略配得多漂亮，是因为条数多得吓人。

今天就聊聊这个每个网工都躲不开、但很少有人系统讲的话题：那些加上去就再也没删过的策略，到底该怎么办。

先讲个场景，你看看是不是熟悉。

某天下午 4 点，业务同事微信轰炸过来：

你问：源 IP 是哪些？目的端口确定吗？是只放演示那几台，还是整个办公网段都要？

对方回：“先全部放通吧，演示完我们再梳理具体需要哪些。领导现在就在等结果，你快点！”

你咬咬牙，在防火墙上加了一条：

点保存。业务通了。领导不催了。你松了口气。

三年过去了，这条策略还在。

那个同事换岗了。那个系统早就下线了。但你不敢删——因为你不知道现在还有谁在用这条策略背后的通路。

这事看着像态度问题（“你们网工怎么不定期清理”），其实是结构性问题。三个原因：

第一，加策略的人和用策略的人，不是同一个人。加策略的是网工，用策略的是业务。业务同事不会主动来告诉你“这条策略我们不用了”——因为他们根本不知道这条策略存在。他们只知道“系统能访问”或“系统访问不了”。

第二，变更有审批，删除没流程。公司对“加策略”管得特别严——走 OA、填工单、安全审核、变更窗口。但“删策略”这件事从来没有流程。你想主动清理，没人给你签字；万一删错了导致业务中断，锅全是你的。于是最理性的选择就是：不删。

第三，策略背后的“业务上下文”丢失了。备注里写“XX 系统临时放通”，三年后你根本不知道 XX 系统现在是不是还在跑、是不是改了名字、是不是迁移到了云上。没有上下文的策略，等于死策略，但你不敢当死策略处理。

这三个原因叠加，结果就是——每一条临时策略都在滚雪球。我见过运行了 8 年的防火墙，策略数超过 3000 条，真正还在被命中的不到 600 条。剩下 2400 多条，没人敢动。

你可能会想，策略多就多了，反正也没坏事。但废弃策略不是中性的，它是在持续产生风险：

风险一：攻击面扩大。每一条“any to any”的放通策略，都是一个潜在的横向移动通路。真有攻击者进来，他不需要再突破什么——你三年前为了演示留的那条口子，就是现成的高速公路。

风险二：策略冲突，排错指数级变难。策略多到一定程度，上下策略之间会互相覆盖。你新加的一条拒绝策略可能被上面一条宽松的允许策略直接盖掉，结果就是“我明明配了禁止，为什么还通？”——这种工单每周都有。

风险三：合规风险。等保 2.0、ISO27001、金融行业的 1104 检查，都明确要求“最小权限原则”和“策略定期复查”。审计一来，你指着 3000 条策略说“我也不知道哪些该删”，直接扣分。

风险四：性能衰减。虽然现代防火墙的硬件够强，但策略匹配是从上到下顺序扫描的（有些设备做了优化，但原理没变）。3000 条策略和 600 条策略，CPU 占用、新建连接数、吞吐量都不是一个量级。

风险五：也是最隐蔽的——“策略疲劳”。当你的策略表有 3000 条，你就不再认真审新策略了。因为反正也看不过来。久而久之，防火墙从“安全设备”退化成“流量放行器”。

不绕弯子，直接讲办法。按“不用动审批流程”到“需要管理层支持”由浅到深：

办法一：从今天开始，所有新加的临时策略必须带“过期时间”

不用任何工具，不用申请预算，今天就能做。

每一条新加的策略，备注格式强制统一：

然后在你的个人日历上建一个重复提醒，每月 1 号打开防火墙，看一遍到期清单，挨个联系对应申请人确认：“这条策略还要不要？不要我就删了。”

这个方法最大的价值不是“真能删掉多少”，而是从源头上止血——不让新的“永久临时策略”再诞生。老策略慢慢处理，新策略一条都不多留。

现实挑战：你会发现 70% 的申请人会说“再留一段时间吧我也不确定”。这时候你有两个选择：要么再延 3 个月（并记录），要么把责任转移出去——让申请人书面确认“同意保留”，锅归他。

办法二：用命中率数据反向推废弃策略

现在主流的防火墙都支持策略命中计数（Hit Count）和最后命中时间（Last Hit）。打开这两个字段，然后：

连续 90 天命中次数 = 0 的策略，列入“疑似废弃清单”。

但注意，不要直接删。因为有些业务是季度性的、年度性的（比如年报系统、HR 的年终调薪通道、财务审计时才用的接口），90 天内没命中不代表以后不用。

正确做法是分两步：

第一步，降权不删除。把这些策略从“允许”改成“允许+告警”，或者挪到策略列表的最下面（如果你的设备支持排序）。观察 30-60 天。

第二步，如果期间触发了告警或者有人投诉“XX 不能访问了”，说明策略还在用，恢复并记录业务上下文；如果 60 天还是没动静，再走变更流程删除。

这个方法的好处是：所有删除都有数据支撑，审计问起来你能拿出“180 天零命中 + 60 天观察期无业务反馈”的证据链，责任边界清晰。

办法三：建一张“策略台账”，把隐性知识显性化

这是三条办法里最累的，但也是唯一能长期根治的。

拿一张表（Excel 就行，不用上专业工具），把每一条策略对应的信息补齐：

关键是“业务负责人”这一列。因为业务会换人，最初那个张三可能早就离职了。你每半年要主动跟一次人事或业务线负责人，更新这一列——没有责任人的策略，就是最危险的策略。

这张表一开始会很痛苦（3000 条策略要补齐，光访谈业务就得一两个月），但它一旦建起来，你就从“背锅的网工”变成“管策略的网工”——这是本质差别。

细节一：删策略前，先禁用或转告警观察 30 天以上，不要直接删。很多设备支持“策略状态：禁用”而不是“删除”。禁用相当于软删除，万一出事直接启用，比你从审计日志里翻 commit 记录快得多。配合办法二里 60 天的观察期，禁用是最稳的中间态。

细节二：别在周五下午做策略清理。所有做过运维的人都知道这条铁律。真要清理，周二周三上午，留足响应时间。

细节三：“any to any” 永远不该出现在生产网，除非是互联网出口的默认拒绝兜底。看到这种策略直接列入最高优先级处理，哪怕是领导加的也要去确认。

细节四：如果公司有多台防火墙组成的策略链路（比如内外两道、核心+边界），策略要在哪一台上加是有讲究的——加错位置会导致同一条规则在多台设备上重复或互相覆盖。这件事没有标准答案，但原则是：离业务越近的那台，越应该放细粒度策略；越靠近边界的，越应该放粗粒度策略。

细节五：所有的策略评审会议，都要让业务方参加。不要你一个网工关起门来审策略——审完了没人认账。拉着业务一起审，哪怕每次只审 20 条，审完有人签字，责任分摊了，你也轻松。

防火墙策略治理这事，本质上不是技术问题，是“责任边界”问题。

网工背着所有策略的锅，但大部分策略的真实使用者是业务。只要责任边界不清，网工就永远在“不敢删”和“该删”之间焦虑。

上面三条办法，核心逻辑其实都一样——用流程、数据、台账，把本来模糊的责任边界显性化。显性化之后，该谁的锅就是谁的，你才有可能真正清理。

这事做好了，防火墙策略数能从 3000 降到 800，排错时间能缩一半，审计一次过——但更重要的是，你终于不用每次有人问“这条策略能不能删”的时候，心里打鼓了。

· · ·

评论区聊聊：你维护过的防火墙，策略数最多的时候有多少条？真正还在用的大概占多少？ 有见过最离谱的“临时策略”也欢迎吐槽。

如果这篇对你有用，转给你们单位那个“加策略最多、删策略最少”的兄弟看看，他知道该干嘛。