这里所介绍的规则语法已经经过了简化， 只包括了建立标准的明示允许防火墙规则集所必需的那些。 要了解完整的规则语法说明， 请参见 ipfw(8) 联机手册。

规则是由关键字组成的： 这些关键字必须以特定的顺序从左到右书写。 下面的介绍中， 关键字使用粗体表示。 某些关键字还包括了子选项， 这些子选项本身可能也是关键字， 有些还可以包含更多的子选项。

# 用于表示开始一段注释。 它可以出现在一个规则的后面， 也可以独占一行。 空行会被忽略。

CMD RULE_NUMBER ACTION LOGGING SELECTION STATEFUL

有状态过滤将网络流量当作一种双向的包交换来处理。 它提供了一种额外的检查能力， 用以检测会话中的包是否来自最初的发送者， 并在遵循双向包交换的规则进行会话。 如果包与这些规则不符， 则将自动地拒绝它们。

check-state 用来识别在 IPFW 规则集中的包是否符合动态规则机制的规则。 如果匹配， 则允许包通过， 此时防火墙将创建一个新的动态规则来匹配双向交换中的下一个包。 如果不匹配， 则将继续尝试规则集中的下一个规则。

动态规则机制在 SYN-flood 攻击下是脆弱的， 因为这种情况会产生大量的动态规则， 从而耗尽资源。 为了抵抗这种攻击， 从 FreeBSD 中加入了一个叫做 limit 的新选项。 这个选项可以用来限制符合规则的会话允许的并发连接数。 如果动态规则表中的规则数超过 limit 的限制数量， 则包将被丢弃。

记录日志的好处是显而易见的： 它提供了在事后检查所发生的状况的方法， 例如哪些包被丢弃了， 这些包的来源和目的地， 从而为您提供找到攻击者所需的证据。

即使启用了日志机制， IPFW 也不会自行生成任何规则的日志。 防火墙管理员需要指定规则集中的哪些规则应该记录日志， 并在这些规则上增加 log 动作。 一般来说， 只有 deny 规则应记录日志， 例如对于进入的 ICMP ping 的 deny 规则。 另外， 复制 “默认的 ipfw 终极 deny 规则”， 并加入 log 动作来作为您的规则集的最后一条规则也是很常见的用法。 这样， 您就能看到没有匹配任何一条规则的那些数据包。

日志是一把双刃剑， 如果不谨慎地加以利用， 则可能会陷入过多的日志数据中， 并导致磁盘被日志塞满。 将磁盘填满是 DoS 攻击最为老套的手法之一。 由于 syslogd 除了会将日志写入磁盘之外， 还会输出到 root 的控制台屏幕上， 因此有过多的日志信息是很让人恼火的事情。

IPFIREWALL_VERBOSE_LIMIT=5 内核选项将限制同一个规则发到系统日志程序 syslogd(8) 的连续消息的数量。 当内核启用了这个选项时， 某一特定规则所产生的连续消息的数量将封顶为这个数字。 一般来说， 没有办法从连续 200 条一模一样的日志信息中获取更多有用的信息。 举例来说， 如果同一个规则产生了 5 次消息并被记录到 syslogd， 余下的相同的消息将被计数， 并像下面这样发给 syslogd：

所有记录的数据包包消息， 默认情况下会最终写到 /var/log/security 文件中， 后者在 /etc/syslog.conf 文件里进行了定义。

绝大多数有经验的 IPFW 用户会创建一个包含规则的文件， 并且， 按能够以脚本形式运行的方式来书写。 这样做最大的一个好处是， 可以大批量地刷新防火墙规则， 而无须重新启动系统就能够激活它们。 这种方法在测试新规则时会非常方便， 因为同一过程在需要时可以多次执行。 作为脚本， 您可以使用符号替换来撰写那些经常需要使用的值， 并用同一个符号在多个规则中反复地表达它。 下面将给出一个例子。

这个脚本使用的语法同 sh(1)、 csh(1) 以及 tcsh(1) 脚本兼容。 符号替换字段使用美元符号 $ 作为前缀。 符号字段本身并不使用 $ 前缀。 符号替换字段的值必须使用 "双引号" 括起来。

