网络中的恐怖故事

万圣节将至，这里有一个真实发生的防火墙策略恐怖故事。（为了营造气氛，您不妨想象用低沉沙哑的警示嗓音来讲述……或者，如果您喜欢，也可以想象是 Morgan Freeman 的声音。）

作为售前工程师，我有很多时间都在演示我们的产品，与安全工程师、合规人员、DevOps 经理和 CISO 讨论防火墙与网络安全。有时，一线人员讲述的经历令人难以置信，有时甚至相当吓人。下面这个来自某位客户的近期故事，会让每一位防火墙工程师夜不能寐。

场景：
这家公司最近采用了“零信任”理念，并投入了大量时间向这一目标靠近。过去一年里，他们专注于清理防火墙策略，只针对业务需求编写规则——不多不少——仅放行确实需要访问的特定 IP 和网络。正当进展顺利之际，他们的一位工程师有了一个令人毛骨悚然的发现：策略中间埋着一条可怕的“Any – Any – Any – Accept”规则。

他们手忙脚乱地排查这条规则为何存在。最终发现，是一位初级网络工程师为了让某个功能跑起来而创建了它。就这一条规则，绕开了他们在零信任目标上取得的全部进展，使网络暴露在巨大风险之中。

显然，这条规则必须删除。但它已经在策略中存在——且未被发现——至少 6 个月，其间必定放行着业务关键流量。事实上，日志流量表明这是一条极其繁忙的规则。当然，它放行的很可能不只是业务关键流量，也很可能同时放行了恶意流量。他们需要迅速解决这个问题。

起初，他们与网络团队开会，猜测其中可能包含哪些流量，集思广益列出熟悉网络的人认为可能正在使用该规则的关键应用和流量。但最终，他们决定只能咬牙硬上：删掉规则，看谁会叫。

于是，他们向各个业务部门的管理者通报了这一失误。他们颇为难堪地表示，将设立一条“热线”并安排话务人员值守，最终还不得不安排人员测试所有业务关键功能，以确保他们的产品、应用，以及开展工作和让客户/合作伙伴/供应商与其开展业务所需访问的一切，只会中断到重新配置完成为止。是的，业务确实中断了；是的，他们也做好了创建新规则来修复问题的准备，但这真是一场噩梦。

—

也许您并未遇到我上面描述的噩梦场景，但 FireMon 依然可以帮助您清理防火墙策略，让您的工作更轻松。以下是 FireMon 能够避免上述场景的几种方式。而且，如果您在策略中发现了可怕的过度宽松规则，请务必查看下面的第 6 点，那里有一个无痛的解决方案。

1) 合规告警与报告：
一旦有这样过度宽松的规则上线，我们会立即通知团队。您基本上可以自行“设定刻度”，决定规则宽松到什么程度算超标，例如“允许访问超过 60,000 个目标的规则”或“源地址大于 /16 网络的规则”。

2) 变更告警：
无论防火墙来自哪家厂商，这条规则都会出现在我们的归一化视图中，新增动作一目了然。因此它无法被“偷偷塞进来”。有些工程师和管理者会在每次发生变更时自动收到策略变更报告邮件——或者只接收一份涵盖所有变更的 30 天快照。

3) 如果部署了我们的自动化工具 FireMon Policy Planner，它会在这条高风险规则被推送之前就将其拦下。借助我们的“变更前分析”，该规则在推送到生产环境、放行任何一个数据包之前就会被识别并标记。这正是合规人员喜欢我们的原因：我们不仅根据需求推荐应创建的规则，还像沙箱环境一样，在自动推送规则之前先运行合规算法。有些客户仅仅为了这项功能就采购了 Policy Planner，并通过我们的 API 来调用它。

4) 同样借助变更告警，团队可以确切掌握谁在何时做了哪些变更。因此在本例中，由于责任人是一位初级工程师，管理者或主管本可以快速筛选/排序该用户在过去一周（或至少一个月）内所做的变更，从而看清这名用户做了哪类改动。这也是合规团队，甚至该用户本人，都可以查看的内容。

5) 从文档化的角度看，FireMon 可以成为“谁提出的申请、应用负责人是谁、这条规则上次审核是什么时候”等信息的唯一可信来源。因此，通过对带有规则文档的规则进行筛选和排序，这个问题本也能更快被发现。

6) 最好的留到最后。如果您确实存在过度宽松的规则——例如您的前任采用了与您不同、更“开放/灵活的规则创建风格”——我们有一种简便的方法来清理这些规则。借助流量分析，我们的工具会逐一查看流经该规则的每一个 IP 地址，把 any/any/any 拆解为具体的流量流向。您可以导出这些流量流向，并据此创建具体的规则。