上个月，我们使用了 Firewall Builder 为 iptables 策略创建了一组可重用的对象。在本月的专栏中，我将向您展示如何使用 Firewall Builder 创建两个这样的规则集：一个用于需要保护自身的主机堡垒机，另一个用于需要保护整个网络的防火墙。

让我们首先考虑主机堡垒机的情况。关于 Netfilter/iptables 以及一般数据包过滤的一个常见误解是，数据包检查严格来说是防火墙的功能。然而，深度防御原则表明，将所有安全鸡蛋放在一个篮子里是愚蠢的。尽管您必须使用经过仔细配置和监控的防火墙来保护所有连接到互联网的主机，但这些主机也应该能够保护自己，尤其是那些托管公共可访问服务（如 FTP 和 WWW）的主机堡垒机。

例如，如果您的公共 Web 服务器运行 Linux 2.4，那么您应该配置其本地 Netfilter 规则，以提供额外的防御级别，以防聪明的攻击者破坏或以其他方式绕过您的企业防火墙。如果您的服务器运行的是 pre-2.4 内核，则需要使用 ipchains 而不是 Netfilter/iptables。您还需要为 Firewall Builder 找到一个贡献的 ipchains 编译器插件来构建您的脚本。

创建任何防火墙规则库（即使是主机堡垒机）的第一步是为本地环回接口提供自由权限。环回用于本地进程和守护程序之间的某些事务。如果没有允许环回的规则，当您运行 iptables 脚本时，诸如名称服务缓存和 SSH 端口转发之类的事情会中断。

假设您有一台要强化的 Web 服务器，名为 Trillian。您已在管理工作站上安装了 Firewall Builder；请记住，我们避免在主机堡垒机上运行 X Window 系统以及基于 X 的应用程序。随后，您创建了一些对象来描述环境中的主机、网络和组，以及 Trillian 的防火墙对象，并完整地定义了环回接口。换句话说，您已经完成了我在上个月的专栏中描述的事情。

您需要两个用于 Trillian 环回接口的规则：一个允许所有离开环回接口的流量，另一个允许所有进入环回接口的流量。按照以下步骤创建两个这样的规则（图 1）

图 1. 环回接口规则

要创建图 1 中的第二个规则，请重复步骤 2 到 8。但是，在步骤 3 中，将 Trillian 的图标拖到新规则的“目标”字段中，而不是其源字段中。在步骤 5 中，将方向设置为“入站”。

您可能会问，这些规则是如何工作的？首先，您应该了解它们仅适用于环回接口。可以创建特定于任何接口的规则，这些规则在防火墙的全局策略之前进行解析。尽管我们分别使用 Trillian 作为两个环回规则的源和目标，但这并不意味着这些规则匹配具有特定 IP 地址（即 Trillian 的 IP 地址）的数据包。它们将匹配任何离开或进入环回接口的数据包。

这引出了我关于环回规则的最后一点。使用引用防火墙对象的两个规则而不是一个表示应接受任何源到任何目标的规则似乎违反直觉。但在我自己的测试中，单规则方法导致 Firewall Builder 为 FORWARD 链而不是 INPUT 和 OUTPUT 编写其环回规则，这适得其反地杀死了我的测试系统上的环回。更改为单独的环回入站和环回出站规则解决了问题。不用担心；这是我唯一一次看到 Firewall Builder 为其规则选择错误的链。即便如此，它也仅适用于单宿主主机，而不是多接口防火墙。

在满足主机堡垒机的环回需求后，将注意力转向其全局策略。这需要一些思考。您希望 Netfilter 提供有意义的保护量，但不能以牺牲所需的功能为代价。

我们的示例主机 Trillian 是一台 Web 服务器，因此我们希望允许其他主机通过 HTTP 和 HTTPS 访问它。我们还希望允许 Trillian 执行 DNS 查找以进行连贯的日志记录。此外，应允许某种管理连接。为此目的的首选工具是 SSH，因此我们还将允许入站 SSH 连接，但仅允许来自我们的内部网络。图 2 显示了为 Trillian 定义的此类策略。

图 2. 主机堡垒机的策略

我将不再详细描述我是如何创建每个规则的，但有几件事值得注意。首先，在窗口左侧的对象层次结构中，您可以看到我选择了层次结构级别中直接位于 Trillian 下方的全局“策略”对象，而不是任何特定于接口的策略对象。

