防火墙策略基础 – 如何验证隐身规则

更新于 2017 年 1 月

防火墙隐身规则是位于策略靠前位置的显式规则，用于拒绝除管理设备所必需之外的一切对防火墙的访问。其定义应如下：

源 = ANY

目标 = [self]

服务 / 应用 = ANY

动作 = DROP

日志记录 = 启用

这一点并不完全适用于某些防火墙，例如 Juniper Netscreen，它通过接口级设置而非防火墙策略来定义管理访问。不过，即便在这些情况下，审计人员出于惯例仍可能要求配置隐身规则。

为什么要定义隐身规则

隐身规则可确保策略中后续定义的规则不会无意中放行对防火墙的访问。例如，防火墙可能在 Web-DMZ 区域中有一个接口。Web 开发团队可能提出申请，要求对 Web-DMZ 中的所有系统拥有 SSH 访问权限。若不深究该申请，看起来似乎合理：如果他们是 Web-DMZ 中所定义系统的唯一负责人，那么他们可能确实需要对所有这些服务器的 SSH 访问权限。然而，如果没有正确定义隐身规则，SSH 访问不仅会被放行至 Web-DMZ 中的服务器，也会被放行至防火墙本身。这显然并不恰当，但防火墙管理员可能多年都未能察觉。

为避免这种简单却重大的失误，应在防火墙策略中定义隐身规则。

如何验证是否存在隐身规则

该过程非常简单。审查每一条策略，确认在必要的管理规则之后、策略靠前的位置存在一条规则，拒绝所有发往防火墙的流量（Any、Self、Any、Drop、Log）。

FireMon 能提供哪些帮助

FireMon 提供预定义控制项，用于验证每条策略中隐身规则是否存在。该控制项是预定义评估的一部分，也可添加到任何用户自定义评估中。

另一个强大的选择是使用 SiCL 自行搜索规则。在这种情况下，搜索相当简单。您需要验证在策略靠前的位置存在一条显式规则，丢弃所有发往防火墙的流量。借助预定义变量 self，您可以创建一条适用于所有设备的 SiCL 查询。此时，该搜索的 SiCL 语法为：

rule{ POSITION < 5 and source.any=true and destination is superset of self and SERVICE.any=true and action=’DROP’}

在上面的示例中，我指定该规则必须是策略中的前 4 条规则之一，并且目标必须完全涵盖防火墙的地址空间（destination is superset of self）。超集包括相等及更大的范围。Self 即防火墙对象本身。