可以使用类似下面的规则文件：

这就是所要做的全部事情了。 例子中的规则并不重要， 它们主要是用来表示如何使用符号替换。

如果把上面的例子保存到 /etc/ipfw.rules 文件中。 下面的命令来会重新加载规则。

/etc/ipfw.rules 这个文件可以放到任何位置， 也可以命名为随便什么别的名字。

也可以手工执行下面的命令来达到类似的目的：

以下的这组非-NAT 规则集， 是如何编写非常安全的 '明示允许' 防火墙的一个例子。 明示允许防火墙只允许匹配了 pass 规则的包通过， 而默认阻止所有的其他数据包。 用来保护整个网段的防火墙， 至少需要有两个网络接口， 并且其上必须配置规则， 以便让防火墙正常工作。

所有类 UNIX® 操作系统， 也包括 FreeBSD， 都设计为允许使用网络接口 lo0 和 IP 地址 127.0.0.1 来完成操作系统内部的通讯。 防火墙必须包含一组规则， 使这些数据包能够无障碍地收发。

接入 Internet 公网的那个网络接口上， 应该配置授权和访问控制， 来限制对外的访问， 以及来自 Internet 公网的访问。 这个接口很可能是您的用户态 PPP 接口， 例如 tun0， 或者您接在 DSL 或电缆 modem 上的网卡。

如果有至少一个网卡接入了防火墙后的内网 LAN， 则必须为这些接口配置规则， 以便让这些接口之间的包能够顺畅地通过。

所有的规则应被组织为三个部分， 所有应无阻碍地通过的规则， 公网的发出规则， 以及公网的接收规则。

公网接口相关的规则的顺序， 应该是最经常用到的放在尽可能靠前的位置， 而最后一个规则， 则应该是阻止那个接口在那一方向上的包。

发出部分的规则只包含一些 allow 规则， 允许选定的那些唯一区分协议的端口号所指定的协议通过， 以允许访问 Internet 公网上的这些服务。 所有的规则中都指定了 proto、 port、 in/out、 via 以及 keep state 这些选项。 proto tcp 规则同时指定 setup 选项， 来区分开始协议会话的包， 以触发将包放入 keep state 规则表中的动作。

接收部分则首先阻止所有不希望的包， 这样做有两个不同的原因。 其一是恶意的包可能和某些允许的流量规则存在部分匹配， 而我们希望阻止， 而不是让这些包仅仅与 allow 规则部分匹配就允许它们进入。 其二是， 已经确信要阻止的包被拒绝这件事， 往往并不是我们需要关注的， 因此只要简单地予以阻止即可。 防火墙规则集中的每个部分的最后一条规则都是阻止并记录包， 这有助于为逮捕攻击者留下法律所要求的证据。

另外一个需要注意的事情是确保系统对不希望的数据包不做回应。 无效的包应被丢弃和消失。 这样， 攻击者便无法知道包是否到达了您的系统。 攻击者对系统了解的越少， 其攻击的难度也就越大。 如果不知道端口号， 可以查阅 /etc/services/ 或到 http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers 并查找一下端口号， 以了解其用途。 另外， 您也可以在这个网页上了解常见木马所使用的端口： http://www.sans.org/security-resources/idfaq/oddports.php。

下面是一个非-NAT 的规则集， 它是一个完整的明示允许规则集。 使用它作为您的规则集不会有什么问题。 只需把那些不需要的服务对应的 pass 规则注释掉就可以了。 如果您在日志中看到消息， 而且不想再看到它们， 只需在接收部分增加一个一个 deny 规则。 您可能需要把 dc0 改为接入公网的接口的名字。 对于使用用户态 PPP 的用户而言， 应该是 tun0。

这些规则遵循一定的模式。

这些规则都应放到 /etc/ipfw.rules。

要使用 IPFW 的 NAT 功能， 还需要进行一些额外的配置。 除了其他 IPFIREWALL 语句之外， 还需要在内核编译配置中加上 option IPDIVERT 语句。