我还不仅引用了 Trillian 对象，还引用了一个名为 Net_Internal 的网络对象，它是上个月专栏中的示例网络对象。此对象引用整个网络的 IP 地址，确切地说是 192.168.111.0。规则 02 使用单个 IP 地址（Trillian 的 IP 地址）作为其源 IP 地址，而规则 03 匹配源 IP 地址为整个范围（192.168.111.1-192.168.111.254）中的任何 IP 地址的数据包。

规则构建的另一个重要提示是获取 Firewall Builder 方便的预构建服务对象，单击窗口左侧的“标准”选项卡。但请注意；如果您执行任何除了将服务对象（例如 dns_tcp）拖到规则中以外的操作，窗口右侧的规则显示将被您选择的任何内容的信息替换。

换句话说，如果您正在处理策略，您可以单击“标准”选项卡，单击层次结构窗口中的 +（展开）和 -（折叠）图标，然后从中单击并拖动服务对象，所有这些都不会更改窗口右侧部分的模式。但是，如果您只是在“标准”层次结构中选择一个服务对象或类别（通过单击一次而不拖动），则该对象的属性将显示在右侧。您必须返回到“用户”选项卡并重新选择防火墙的全局策略才能再次显示您的规则。您不会丢失任何数据，但如果您没有预料到，这可能会很不方便并且令人不安。

一个更重要的观察是，在所有这些规则中，我都保持状态检测处于打开状态。我跳过了环回规则过程中的步骤 7。通常，我们希望内核保留网络事务的状态信息；这就是为什么我们可以用单个双向规则而不是两个单向规则来描述大多数事务的原因。例如，由于状态检测，每当事务匹配图 2 中的规则 02 时，该规则允许来自内部网络主机的入站 SSH 流量，Trillian 的内核不仅匹配那些入站 SSH 数据包，还匹配 Trillian 发回的 SSH 数据包。如果我关闭规则 02 的状态检测，我将需要另一个规则来允许来自 Trillian TCP 端口 22 的所有数据包以适应这些回复。

最后，除了最后一个规则外，所有规则都关闭了日志记录，如我们的环回规则过程的步骤 6 中所述。大多数人认为记录防火墙规则处理的每个数据包对于磁盘空间或 I/O 开销来说不是有用或合理的用途。就我个人而言，我倾向于关注丢弃的数据包，而放弃对允许规则的日志记录。因此，图 2 中的示例规则以底部的清理规则结束，该规则显式丢弃任何与其他规则或任何特定于接口的策略（例如环回策略）中的规则不匹配的数据包。

此规则的唯一目的是用于日志记录。Firewall Builder 自动将我的所有 iptables 链的默认策略设置为 DROP，但除非您告诉 Netfilter 这样做，否则这些默认丢弃的数据包不会被记录。

Netfilter 提供了一个实验性的丢弃表补丁，允许自动记录所有丢弃的数据包，但我建议您等待此代码稳定后再专门编译到内核中。如果您由于某种原因不能等待，您可以从 Firewall Builder 访问此功能，方法是选择您的防火墙对象，单击其“防火墙属性”选项卡，然后选中“记录所有丢弃的数据包”旁边的框。有关丢弃表补丁的更多信息，请参阅 www.netfilter.org/documentation/pomlist/pom-summary.html。

完成防火墙策略后，您需要将其转换为实际的 iptables 脚本。为此，首先确保在屏幕左侧的层次结构视图中选择了防火墙的对象、其全局策略或其接口策略之一——选择哪个都无关紧要。然后，下拉“规则”菜单并选择“编译”。图 3 显示了结果。

图 3. 编译策略

策略编译成功后，Firewall Builder 会写入一个文件，该文件的名称由您编译策略的防火墙对象的名称和后缀 .fw 组成。我们生成的示例脚本 trillian.fw 如清单 1 所示。清单 1 已根据空间要求进行了少量修改，并且删除了一些内务处理材料。本文中提到的所有实际规则都存在。

清单 1. trillian.fw

