防火墙规则审查清单与清理步骤

简短回答：每条防火墙规则至少每年审查一次，面向互联网和远程访问的规则每季度审查一次，有变更的规则在变更当时就审查。逐条检查：有没有负责人、理由，来源、目的和服务是否足够窄，有没有开日志，最近有没有被用到。不要一步删除：先停用，观察，再删除，并保留可以还原的配置备份。

本文写给负责防火墙的 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 指出给规则写注释“花不了多少力气”，并有助于日后审计的人。解决：创建时强制填写负责人、理由和工单号。
临时规则变成永久规则。解决：每条临时规则都有到期日，每月检查时查看已过期的。
忽略出站规则。解决：既审进来的，也审出去的。
只在危机时才审。解决：把日期放进日历，像补丁窗口一样对待。