在 /etc/rc.conf 中， 除了普通的 IPFW 配置之外， 还需要加入：

将带状态规则与 divert natd 规则 (网络地址转换) 会使规则集的编写变得非常复杂。 check-state 的位置， 以及 divert natd 规则将变得非常关键。 这样一来， 就不再有简单的顺序处理逻辑流程了。 提供了一种新的动作类型， 称为 skipto。 要使用 skipto 命令， 就必须给每一个规则进行编号， 以确定 skipto 规则号是您希望跳转到的位置。

下面给出了一些未加注释的例子来说明如何编写这样的规则， 用以帮助您理解包处理规则集的处理顺序。

处理流程从规则文件最上边的第一个规则开始处理， 并自顶向下地尝试每一个规则， 直到找到匹配的规则， 且数据包从防火墙中放出为止。 请注意规则号 100 101， 450， 500， 以及 510 的位置非常重要。 这些规则控制发出和接收的包的地址转换过程， 这样它们在 keep-state 动态表中的对应项中就能够与内网的 LAN IP 地址关联。 另一个需要注意的是， 所有的 allow 和 deny 规则都指定了包的方向 (也就是 outbound 或 inbound) 以及网络接口。 最后， 请注意所有发出的会话请求都会请求 skipto rule 500 以完成网络地址转换。

下面以 LAN 用户使用 web 浏览器访问一个 web 页面为例。 Web 页面使用 80 来完成通讯。 当包进入防火墙时， 规则 100 并不匹配， 因为它是发出而不是收到的包。 它能够通过规则 101， 因为这是第一个包， 因而它还没有进入动态状态保持表。 包最终到达规则 125， 并匹配该规则。 最终， 它会通过接入 Internet 公网的网卡发出。 这之前， 包的源地址仍然是内网 IP 地址。 一旦匹配这个规则， 就会触发两个动作。 keep-state 选项会把这个规则发到 keep-state 动态规则表中， 并执行所指定的动作。 动作是发到规则表中的信息的一部分。 在这个例子中， 这个动作是 skipto rule 500。 规则 500 NAT 包的 IP 地址， 并将其发出。 请务必牢记， 这一步非常重要。 接下来， 数据包将到达目的地， 之后返回并从规则集的第一条规则开始处理。 这一次， 它将与规则 100 匹配， 其目的 IP 地址将被映射回对应的内网 LAN IP 地址。 其后， 它会被 check-state 规则处理， 进而在暨存会话表中找到对应项， 并发到 LAN。 数据包接下来发到了内网 LAN PC 上， 而后者则会发送从远程服务器请求下一段数据的新数据包。 这个包会再次由 check-state 规则检查， 并找到发出的表项， 并执行其关联的动作， 即 skipto 500。 包跳转到规则 500 并被 NAT 后发出。

在接收一侧， 已经存在的会话的数据包会被 check-state 规则自动地处理， 并转到 divert nat 规则。 我们需要解决的问题是， 阻止所有的坏数据包， 而只允许授权的服务。 例如在防火墙上运行了 Apache 服务， 而我们希望人们在访问 Internet 公网的同时， 也能够访问本地的 web 站点。 新的接入开始请求包将匹配规则 100， 而 IP 地址则为防火墙所在的服务器而映射到了 LAN IP。 此后， 包会匹配所有我们希望检查的那些令人生厌的东西， 并最终匹配规则 425。 一旦发生匹配， 会发生两件事。 数据包会被发到 keep-state 动态表， 但此时， 所有来自那个源 IP 的会话请求的数量会被限制为 2。 这一做法能够挫败针对指定端口上服务的 DoS 攻击。 动作同时指定了 allow 包应被发到 LAN 上。 包返回时， check-state 规则会识别出包属于某一已经存在的会话交互， 并直接把它发到规则 500 做 NAT， 并发到发出接口。

示范规则集 #1:

下面的这个规则集基本上和上面一样， 但使用了易于读懂的编写方式， 并给出了相当多的注解， 以帮助经验较少的 IPFW 规则编写者更好地理解这些规则到底在做什么。

示范规则集 #2：