现在可以将此脚本手动复制到 Trillian 并按原样运行，或者可以手动转换为适合 Trillian 的 Linux 发行版的启动脚本，例如标准的 Red Hat 7.3 启动脚本。更简单的是，您可以使用 Firewall Builder 安装程序脚本（例如 fwb_install，可在 contrib 下的 sourceforge.net/project/showfiles.php?group_id=5314 中找到）自动复制并激活它。

特别是后者是安全地复制和激活防火墙脚本的一种优雅而简单的方法；fwb_install 使用 scp 将脚本复制到远程主机上的 /etc/firewall，然后使用 ssh 远程执行脚本。如果您已在 Firewall Builder 系统上的某个位置下载了 fwb_install，则可以配置 Firewall Builder 以从每个防火墙对象的“编译/安装”属性中使用它。

务必手动调整 fwb_install 以匹配您的系统设置，并设置 SSH 密钥供 fwb_install 使用。设置完成后，您需要做的就是在编译策略后安装它们，下拉“规则”菜单并选择“安装”。

尽管 fwb_install 非常方便，但您需要在目标系统上安装启动脚本，该脚本也在启动时和任何重启后执行防火墙脚本。否则，系统在每次启动或重启以及下次从 Firewall Builder 中执行“安装”之间是脆弱的。可以轻松复制和改编系统 /etc/init.d 目录中的现有脚本。

我在这篇专栏的大部分篇幅中都致力于主机堡垒机示例，但为多宿主（多接口）网络防火墙构建策略非常相似。创建环回策略，为其他接口创建反欺骗策略，创建全局策略，编译策略并安装它。

最大的区别在于防火墙与服务器不同，它具有多个网络接口。由于单接口系统在一个物理点接收除环回之外的所有数据包，因此它无法区分欺骗数据包和合法数据包；它必须按表面价值接受每个数据包的源 IP 地址。但是多宿主系统可以轻松区分真正来自本地网络的数据包和来自 Internet 但具有伪造的源 IP 地址（与本地或受信任网络匹配）的数据包。

例如，我们的示例内部网络的编号为 192.168.111.0（子网掩码 255.255.255.0）。如果我们在该网络与世界其他地方之间有一个名为 Slartibartfast 的防火墙，我们可以使用反欺骗规则来告诉 Slartibartfast 立即丢弃来自任何接口（而不是面向我们内部网络的接口）的任何数据包，如果该数据包的源 IP 以 192.168.111 开头。这样的数据包显然是被欺骗的。图 4 显示了 Slartibartfast 的反欺骗规则。

图 4. 反欺骗防火墙规则

在制定此规则之前，我创建了几个网络对象，这些对象引用了 RFC 1918“专用互联网地址分配”中定义的保留 IP 地址空间。RFC 1918 地址空间仅供组织内部使用，不能通过 Internet 路由，因此任何 Internet 防火墙都应将带有此类地址的入站数据包视为欺骗数据包，这正是图 4 中的规则所做的。由于我的 RFC 1918 C 类对象扩展到 192.168.0.0，子网掩码 255.255.0.0，并且我的内部网络地址是 192.168.111.0（RFC 1918 地址空间的一部分），因此没有必要在此规则中包含我的 Net_Internal 对象。

顺便说一句，如果您不熟悉 RFC 1918，我的 RFC 1918 A 类对象指的是 10.0.0.0，子网掩码 255.0.0.0，RFC 1918 B 类对象指的是 172.16.0.0，子网掩码 255.240.0.0。

图 5 显示了 Slartibartfast 的全局策略；由于本文已经太长，我将不再深入解释。但 Firewall Builder 的全部意义在于以易于阅读的格式显示防火墙规则，因此图 5 应该是自明的。

图 5. 网络防火墙的全局策略

说到自明，我有没有提到所有规则（无论是环回、反欺骗还是全局规则）都可以使用 Firewall Builder 的策略向导快速自动生成？您可以通过选择防火墙对象，下拉“规则”菜单并选择“帮助我构建防火墙策略”来运行它。

不要因为直到让您艰难地完成我所有关于以困难方式构建策略的说明之后才提到这一点而对我感到恼火。防火墙规则太重要了，不能完全信任向导。希望您现在可以理解和调整甚至纠正 Firewall Builder 为您生成的规则。无论您如何构建策略，我都希望您发现 Firewall Builder 像我一样有用。