验证的iptables防火墙分析和验证

摘要

本文总结了我们围绕使用Isabelle/HOL对iptables规则集进行正式验证的静态分析所做的工作。我们围绕iptables防火墙行为的正式语义构建工作。这种语义是根据过滤器表的具体情况定制的，支持任意匹配表达式，甚至将来可能添加的新表达式。围绕这一点，我们组织了一组简化过程及其正确性证明：我们包括可以展开对用户定义链的调用、简化匹配表达式以及构造近似以删除未知或不需要的匹配表达式的过程。出于分析目的，我们描述了一个简化的防火墙模型，该模型仅支持一组表达能力有限的规则。我们提供并验证了将复杂的iptables语言转换为这个简单模型的过程。在此基础上，我们实现了IP空间分区和最小服务矩阵的验证生成。对我们在大量现实世界防火墙规则集上的工作进行的评估表明，我们的框架在许多情况下都能提供有趣的结果，并且可以帮助并超越相关工作中发现的其他静态分析框架。

1介绍

防火墙是计算机网络的基本安全机制。几种防火墙解决方案，包括开源[66,78,79]到商业[14,37]，存在。操作和管理防火墙具有挑战性，因为规则集通常是手动编写的。虽然防火墙软件本身的漏洞相对较少，但十多年来人们都知道这一点[82]许多防火墙强制执行写得很差的规则集。然而，配置防火墙的普遍方法并没有改变。因此，研究经常报告防火墙规则集的质量不足[25,36,47,54,74,81,84,85,86].

图1

Synology NAS（网络连接存储）设备的Linux iptables规则集

Linux的主要防火墙是iptables[78]. 通常，iptables规则集由Linux内核对每个数据包进行处理，与批处理程序类似：规则是按顺序计算的，但操作（有时称为目标）仅在数据包符合规则标准时才应用。规则列表称为链。最终，Linux内核需要确定是否接受或下降因此，包是常见的操作。进一步可能的操作包括跳转到其他链并从那里继续处理。

作为示例，我们使用图中的防火墙规则1，取自NAS（网络连接存储）设备。规则集如下所示：处理从INPUT（输入）链条。在第一个规则中，所有传入的数据包都直接发送到用户定义的DOS_保护链，其中应用了一些速率限制。不超过特定限制的数据包可以通过此链而不会下降ped由返回回到第二条规则INPUT（输入）链条。在第二条规则中，防火墙允许已经属于的所有数据包已建立（或相关)连接。这通常被视为良好做法。通常已建立rule接受大多数数据包，并出于性能原因放在规则集的开头。然而，对于实际的政策（“谁可以连接到谁“）由防火墙强制执行。有趣的是，当防火墙接受不属于已建立连接的数据包时。一旦数据包被接受，此连接的其他数据包将被视为已建立。在该示例中，后续规则是影响防火墙连接策略的有趣规则。在那里，一些由其端口标识的服务被阻止（并且任何具有这些目的端口的数据包都不会创建已建立的连接）。最后，防火墙允许来自本地网络192.168.0.0/16的所有数据包，并丢弃所有其他数据包。

几个工具[47,48,49,54,59,69,80,85]已开发用于简化防火墙管理并揭示配置错误。许多工具不是直接为iptables设计的，而是基于通用防火墙模型。当我们试图使用公开可用的静态分析工具分析现实世界中的iptables防火墙时，没有一个工具能够处理规则集。即使我们简化了防火墙规则集，我们发现由于以下原因，工具仍然无法分析我们的规则集：

• 它们不支持大量的防火墙功能，

• 他们的防火墙模型过于简单，

• 它们要求管理员学习一种复杂的查询语言，这种语言可能比防火墙语言本身更复杂，

• 分析算法无法扩展到大型防火墙，或

• 无法信任（未验证的）验证工具本身的输出。

为了说明这个问题，我们决定使用ITVal公司[48]因为它本身支持iptables，是开源的，并且支持对用户定义链的调用。然而，ITVal的防火墙模型是大多数工具使用的模型的代表；因此，这里描述的问题也适用于一大类其他工具。相关工作中使用的防火墙模型在第节中进行了调查。 3.1.

我们使用ITVal划分图的IP空间1到等价类中（即具有相同访问权限的范围）[49]. 预期的结果是一组两个IP范围：本地网络192.168.0.0/16和“其余”。然而，ITVal错误地只报告了一个IP范围：宇宙。删除前两个规则（尤其是DOS_保护链）让ITVal计算预期结果。

我们确定了两个具体问题，这两个问题阻碍了工具“理解”真实世界的防火墙。首先，由于可能存在复杂的嵌套链调用，因此需要从自定义链调用和返回。其次，更严重的是，大多数工具都不了解防火墙的匹配条件。在上面的例子中，没有理解速率限制。由于底层算法可能无法处理这种特殊情况，因此不可能为各个工具实现速率限制。即使如此，这也不能解决未知匹配条件的一般问题。防火墙（如iptables）支持多种匹配条件，并且在每个版本中都添加了几个新的匹配条件。截至1.6.0版（Linux内核4.10，2017年初），iptables支持超过60个匹配条件和200个独立选项。我们期望nftables有更多的匹配条件[79]因为它们可以作为简单的用户空间程序编写[45]. 因此，编写一个能够理解所有可能匹配条件的工具几乎是不可能的。再加上生产网络中庞大、复杂和遗留的防火墙规则集随着时间的推移而不断演变，这就构成了一个特殊的挑战。我们解决这一问题的方法也可以应用于语义更简单的防火墙，或功能更少的年轻技术，例如Cisco IOS访问列表或过滤OpenFlow流表（Sect15).

在本文中，我们首先构建了一个基本前提条件，以支持对真实世界防火墙：我们提出了几个保持语义的规则集简化步骤，这将导致后续分析工具“可以理解”的规则集：首先，我们展开对用户定义链的所有调用和从用户定义链返回的所有调用。此过程对于任意匹配条件都是准确有效的。然后，我们处理未知的匹配条件。为此，我们在防火墙的语义中嵌入了一个三元逻辑语义。由于三元逻辑，所有后续分析工具无法理解的匹配条件都可以被视为总是产生未知结果。在下一步中，可以删除所有未知条件。这引入了一个过近似和欠近似规则集，称为上/下闭包。使用相应的闭包规则集可以保证原始规则集丢弃/允许数据包。

总之，我们为简化iptables规则集提供了以下贡献：

• 1 iptables包过滤的正式语义（第4)

• 2 链展开：将复杂链模型中的一个规则集转换为简单列表模型中的规则集（Sect5)

• 三。 带有三元逻辑的嵌入式语义，支持任意匹配条件，引入接受数据包的下/上闭包（Sect6)

• 4 将复杂逻辑表达式规范化并转换为与iptables兼容的格式，发现元逻辑防火墙代数（第7)

我们给出了一个小的中间评估来演示这些通用规则集预处理步骤（Sect8). 然后，我们使用这些预处理步骤在顶部构建一个经过充分验证的iptables分析和验证工具。具体而言，我们的进一步贡献是：

• 5 一个简单的防火墙模型，设计用于数学美观和易于静态分析（第9)

• 6 一种将真实防火墙规则集转换为这个简单模型的方法（Sect10)，具有一系列转换、重写和规范化原始匹配条件的翻译步骤（第11)

• 7 基于简单模型的静态和自动防火墙分析方法（第12)，具有

  • IP地址空间分区

  • 最小服务矩阵

• 8 我们的独立、管理员友好的工具fffuu（飞行功能单位）（第13)

• 9 对大型真实世界数据集的评估（第14)

• 10 通过Isabelle/HOL（第17)

2背景：与Isabelle进行正式验证

我们与伊莎贝尔核实了所有证据[63]，使用其标准高阶逻辑（HOL）。Isabelle是低成本融资传统：该系统基于一个小而完善的内核。所有高级规范和证明工具，例如归纳谓词、函数程序或证明搜索，都必须经过这个内核。因此，所有获得结果的正确性仅取决于此内核和iptables语义的正确性（图2).

包含一组Isabelle理论文件的完整形式化是公开的。感兴趣的读者可以查阅详细的（100多页）证明文件。为了简洁起见，我们通常省略本文中的证明，但用脚注指向形式化的相应部分。章节17向读者指出我们的Isabelle形式化和进一步的附带材料。

符号。我们使用接近SML和Isabelle的伪代码。函数应用程序没有括号，例如。，\（f \ a \）表示功能（f）应用于参数一.我们写作用于在列表前添加单个元素，例如。，、和用于附加列表，例如。，。空列表写为[]。\（[f\a\a\leftarrow l]\）表示列表理解，即应用（f）到每个元素一列表的我.\（[f\x\y.\\x\左箭头l_1，\；y\左箭头l_2]\）表示列表理解，其中（f）应用于列表元素的每个组合\（l_1）和\（l2\）。对于\（f\x\y=（x，\，y）\），这将生成笛卡尔积\（l_1）和\（l2\）.

每当我们提到特定的iptables选项或模块时，我们都会在打字机字体。iptables选项可以在各自的手册页中查找iptables（8）和iptables扩展（8）.

三相关工作

我们首先调查了文献中对防火墙的共同理解，然后介绍了特定的静态防火墙分析工具。

3.1防火墙型号

数据包通过防火墙路由，防火墙需要决定是否允许或拒绝数据包。防火墙的规则集决定其过滤行为。防火墙检查每个数据包的规则集，以确定应用于该数据包的操作。可以将规则集视为规则列表；通常按顺序处理，并应用第一个匹配规则。

文献对单一防火墙规则的定义表示赞同。它由谓词（匹配表达式）和操作组成。如果匹配表达式应用于数据包，则执行该操作。通常情况下，一个数据包是由几个规则检查的。Zhang等人。[86]指定数据包筛选规则的通用格式。操作是“允许”或“拒绝”，这直接对应于防火墙的过滤决定。规则集严格按顺序处理，不可能在链之间跳转。Yuan等人。[85]把这个叫做简单列表模型.ITVal还支持作为操作调用用户定义的链。这允许在规则集中“跳跃”，而无需最终的筛选决策。这称为复杂链模型[85].

通常，数据包头是一个可以与之匹配的位字符串[87]. Zhang等人。[86]支持以下数据包头字段的匹配：IP源和目标地址、协议和第4层上的端口。此模型在文献中常见[6,9,10,69,85,86]. ITVal使用标志（例如。，TCP同步)和连接状态(无效,新款,已建立,相关）。状态匹配仅被视为另一个匹配条件。¹此模型类似于Margrave的IOS模型[54]. 将这些功能与图中的简单防火墙进行比较时1很明显，这些工具都不直接支持该防火墙。

我们并不是第一个建议简化防火墙规则集以进行后续分析的人。Brucker等人。[8,10,11]提供从防火墙策略生成测试用例的算法。他们模型中的防火墙策略是不相交网络上的规则列表。规则是从数据包到决策的部分函数，例如允许或拒绝。为了保持测试用例的数量可管理，首先简化防火墙规则集，同时保留原始行为。用Isabelle/HOL证明了这些变换的正确性。关于低级防火墙功能，Brucker等人使用的实例化。在他们的评估中，比上述工具所使用的模型更加有限。这并不是一个限制，因为它们的框架设计为通过具有更抽象和通用的策略模型来支持不同的防火墙技术。然而，它证明了我们的工具作为一个预处理器，将低级iptables规则转换为通用防火墙模型是一个有用的构建块。通常，使用我们的工具作为预处理器可以使来自相关工作的防火墙分析工具可用于iptables。

我们不知道有任何工具使用的模型与此处描述的模型有根本不同。我们的模型增强了现有的工作，因为我们使用三元逻辑来支持任意匹配条件。为了分析大型iptables防火墙，Margrave的作者[54]将其转换为基本的Cisco IOS访问列表[14]手动操作。通过简化，我们可以自动删除基本Cisco IOS无法理解的所有功能。这使得任何iptables防火墙都可以转换为基本的Cisco访问列表，保证不会比原来的iptables firewall丢掉更多的数据包。这将打开所有仅适用于Cisco IOS访问列表的工具，例如Margrave[54]和标题空间分析[41].²

3.2静态防火墙分析工具

静态防火墙分析的流行工具包括FIREMAN[85]，Capretta等人。[13]和防火墙策略顾问[2]. 他们可以使用以下功能来匹配数据包：IP地址、端口和协议。然而，我们在评估中发现的大多数真实防火墙规则集使用了更多功能。如图所示1除其他外，iptables支持匹配源IP地址、第4层端口、入站接口、连接状态、最近的列表。因此，从我们的评估来看，这些工具（如果没有通用的预处理）将不适用于大多数防火墙。

上述大多数工具都允许检测规则之间的冲突，以发现配置错误。由于我们的方法将规则重写为更简单的形式，并且简化规则与原始规则集的出处和关系丢失，因此我们的方法不支持这一点。然而，我们提供服务矩阵（第12.2)提供防火墙过滤行为的一般概述。

与我们的静态分析工具最相似的工作是ITVal，特别是与我们的IP地址空间分区最相似[48]：它支持大量iptables功能，可以计算IP地址空间分区[49]. ITVal作为一个学术原型，只支持IPv4，未经正式验证，其实现包含多个错误。例如，如果CIDR表示法中IP地址的有效位数为[31]不是8的倍数。它不考虑在下列情况下可能发生的逻辑否定\（{\mathtt{RETURN}}\）过早地从用户定义的链中生成，这会导致对补码集的错误解释。它不支持对未知匹配条件进行抽象，而只是忽略它们，这也会导致虚假结果。有趣的是，当我们试图证明我们的算法的正确性时，我们发现了这些角落案例，而Isabelle则提出了意想不到的证明义务。如果没有正式的验证，我们的工具可能会包含类似的错误。对于超过1000个规则的规则集，ITVal需要数十GB的内存。我们不确定这是内部数据结构的限制，还是只是简单的内存泄漏。ITVal既没有证明其IP地址范围划分的可靠性，也没有证明其最小性。然而，ITVal显示了IP地址范围分区的需要和使用，并证明了它的实现在不触发上述错误的规则集上运行良好。我们的工具强烈地基于ITVal的思想，但使用了不同的算法。

出埃及记[57]将现有设备配置转换为更简单的模型，类似于我们的转换步骤。它将路由器配置转换为一个高级SDN控制器程序，该程序在OpenFlow之上实现。Exodus支持许多Cisco IOS功能。Exodus解决的转换问题与本文中转换为简单防火墙模型的问题相当：OpenFlow 1.0只支持有限的一组功能（与我们的简单防火墙相当），而IOS支持广泛的功能（与iptables相当）。复杂的语言最终被翻译成简单的语言，这是“硬”的方向。

由于我们的方法失去了简化规则与原始规则集的关系，因此我们的方法不能指向个别有缺陷的防火墙规则，而只能提供完整的概述。例如，我们的工具将数千条防火墙规则简化为图中易于理解的图形8，但初始防火墙规则和匹配条件对图的每条边负责的信息将丢失。Margrave是对我们的验证工具的补充，非常适合调试和发现负责任的不当行为规则[54]. Margrave可用于查询防火墙和排除配置故障，或显示规则集编辑的影响。Margrave可以找到场景，也就是说，它可以显示违反安全策略的具体数据包。我们的框架没有显示此类信息。潜在用户必须学习的Margrave查询语言基于一阶逻辑。

所有这些工具都有一个共同的限制：它们不能理解所有iptables匹配条件。我们的通用规则集预处理算法有助于使相应工具可以访问规则集。然而，我们的通用算法仍然丢失了太多信息。这是因为iptables条件也相互关联。例如IP范围该模块允许使用比大多数工具支持的更具表现力的符号来写下IP地址范围。正在删除IP范围匹配将丢失太多信息，因为工具以更简单的格式理解IP地址范围上的匹配。我们需要重写IP范围表达式转换为更简单的、语义表示IP地址的符号，这些符号通常被工具所理解。这可能并不重要，因为一个规则有一个IP范围该表达式可能对应于几个仅与IP地址进行简单匹配的规则。作为一个更复杂的示例，我们看到大多数防火墙分析工具不支持接口匹配。但考虑到防火墙实现了欺骗保护并且路由表已知，网络接口上匹配的条件可以重写为IP地址上匹配的那些条件。中间评估后（第8)，我们在门派。 11针对最常见匹配条件克服这些问题的算法。

4iptables的语义

我们形式化了iptables子集的语义。语义侧重于访问控制，这是在INPUT（输入）,输出、和向前地链滤波器表。因此，不考虑数据包修改（例如NAT）（在这些链中也不允许）。

匹配条件，例如。，来源192.168.0.0/24和TCP协议，被称为基本体.基本匹配器\（伽玛射线）决定数据包是否与原语匹配。形式上，基于集合X（X）基本类型和一组数据包P（P），一个基本匹配器\（伽玛射线）是二元关系X（X）和P（P）。语义支持任意数据包模型和匹配条件，因此在我们的定义中这两者都是抽象的。

在一个防火墙规则中，可以指定多个原语。例如，它们的逻辑连接词是连词\（\texttt{src 192.168.0.0/24}\）和\（{\texttt{tcp}}\）.省略了析取，因为它既不需要形式化，也不受iptables用户界面的支持；这与Jeffrey和Samak的模型一致[39]. 基本体可以组合在以下代数中匹配表达式 \（M_X\）:

匹配表达式\（{\mathsf{Any}}{}\）匹配任何数据包。对于基本匹配器\（伽玛射线）和匹配表达式\（m_X中的m），我们写\（{{\mathsf{match}\{\gamma}}\m\p}\）如果是数据包\（p\ in p\）比赛米，基本上是提升\（伽玛射线）与……的关系\（M_X\）和P（P）连接词的定义与往常一样。完全通用P（P）,X（X）、和\（伽玛射线），可以认为语义可以访问理解所有可能的匹配条件的oracle。

此外，我们支持以下内容行动模仿iptables：\（{\mathtt{Accept}}\）,\（{\mathtt{Reject}}\）,\（｛\mathtt｛Drop｝｝\）,\（{\mathtt{Log}}\）,\（{\mathtt{空}}\）,\（{\mathtt{Call}}\c\）对于链条c（c）、和\（{\mathtt{Return}}\）.A型规则可以定义为元组\（（m，\，a）\）用于匹配表达式米和一个动作一。规则列表（或序列）称为链。例如\（{\texttt{DOS\_PROTECT}}\）图中的链条1是\（[（{\textt{icmp}}\wedge{\texttt{icmptype 8限制：}}\，\dots，\，{\mathtt{Return}}），\，\ dots]\）.

一组命名链称为规则集.让\（\varGamma\）表示从链名称到链的映射。例如，\（\varGamma\｛\texttt｛DOS_PROTECT｝｝）返回\（{\texttt{DOS\_PROTECT}}\）链条。我们假设\（\varGamma\）格式良好，也就是说，如果\（{\mathtt{Call}}\c\）操作发生在规则集中，然后链命名为c（c）定义于\（\varGamma\）。这个假设是合理的，因为Linux内核只接受格式良好的规则集。

4.1归纳定义

防火墙写入给定数据包的语义第页，一个后台规则集\（\varGamma\），和一个原始匹配器\（伽玛射线）可以定义为当前活动链与处理此链之前和之后的状态之间的关系。语义如图所示2.^三判决书\（{\varGamma，\gamma，p\vdash\big\langle-rs，\；t\big\rangle\Rightarrow t'}\）以state开头的状态t吨，加工链条后\（个\），得到的状态为\（t’\）.对于数据包第页，我们的语义侧重于防火墙过滤决策。因此，只需要以下三种状态：防火墙可能允许(\（\text圈出{\复选标记}\）)或者否认()或者它可能还没有做出决定(\（\textcircled{？}\）).

我们现在将讨论最重要的规则。

\（\textsc{接受}\）:

如果数据包第页匹配匹配表达式米，然后是没有过滤决策的防火墙(\（\textcircled{？}\）)处理单例链\（[（m，\，{\mathtt{Accept}}）]\）通过切换到允许状态。

\（\textsc{Drop}/\textsc{Reject}\）:

这两个操作都会拒绝数据包。区别在于防火墙是否生成一些信息性消息，这不会影响过滤。

\（\textsc{NoMatch}\）:

如果防火墙还没有做出过滤决定，它可以处理任何不匹配的规则，而不更改其状态。

\（\textsc{决策}\）:

一旦防火墙做出过滤决定，就可以跳过所有剩余的规则。给定确定性（定理2)，这意味着一旦决定，防火墙不会更改其过滤决定\（\text圈出{\复选标记}\）或.

\（\textsc{Seq}\）:

如果防火墙没有做出过滤决定，它会处理链\（rs _1\），这将导致状态t吨从开始t吨处理链\（秒2\），这将导致状态\（t’\），然后可以顺序处理这两个链，以状态结束\（t’\）.

\（\textsc{CallResult}\）:

如果匹配\（｛\mathtt｛Call｝｝\）连接到名为“c（c）“发生时，产生的状态t吨是处理链的结果\（\varGamma\；c\）.

\（\textsc{CallReturn}\）:

同样，如果处理前缀\（rs _1\）被调用链的\（{\mathtt{Return}}\）规则发生时，被调用的链被处理而没有结果。

\（\textsc{Log}/\textsc{Empty}\）:

这两条规则都不会影响过滤行为。一个清空规则，即没有动作的规则，有时被管理员用来让iptables只更新其内部状态，例如更新数据包计数器。

图2

iptables的大步语义

图3

iptables的可选大步骤语义

语义经过精心设计，不需要调用堆栈。的格式调用返回规则是此设计的一部分：如果我们尝试引入一个允许处理\（{\mathtt{Return}}\）不处理其匹配\（｛\mathtt｛Call｝｝\）或者操纵一些调用堆栈，我们必然会导致顺序规则。这是因为\（{\mathtt{Return}}\）需要留在\（\textcircled{？}\）状态，然后来自同一链的稍后规则（我们应该已经从中返回）可以切换到决策状态。避免此问题的一种方法是合并顺序和决策将规则转换为所有其他规则。这样做之后，可以引入一个单独的返回规则，并额外删除初始状态，因为它总是\（\textcircled{？}\）这种替代配方的生产示例集如图所示三。对于我们的证明的实际实施，此替代方案缺乏灵活性：因为顺序规则不再适用，我们不能轻易地将规则列表的参数与规则的不同操作类型的参数分开。我们将其作为等效项提供⁴因为我们希望这可以为语义的正确性提供额外的信心：

定理1

（两个语义的等价性）如果没有调用c（c）发生在\（\varGamma\）和是其中之一\（{\mathtt{Accept}}\）或\（｛\mathtt｛Drop｝｝\），然后

注意，对于有限规则集（即\（\varGamma\）是有限的），我们总是可以找到c（c）这样就不会发生调用。实际上，我们将选择c（c）成为INPUT（输入）,向前地，或输出。Linux内核拒绝用户直接调用这些链的规则集。

4.2模型限制和状态匹配器

我们的原始匹配器是完全无状态的：\（\gamma:{：}\left（X\右箭头P\右箭头\mathbb{B}\right）\）然而，iptables还允许有状态操作，例如标记数据包，以及稍后在标记上进行匹配。

iptables的文档区分了匹配扩展名和目标扩展。理想情况下，几乎所有匹配扩展都可以像无状态一样使用。执行动作的任何内容都应作为目标扩展实现，即动作。例如，用标记包康马克是一种行动。匹配上的康马克标记是匹配条件。我们的语义不支持康马克行动。这不是问题，因为通常情况下康马克标记未设置在滤波器表。但是，可以在现有标记上进行匹配。由于我们的原始匹配器和数据包是完全通用的，因此这种情况可以在我们的语义中表示：而不是保留内部康马克状态时，必须在数据包模型中引入额外的“ghost字段”。由于数据包是不可变的，因此无法通过规则设置此字段，但必须将数据包交给防火墙，并且必须设置ghost字段的最终值。因此，当数据包被提供给滤波器表。我们承认，这种模式总的来说非常笨拙。然而，对于iptables中最常用的状态模块之一，即使用连接跟踪和状态，该模型已被证明非常方便。⁵我们将在Sect.中详细介绍有状态连接跟踪（我们的语义可以完全支持它）。 11.2。对于未来的工作，如果我们想考虑未经加工的或捣碎表及其扩展的操作集或OpenFlow及其完整的操作集，需要使用可变的数据包模型来设计语义。

如果匹配扩展维护内部状态并在每次调用时更改其行为，该怎么办？理想情况下，由于可用性，iptables匹配扩展应该是“纯功能性的”；然而最近的和连接字节模块会对其内部状态产生副作用。因此，布尔逻辑中的重言式“\（a \ wedge \ lnot a=\ mathsf{False}\）“不适用于一是在每次调用后更新内部状态及其匹配行为的模块。因此，有人可能会认为我们的iptables模型只能应用于无状态匹配条件。如果我们添加一些状态\（\西格玛\）和更新的状态\（西格玛）匹配条件，公式“\（a_\sigma\wedget\lnot a_{\sigma’}）“现在正确表示有状态匹配条件。因此，只对有状态匹配条件执行相等操作是错误的，而不对具有特定固定状态的有状态匹配情况进行建模。为了进一步使读者相信我们方法的合理性，可以对解析器进行调整，以便为每个未知的无状态原语提供唯一的标识符。此标识符表示规则集中特定位置处特定匹配条件的内部状态。它防止在多个有状态匹配条件调用之间进行相等操作。这不会改变我们的任何算法。

4.3语义的分析和使用

本文的后续部分都是基于这些语义的。每当我们提供程序时\（\mathsf{P}\）为了在链上操作，我们证明了防火墙的过滤行为在形式上得到了保留：

我们所有的证明都经过伊莎贝尔的机器验证。因此，一旦读者确信图中规定的语义2，所有后续定理的正确性都会自动遵循，没有任何隐藏的假设或限制。

图中的规则2设计成可以单独检查每条规则。然而，综合考虑所有这些因素，尚不清楚结果是否取决于它们应用于具体规则集和数据包的顺序。定理2声明语义是确定性的，即只有一个唯一定义的结果是可能的。⁶

定理2

（决定论）

接下来，我们展示了语义实际上是完整的，即，对于任何数据包和规则集，总是有一个决策。⁷我们假设规则集没有无限循环，并且被调用的所有链都存在于后台规则集中。这些条件由Linux内核检查，因此可以安全地假定。此外，我们假设只有图2发生在规则集中；我们的解析器拒绝其他所有内容。

我们从以下方面开始分析，其中默认策略为\（{\mathtt{Accept}}\）或\（｛\mathtt｛Drop｝｝\）。这意味着现有顶级\（{\mathtt{Return}}\）操作返回到默认策略。这与iptables的行为一致。

定理3

（总计）如果调用方-被调用方关系基础良好（即，没有无限的调用循环），\（\varGamma\）格式良好（即定义了所有被调用的链名称），则没有\（{\mathtt{Return}}\）在顶层，语义支持所有操作，然后

为了从经验上断言我们只允许根据语义分析iptables规则集，我们总是检查定理的前提条件三在运行时，当我们的工具加载规则集时：首先，我们可以静态地验证\（\varGamma\）通过验证操作中引用的所有链名称都已定义并且没有发生不受支持的操作，可以很好地形成。接下来，我们的工具通过展开规则集（Sect5)只有有限但足够多的次数，并且如果规则集后来的形式不正确，则会中止。这些条件只在我们分析过的所有真实世界防火墙中被违反了一小部分。那些使用了非常特殊的iptables操作⁸我们的语义或特殊的手工防火墙不支持，这些防火墙故意违反属性，也被Linux内核拒绝。

5自定义链展开

在本节中，我们将介绍将规则集从复杂链模型转换为简单列表模型的算法。

功能\（\mathsf{pr}\）（“process-return”）在链上迭代。如果\（{\mathtt{Return}}\）规则，所有后续规则都将通过添加\（{\mathtt{Return}}\）规则的否定匹配表达式作为连接词。直觉上，如果\（{\mathtt{Return}}\）规则发生在链中，只有在\（{\mathtt{Return}}\）规则不匹配。

功能\（\mathsf{pc}\）（“进程调用”）在链上迭代，展开一级\（｛\mathtt｛Call｝｝\）规则。如果\（｛\mathtt｛Call｝｝\）到链条c（c）发生时，链本身（即。，\（\varGamma\c\）)插入，而不是\（｛\mathtt｛Call｝｝\）然而，\（{\mathtt{Return}}\）链中的s需要处理，并且原始的匹配表达式\（｛\mathtt｛Call｝｝\）需要添加到插入的链中。

程序\（\mathsf{pc}\）可以任意多次应用，并保留语义。⁹

定理4

(\（\mathsf{pc}\）完好完整）

在每次迭代中，算法展开一个级别\（｛\mathtt｛Call｝｝\）s.需要应用算法，直到结果不再改变。请注意，语法和语义允许非终止规则集。然而，唯一值得分析的规则集是Linux内核实际接受的规则集。因为它拒绝带循环的规则集，¹⁰我们的算法和生成的规则集都保证终止。

推论1

每个规则集（只有\（{\mathtt{Accept}}\）,\（｛\mathtt｛Drop｝｝\）,\（{\mathtt{Reject}}\）,\（{\mathtt{Log}}\）,\（{\mathtt{空}}\）,\（｛\mathtt｛Call｝｝\）,\（{\mathtt{Return}}\）操作）可以完全展开，同时保留其过滤行为。

由于我们还没有正式验证Linux内核源代码，推论1未经正式证明。它遵循我们之前的定理，我们已经对其进行了广泛的实证检验。

除了展开调用之外，应用于任何规则集的以下转换还保留了语义：

• 更换\（{\mathtt{Reject}}\）操作与\（｛\mathtt｛Drop｝｝\）行动，¹¹

• 移除\（{\mathtt{空}}\）和\（{\mathtt{Log}}\）规则，¹²

• 简化包含以下内容的匹配表达式\（{\mathsf{Any}}{}\）或\（\lnot\，{\mathsf{Any}}{}\）,¹³

• 对于某些给定的基本匹配器，特定的优化，¹⁴例如，重写源代码0.0.0.0/0到\（{\mathsf{Any}}{}\）.

因此，展开和优化后，只包含\（{\mathtt{Accept}}\）或\（｛\mathtt｛Drop｝｝\）剩下个操作。在接下来的部分中，我们要求这是一个先决条件。例如，调用图中的防火墙1.它\（{\texttt{INPUT}}\）展开和优化后的链如图所示4观察到一些计算出的匹配表达式超出了iptables命令行用户界面所支持的表达能力。我们将在门派中对此进行详细说明。 7.

图4

展开的Synology防火墙

6未知基本体

如前所述，支持防火墙的所有可能原语是不可行的。假设创建了一个新的防火墙模块，该模块提供\（{\texttt{ssh\_blacklisted}}\）和ssh_无基本体。如果一个IP地址在过去有过多次无效的SSH登录尝试，则前者适用；后者与前者相反。因为我们发明了这些原语，所以没有现有的工具支持它们。然而，iptables的新版本可以实现它们，也可以作为第三方内核模块提供。因此，我们的规则集转换必须考虑未知原语。为了实现这一点，我们提升了基本匹配器\（伽玛射线）到三元逻辑，添加\（\mathsf{未知}\）作为匹配结果。我们将这个新的“近似”语义嵌入到前面部分描述的语义中。因此，构建针对特定工具支持的原语的匹配器变得更加容易。

6.1三值匹配

三元值的逻辑合取和否定与布尔逻辑中的一样，还有以下附加规则\（\mathsf{未知}\）操作数（省略交换情况）：

这些规则与Kleene的三值逻辑相对应[42]和非常适合防火墙语义。对于防火墙规则，第一个等式表明，如果一个条件匹配，最终结果只取决于另一个条件。下一个等式表示，如果规则的某个条件不匹配，则该规则无法匹配。最后，通过否定未知值，无法推断出任何附加信息。匹配表达式\（{\mathsf{Any}}{}\）始终计算为\（\mathsf{True}\）和\（\lnot\；{\mathsf{Any}}{}\）始终计算为\（\mathsf{False}\）对于任何\（伽玛射线）。匹配表达式的计算结果可能为\（\mathsf{未知}\）如果它包含未知原语\（x中的x）.

我们演示了\（\lnot\，\mathsf{Unknown}=\mathsf{Unknows}\）逐个示例：两个规则集\（\left[（{\texttt{ssh\_blacklisted}}，\，{\mathtt{Drop}}）\right]\）和\（\left[（｛\mathsf｛Any｝｝｛｝，\，｛\mathtt｛Call｝｝\c）\right]\）哪里\（\varGamma\，c\，=[（\mathtt{ssh\_innocent}，\，{\mathtt{Return}}），\，（{\mathsf{Any}}{}，，{\mathtt{Drop}}，）]\）具有完全相同的过滤行为。展开后，第二个规则集折叠为\（\left[（\lnot；{\texttt{ssh\innocent}}，\，{mathtt{Drop}}）\right]\）。两个ssh_黑名单和ssh_无基本体是\（\mathsf{未知}\）给我们的火柴。因此，由于两个规则集具有相同的过滤行为，因此数据包匹配\（\mathsf{未知}\）在第一个规则集中也应该匹配\（\lnot\；\mathsf{未知}\）在第二个规则集中。

三值逻辑中的状态匹配器。在Sect。 4.2，我们讨论了一些匹配条件可能保持内部状态的问题。对于匹配条件一更新内部状态，“\（a \ wedge \ lnot a=\ mathsf{False}\）“可能无法保持。我们认为，对于某些州来说\（\西格玛\）和\（西格玛），有状态匹配条件需要用其内部状态进行扩充。例如“\（a_\sigma\wedget\lnot a_{\sigma’}）“，这不是同义反复。在我们的实现中，我们立即将所有内容嵌入到三元逻辑中，并将所有不一定是无状态的原语视为“未知”。这避免了内部状态的问题，并产生“\（a \ wedge \ lnot a=\ mathsf{未知}\）“，它正确地描述了该行为，因为我们不知道某些任意匹配条件的潜在内部状态一.

6.2关闭

在三元语义中，可能不知道规则是否适用于数据包。因此，匹配语义被扩展为“怀疑”-策略。如果匹配表达式的结果为\（\mathsf{未知}\）。它决定是否应用规则。

我们介绍有疑问-\（允许\）和有疑问-\（拒绝\）战术。如果规则的动作是\（{\mathtt{Accept}}\）如果是，则为不匹配\（｛\mathtt｛Drop｝｝\）第二种策略表现为相反的方式。请注意，展开的规则集是必要的，因为不能为指定任何行为\（｛\mathtt｛Call｝｝\）和\（{\mathtt{Return}}\）行动。¹⁵

我们用“\（\向右箭头\）“并使用任意策略嵌入三元语义\（\字母\）带有“\（\右箭头_\字母\）”. 特别地，\（\字母\）=允许有疑问-\（允许\）和\（\字母\）=类似地否认。

“\（\向右箭头\）“和”\（\右箭头_\字母\）“与以下策略相关：考虑到所有接受的数据包的集合，有疑问-\（允许\）是过于接近，而有疑问-\（拒绝\）是一个欠近似值。换句话说，如果“\（\向右箭头\）“接受数据包，然后”\（\Rightarrow_{{text{allow}}}\）”也接受数据包。因此，从相反的角度来看有疑问-\（允许\）该策略可用于确保数据包确实被丢弃。同样，如果“\（\向右箭头\）“拒绝数据包，然后”\（\Rightarrow_{{text{deny}}}\）“也否认这个数据包。因此有疑问-\（拒绝\）该策略可用于确保包确实被接受。

例如，图1包含在超过限制时丢弃数据包的规则。如果不理解此速率限制\（伽玛射线），的有疑问-\（允许\）策略永远不会应用此规则，而有疑问-\（拒绝\）战术，它是普遍适用的。

我们说，如果布尔匹配器和三元匹配器返回相同的结果，或者三元匹配程序返回\（\mathsf{未知}\）。解释此定义时，三元匹配器可能始终返回\（\mathsf{未知}\）布尔匹配器是一个知道正确结果的预言器。请注意，我们从未明确指定布尔匹配器的任何内容；因此，该模型是普遍有效的，即证明适用于任意预言机。

如果精确匹配器和三元匹配器一致，则有疑问-\（拒绝\）策略是精确语义所允许的数据包的子集，而精确语义又是有疑问-\（允许\）战术。¹⁶因此，我们调用接受的所有数据包\（\Rightarrow_{{text{deny}}}\）这个下部闭合即，最多接受确切语义所接受的包的语义。同样，我们调用接受的所有数据包\（\Rightarrow_{{text{allow}}}\）这个上部封盖即，至少接受确切语义所接受的包的语义。每一个不在上层封包中的数据包都会被防火墙丢弃。

定理5

（允许数据包的上下闭合）

相反，对于一组被拒绝的数据包，则适用。¹⁷

对于图中的示例1，我们计算了闭包（没有相关、建立预计起飞时间规则，请参阅第节。 6.4)以及仅理解IP地址和第4层协议的三元匹配器。较低的闭包是空集，因为速率限制可能适用于任何数据包。上闭包是192.168.0.0/16的数据包集合。

6.3删除未知匹配项

在本节中，作为最后的优化，我们删除了所有未知原语。我们称此算法为\（\mathsf{pu}\）（“过程未知”）。对于这一步，必须知道具体的三元匹配器和战术选择。

在每个规则中，顶级未知原语都可以重写为\（{\mathsf{Any}}{}\）或\（\lnot\，{\mathsf{Any}}{}\）例如，让\（m_u\）是未知的原语\（伽玛射线）。那么，对于有疑问-\（允许\）,\（（m_u，\，{\mathtt{Accept}}）\）等于\（（（{\mathsf{Any}}{}，\，{\mathtt{Accept}}）\）和\（（m_u，\，{\mathtt{Drop}}）\）等于\（（\lnot\，{\mathsf{Any}}{}，\，{\tatht{Drop}}）\）类似地，否定的未知原语和（否定的）未知原语的连词可以重写。

因此\（\mathsf{pu}\）都很简单。然而，在匹配表达式的否定连词的情况下需要小心。以下等式表示De Morgan规则，专门用于有疑问-\（允许\）战术。

该算法明确适用于“\（{\mathsf{Any}}{}\）'而不是'\（\mathsf{True}\）'，因为在这种情况下，\（{\mathsf{Any}}{}\）是匹配表达式的句法基本格\（M_X\）而不是布尔值或三元值。这个\（\lnot；\mathsf{Unknown}=\mathsf{Unknows}\）这个等式是德摩根规则复杂本质的原因。幸运的是，我们对所有算法进行了机器验证。¹⁸有趣的是，我们最初编写了一个看似简单（但不正确）的\（\mathsf{pu}\）大家一致认为这个算法看起来是正确的。在早期的经验评估中，由于还没有完成证据，我们没有发现我们的缺陷。只有在正确性证明失败的情况下，我们才意识到我们引入了一个只适用于布尔逻辑的方程。

定理6

(\（\mathsf{pu}\）完好完整）

定理7

算法\（\mathsf{pu}\）删除所有未知的基元匹配表达式。

的算法有疑问-\（拒绝\）战术（与De Morgan案件的等式相同）可以以类似的方式指定。因此，\（\Rightarrow_{\alpha}\）可以将其视为仅在具有已知匹配表达式的布尔逻辑上定义。

作为一个例子，我们检查了图的上闭包的规则集1（没有相关、建立规则，请参阅第节。 6.4)用于仅了解IP地址和第4层协议的三元匹配器。规则集简化为\（[（{\textt{src192.168.0/16}}，\，{\mathtt{Accept}}），\，（{\mathsf{Any}}{}，，{\mathtt{Drop}}.ITVal现在可以直接计算此规则集的正确结果。

6.4这个相关,已建立规则

由于防火墙按顺序处理规则，因此第一条规则不依赖于任何先前的规则。类似地，开始时的规则很少依赖于其他规则。因此，可以手动检查一开始的防火墙规则，而手动检查的复杂性随着前面每增加一条规则而增加。

使用已建立（有时相关)规则[29]. 这也发生在图1在速率限制之后。这个已建立规则通常匹配大多数数据包[29],¹⁹这对性能很重要；然而，在分析防火墙的过滤行为时，重要的是要考虑如何使连接处于这种状态。因此，我们删除了此规则，只关注连接设置。

这个已建立规则本质上允许数据包以与所有后续规则相反的方向流动[20]. 除非有特殊的安全要求（在我们分析的任何场景中都不是这样），否则已建立分析连接设置时可以排除规则[20，推论1]。²⁰如果已建立规则被删除，在随后的规则中，例如，原语状态NEW发生时，我们的三元匹配器返回未知。关闭过程自动处理这些情况，无需任何额外知识。

我们的通用规则集重写算法不知道连接状态。因此，对于我们的中间评估（第8)，我们删除了已建立手工制定规则。在Sect。 11.2，我们将描述我们的改进，这些改进将支持conntrack state。不再需要手动排除规则。简而言之，我们将全力支持conntrack状态上的匹配，例如已建立或新款。本节的观察和论证仍然是：对于访问控制分析，我们重点关注新款小包。

7规范化

规则集展开可能导致非原子匹配表达式，如\（\不\，（a \楔形b）\）。iptables用户界面仅支持中的匹配表达式否定范式（NNF）。²¹在那里，否定只能出现在原语之前，而不能出现在复合表达式之前。例如，\（\lnot\，（{\texttt{src}}\，ip）\，\wedge\，\mathtt{tcp}\）是有效的NNF公式，而\（\lnot\，\left（\ left（{\texttt{src}}\，ip\right）\，\wedge\，\mathtt{tcp}\ right）不是。原因是iptables规则通常在命令行中指定，并且每个基元都是iptables命令，例如\（\texttt{！--src}\，ip{\texttt}-p\，tcp}}\）。我们使用以下观察结果将匹配表达式规范化为NNF：

De Morgan的规则可以应用于匹配表达式，将一个规则拆分为两个。例如，\（\left[\left（\lnot\；（{\texttt{src}}\，ip\；\wedge\；{\texttt{tcp}}），\，{\mathtt{Accept}}\right）\right]\）和\（[（\lnot\；{\textt{src}}\，ip，\；{\mathtt{Accept}}），\，（\lnot；{\text{tcp}}，\，{\matht{Accept}}是等效的。这引入了一个“元逻辑”析取，由一系列具有共享操作的连续规则组成。例如，\（[（m_1，\，a），\；（m_2，\，a）]\）等于\（[（m_1\vee m_2，\，a）]\）.

对于具有相同动作的规则序列，类似于普通布尔逻辑的分配律成立。例如，两个规则集的连接

$$\开始{aligned}&[（m_1，\，a），\；（m_2，\，a）]&\text{和}&[[（m_3，\$$

等同于规则集

$$\begin｛aligned｝和[（｛m_1\wedge m_3｝，\，a），\；（｛m_1\wedge m_4｝，\，a），\；（m_2\wedge m_3，\，a），\；（m_2\wedge m_4，\，a）]\text｛.｝和\end｛aligned｝$$

这可以用以下情况来说明：\（a={\mathtt{Accept}}\）一个数据包需要连续通过两个防火墙。

我们现在可以构造一个过程，将带有复杂匹配表达式的规则转换为NNF中带有匹配表达式的一系列规则。它独立于特定的原始匹配器和使用的可疑策略。算法\（\mathsf{n}\）（“规范化”）类型\（M_X\右箭头M_X\list\）定义如下：

第二个等式对应于分配定律，第三个等式则对应于德摩根法则。例如，\（\mathsf{n}\\left（\lnot\，（{\texttt{src}}\；ip\wedge{\texttt{tcp}}）\right）=\left[\lnot\\，{\textt{src{}}\，ip，\，\lnot \，{\ttexttt{tcp}}\right]\）。第五条规则表示可以完全删除不匹配的规则。

图的展开规则集4由9个规则组成，可以规范化为20个规则的规则集（由于分布性）。在最坏的情况下，归一化可能会导致指数级爆发。我们的评估表明，即使对于大型规则集，这在实践中也不是问题。这是因为规则集通常是手动管理的，这自然会将其复杂性限制在最先进的硬件可以处理的级别。

定理8

\（\mathsf{n}\）总是终止，返回列表中的所有匹配表达式都是NNF格式的，它们的连接等价于原始表达式。²²

我们展示了任意性的稳健性和完整性\（伽玛射线）,\（\字母\）、和原语。²³因此，它也适用于布尔语义。一般来说，关于三元语义的证明更强，因为三元原语匹配器可以模拟布尔匹配器。²⁴

定理9

(\（\mathsf{n}\）完好完整）

经过标准化处理后\（\mathsf{n}\），这些规则大多可以反馈给iptables。对于某些特定的原语，iptables施加了额外的限制，例如，在单个规则中最多可以存在一个类型的原语。对于我们的中间评估，我们只需要解决CIDR表示法中IP地址范围的这个问题[31]. 我们引入并验证了另一种转换，该转换计算IP地址范围的交集，最多返回一个范围。这足以处理我们在中间评估期间遇到的所有规则集。在下面的部分中，我们将展示如何支持更多的基元；中间评估只关注IP地址；最终评估（第14)包含了更多的原语。

8中级评估

在本节中，我们将演示到目前为止所描述的规则集预处理的适用性。通常，由于潜在的负面安全影响，网络管理员不倾向于发布防火墙规则集。对于这个中间评估，我们获得了大约\（20\text{k}\）真实世界的规则和发布它们的权限（第17). 接下来是一个更大的评估。 14除了图1（一个小型的真实世界防火墙），我们在其他四个真实世界防火墙上测试了我们的算法。我们将重点放在第三个规则集上，因为它是最大、最有趣的规则集之一。

为了进行分析，我们想知道防火墙是如何划分IPv4空间的。因此，我们使用了一个匹配器\（伽玛射线）它只了解源/目标IP地址和第4层协议TCP和UDP。我们的算法不需要特殊的处理能力，它们可以在几秒钟内在一台普通的带4GB内存的笔记本电脑上执行。

规则集1是从Shorewall上取下的[28]防火墙，运行在家庭路由器上，有大约500条规则。我们验证了我们的算法正确地展开、预处理和简化了这个规则集。我们期望看到，在上下封闭中，防火墙会从私有IP范围中丢弃数据包。然而，我们在上面的闭包中看不到这一点，并验证了如果这些数据包的连接处于特定状态，防火墙确实不会阻止这些数据包。防火墙管理员确认了这个问题，并在进一步调查后重写了整个防火墙。

规则集2取自在线找到的小型防火墙脚本[38]. 虽然它只包含了大约50条规则，但我们发现它包含了一个严重的错误。我们认为作者无意中混淆了iptables的-我（插入顶部）和-A类（在尾部追加）选项。我们在展开后看到了这一点，因为防火墙在开始时几乎允许所有数据包。后续规则被隐藏，无法应用。然而，这些规则附带了其预期用途的文档，例如“删除保留地址”，这突出了错误。我们通过在系统上安装防火墙来验证错误行为。因此，我们的展开算法本身可以提供有价值的见解。

规则集3和4取自我们实验室的主防火墙（网络架构和服务主席）。2013年拍摄的一张快照包含2800条规则，2014年拍摄的另一张快照中包含约4000条规则。很明显，这些规则集在历史上不断增长。大约10年前，这两个规则集将是学术界分析过的最大的现实世界规则集[82].

我们提供了2013版防火墙的分析结果。详细信息可以在附加材料中找到，规则集的开头如图所示5。我们删除了前三条规则。第一条规则是已建立规则，如第节所述。 6.4。当我们计算下闭包时，我们的重点放在了第二条规则上：这个规则负责下闭包是空集。在仔细检查该规则后，我们发现它是“死的”，即它永远不适用。我们通过将目标更改为\（{\mathtt{Log}}\）对真正的防火墙采取行动，几个月内再也看不到这条规则的影响。根据我们的分析，这条规则可以删除。第三条规则执行SSH速率限制（a\（｛\mathtt｛Drop｝｝\）规则）。我们删除了这个规则，因为我们对它有了很好的理解。保留它不会影响上闭包的正确性，但会导致下闭包比必要的更小。

首先，我们使用维护良好的防火墙生成器测试了规则集[59]. 由于未知的匹配表达式导致22个错误，防火墙生成器无法导入原始规则集。使用计算出的上限闭包，Firewall Builder可以毫无问题地导入此规则集。

接下来，我们测试了ITVal的IP空间分区查询[49]. 在包含2800条规则的原始规则集上，ITVal用大约3GB的RAM在大约1分钟内完成了查询。通过分析ITVal的调试输出，我们发现由于未知的原语，大多数规则没有被正确理解。因此，结果并不可靠。我们可以验证这一点，因为127.0.0.0/8显然是被我们的防火墙删除的，与互联网的其他部分属于同一类。相反，使用上下闭包规则集，ITVal正确地将127.0.0.0/8标识为自己的类。

图5

我们实验室2013年iptables规则集的摘录（第一条规则）

我们发现了关于ITVal的另一个有趣的结果：（优化的）上闭包规则集仅包含大约1000条规则，下闭包仅包含大约500条规则。因此，我们预计ITVal可以更快地处理这些规则集。然而，情况恰恰相反：ITVal需要10倍以上的资源（CPU和RAM；我们必须将分析转移到内存大于40 GB的大型计算机上）来完成闭包的分析。我们认为这是由于ITVal现在理解了这一事实全部的规则。然而，帮派。 14将揭示ITVal仍然计算错误的结果。

翻译的局限性。我们检查了简化的规则集，并观察到了翻译的一些局限性。这些限制主要是因为我们的算法可以处理任意的\（伽玛射线）虽然这是一个重要的特性，但也意味着我们到目前为止没有考虑特定基元的特性。

我们说过iptables只接受NNF中的匹配表达式，但仅此条件是不够的。除了NNF之外，每个基元在匹配表达式中最多必须出现一次。例如，iptables不允许有两个-秒与表达式中的源IP地址匹配的基元。然而，这种表达式可能会在展开和NNF规范化后出现。对于这个中间评估，我们解决了这个问题，因为我们可以将IP地址上任意数量的匹配项的合并压缩为IP地址上的单个匹配项：CIDR表示法中IP地址范围的交集要么是所有范围中最小的，要么是空集（详细信息请参阅第11.1). 类似地，协议上所有相同匹配的连接要么是协议本身，否则匹配表达式不能应用于任何数据包，并且可以删除完整的规则。例如，一个规则在两者上都匹配tcp协议和icmp公司可以删除，因为数据包不能同时删除。此外，我们还看到了带有“未知”部分的规则（在删除未知原语之前），这些规则永远不会匹配，应该删除。例如，数据包不可能只有SYN（同步）而且只有确认同时设置标志。然而，没有提供有关tcp协议标志，我们对未知匹配条件的一般处理可能会假定此匹配条件可能适用，并且简化后此类规则仍然存在。因此，我们的简化仍然过于粗糙，并且丢失了太多信息。此外，正如我们在第。 3.2，原语也可能是相关的，可以转换为更简单的原语。我们将在下面的部分中详细介绍原语的处理。

9简单防火墙模型

现在，我们提出一个非常简单的防火墙模型。这个模型被设计成具有良好的数学特性，但它过于简单，无法反映现实世界。然后，我们将其与我们的Sect真实防火墙模型进行比较。 4.截面10将显示如何在这两个模型之间转换规则集。此预处理步骤将防火墙规则集从实际模型转换为简单模型，从而大大简化了所有未来的静态防火墙分析。

我们将把简单的防火墙规则编写为元组\（（m，\；a）\），其中米是匹配表达式，并且一是防火墙执行的操作，如果米匹配数据包。防火墙有两种可能的过滤决定：它可以接受(\（\text圈出{\复选标记}\）)数据包或拒绝()数据包。我们还将使用中间状态(\（\textcircled{？}\）)其中防火墙尚未做出过滤决定。请注意，iptables防火墙总是有一个默认策略和\（\textcircled{？}\）案例不能作为我们将要构建的简单防火墙的最终决定。

简单模型的语义由递归函数给出。第一个参数是防火墙迭代的规则集，第二个参数是数据包。

一个函数\（\mathsf{smatch}\）测试数据包是否第页符合匹配条件米.²⁵匹配条件是一个7元组，由以下原语组成：

与iptables相比，不支持否定匹配。具体来说，支持以下原语：

• 输入/输出接口，包括对“+'通配符

• CIDR表示法中的源/目标IP地址范围，例如192.168.0.0/24

• 协议(\（\mathsf{any}\）,tcp协议,udp（统一数据处理程序）,icmp公司，或任何数字协议标识符）

• 端口的源/目标间隔，例如0:65535

例如，当且仅当结束端口大于开始端口时，我们获得空匹配（不适用于任何数据包的匹配）。²⁶通过将接口设置为“+'，IP为0.0.0.0/0，端口为0:65535，协议为\（\mathsf{any}\）.²⁷

我们要求所有匹配条件都是格式良好的，即，如果协议是tcp、udp或sctp，则只允许在端口上进行匹配（universe 0:65535除外）。

使用这种匹配表达式，可以实现函数\（\mathsf｛conj｝\）它需要两个匹配表达式\（m_1\）和\（m2）并且只返回一个匹配表达式，该表达式是两者的合取。²⁸

定理10

（两个简单匹配表达式的连接）

计算端口间隔和单个协议的单个匹配表达式的结合非常简单。CIDR表示法中两个间隔的结合要么是空的，要么是两个间隔中较小的一个。如果两个接口不共享公共前缀，则它们的连接要么为空，否则它是两个接口中最长的接口（非通配符接口占通配符界面的主导地位）。

这个\（\mathsf｛conj｝\）两场精彩的比赛中，又一场精彩绝伦。²⁹

匹配表达式的类型经过精心设计，使得二匹配表达式仅为一匹配表达式。如果将功能添加到匹配表达式中，例如否定接口，则不再保证该属性。iptables防火墙规则集中最常见的功能[三]，我们只发现可以进一步向匹配表达式添加TCP标志，而不会违反前面提到的连接属性。一般考虑防火墙的常见特性[70]，可能会增强我们模型的ICMP支持。

一个优点是在图的语义上2它是一个简单的递归函数。此外，即保证终止。图的语义并非如此2，作为定理的假设三显示。因此，简单的防火墙使关于过滤行为的证明更容易，因为它们通常可以通过对规则集的列表归纳来完成。另一个优点是的函数是完全定义的，不再需要对任意但固定的函数进行推理\（伽玛射线）.

10转换为简单防火墙模型

第节中给出的语义。 4包含一个基本匹配器\（伽玛射线）它决定某个原语是否与数据包匹配。该模型及其上面的所有算法对于任意\（伽玛射线）因此，该模型支持全部的iptables匹配功能。显然，对于任意\（伽玛射线）然而，我们提供的转换规则集的算法是可执行的。为了对基元有一个清晰的语义，我们定义了\（伽玛射线），即简单防火墙支持的所有原语和其他一些原语，详见第节。 11。我们假设\（伽玛射线）在我们的子集上的行为与预期一致，但它可能显示所有其他原语的任意行为。我们说我们同意在\（伽玛射线）例如，\（伽玛射线）在IP地址上的行为与预期一致，但对于高炉给水泵匹配。

使用前面描述的算法，我们假设规则集已经展开，匹配表达式已经规范化。这会留下一个只发生以下操作的规则集：\（{\mathtt{Accept}}\）和\（｛\mathtt｛Drop｝｝\）.³⁰因此，将真实世界模型转换为简单防火墙模型的一大步已经完成。仍然需要翻译简单防火墙的匹配表达式。当然，不可能将所有基元都翻译成非常有限的模型，所以我们将利用\（\mathsf{pu}\）算法。为了举例说明，我们将只考虑本文以下部分中的过度近似；欠近似是类似的，可以在我们的形式化中找到。

由于防火墙通常接受属于已建立连接时，规则集中有趣的访问控制规则仅适用于新款小包。我们只考虑新款数据包，即。，\（{{-}{-}}{}\texttt{ctstate新}}\）和\（{{-}{-}}{}\texttt{syn}}\）用于TCP数据包。我们的第一个目标是将规则集从实际模型转换为简单模型。我们已经证明，简单防火墙所接受的新数据包集是真实世界模型所接受的数据包的超集（过近似）。³¹这是一个核心贡献，我们将在下一节详细介绍翻译。

定理11

（转换为简单防火墙模型）适用于\（伽玛射线）我们同意在

对于任意情况，经过翻译的、过于近似的简单防火墙规则集丢弃的任何数据包都会被真实防火墙丢弃\（伽玛射线）,\（\varGamma\）,\（个\）。通过考虑转换的欠近似，可以为明确接受的数据包提供类似的保证。鉴于模型中，编写算法来分析和验证翻译的规则集要容易得多。

例子。由于本文将更多地关注单个原语，我们将越来越多地使用更精确的语法iptables-save手册页也描述了这一点iptables（8）和iptables扩展（8）。我们认为向前地默认策略为的链\（\mathtt{Drop}\）和用户定义的链foo公司.

尽管这个规则集只包含三个规则和一个默认策略，但分析起来很复杂。我们的转换算法将其转换为简单的防火墙模型，其中的规则集变得非常简单。我们使用\（*\）表示通配符：

由于所有基本体都可以翻译，因此不会出现过近似或欠近似。请注意10.128.0.0/9地址范围，它是10.0.0.0/8与10.0.0.0/9求反的结果。

11转换基本体

在本节中，我们将介绍在不更改防火墙行为的情况下转换特定原语的算法。³²因此，接口、IP地址、协议和端口上的原语匹配将被规范化，以便转换为很明显。由于iptables支持200多个单独的匹配条件选项，我们无法涵盖所有选项。例如，我们不支持任何IPsec啊或专门用途英语匹配或业务流程图匹配，但我们只需使用我们的算法对其进行抽象\（\mathsf{pu}\）。但是，我们支持常见iptables规则集中最常见的功能。简单匹配，例如-秒或-d日已支持在源或目标IP地址上进行匹配. TheIP范围或多端口模块允许在IP地址和端口上进行匹配，但比支架。我们翻译它们时不会丢失信息，但会以增加规则集大小为代价。其他模块，例如连接跟踪状态或tcp协议标志不能在完全。然而，我们有时可以直接将其重写为\（{\mathsf{Any}}\）或\（\lnot\；｛\mathsf｛Any｝｝\）。我们继续描述在iptables规则集中发现的所有通用原语的规范化。

11.1IPv4地址

根据Nelson的说法[54]，“高效地对IP地址建模是一项挑战。”首先，我们提出了一种数据类型，可以有效地对机器字的间隔执行集合操作，例如32位整数。我们将对IPv4地址使用此类型，但我们已将其推广到任意长度的机器字，例如IPv6地址或第4层端口。为了简洁起见，我们将以IPv4为例介绍我们的形式化。我们称我们的数据类型为单词间隔(\（wi\）)、和\（\mathsf{WI}\start\end\）描述了（包含）间隔。这个\（\mathsf{Union}\）共两个\（wi\）s是递归定义的。

让\（\mathsf{set}\）将解释表示为数学集合，然后\（wi\）具有以下语义：

CIDR表示法中的IP地址或由例如。，\（｛-\texttt｛m iprange｝｝\）可以翻译为单个\（\mathsf｛WI｝\）值。我们已经实施并证明了常见的集合运算是正确的：”\（\杯\）’, ‘\（\lbrace\rbrace\）’, ‘\（\设置减号\）’, ‘\（\cap\）’, ‘\（\subseteq\）'、和'$=$”。这些操作在数量上是线性的\（\mathsf{Union}\）建造师。通过合并相邻间隔和重叠间隔并删除空间隔来优化结果。我们还可以代表“\（\mathsf{UNIV}\）'（所有IP地址的范围）。由于大多数规则集通常使用CIDR表示法或间隔中的IP地址\（wi\）数据类型已被证明是非常有效的。回想一下，根据CIDR表示法中的地址构造的两个间隔的交集要么是空的，要么是两个间隔中较小的一个。³³

数据类型\（wi\）是一个内部表示，对于简单防火墙，结果需要用CIDR表示法表示。对于这个方向\（\mathsf｛WI｝\）可能对应多个CIDR范围。我们描述了一种算法\（\mathsf｛split｝\）从任意字间隔中去掉一个CIDR范围第页输出为CIDR范围\（r^\prime\），分割此CIDR范围后的余数。\（\mathsf｛split｝\）实现如下：let\（a）是中最低的元素第页。如果不存在，则第页对应于空集，算法终止。否则，我们将构造CIDR范围列表[一 / 0, 一 / 1, ..., 一 / 32]. 列表中格式良好的第一个元素（即网络前缀后的所有位必须为零），它是第页是需要的元素。请注意，此元素始终存在。从中减去第页以获得\（r^\prime\）。要转换第页完全应用于CIDR范围的列表，这是递归应用的，直到它不再产生任何结果。此算法保证会终止，并且CIDR符号中的结果列表对应于如下所示的同一组IP地址第页.³⁴正式地，\（\bigcup\mathsf{map}\\mathsf}\set}\（\mathsf1{split}\r）=\mathsf2{set}\r\）.

例子。

在这些功能的帮助下，可以将任意IP地址范围转换为简单防火墙所需的格式。以下内容适用于源和目标IP地址上的匹配：首先，将IP匹配表达式转换为单词间隔。如果IP范围上的匹配被否定，我们计算\（\mathsf{UNIV}\setminus wi\）。使用\（\cap\）操作。生成的单词间隔被转换为一组非负CIDR范围。使用NNF规范化，CIDR表示法中的IP范围最多保留一个匹配项。我们已经证明，此过程保留了防火墙的过滤行为。

我们以一个简单的、人为的最坏情况作为结束。评估表明，这并不妨碍成功分析：\（-\texttt{miprange}{-}{-{}}\texttt}src-range0.0.0.1-255.255.}{}\texttt{255.254}\）转换为简单防火墙，此范围在CIDR表示法中最多可扩展到62个范围。对于负IP范围，可能会发生类似的放大。

请注意，虽然以点符号（即。，\（\texttt{<dotnum>}{}\texttt}：{：}=<snum>}}{\prime{\prime}}}.{\primer{\primes}}{}\texttt{<snum>}{\prime{\prime}}.}\prime}}\texttt{[75])简单、漂亮地打印IPv6地址非常简单[40]我们的实现包含了第一个经过正式机器验证的IPv6漂亮打印机[24].

11.2conntrack州

如果数据包第页根据有状态匹配条件进行匹配已建立conntrack抬头看了看第页在其状态表中。当防火墙做出过滤决定时第页，如果数据包未丢弃，并且状态为新款，conntrack状态表将被更新，以便第页现在已确定类似地，处理其他conntrack状态。

我们为这种行为提供了另一种模型：在防火墙开始处理规则集之前第页，将查询conntrack状态表以了解第页。此状态作为（幻影）标记添加到第页。因此，ctstate可以建模为第页处理规则集时，不需要检查conntrack表，只需要检查数据包的虚拟状态标记。处理后，相应地更新状态表。

我们已经证明，这两个模型彼此等价。³⁵由于conntrack状态可以被视为一个普通的数据包字段，因此后一种模型更易于分析。³⁶

在定理中11，我们只对新款小包。与我们的中间评估（第8)，不再需要手动排除已建立规则集中的规则。替代模型只允许我们考虑新款数据包：可以删除所有状态匹配（通过预先计算任意新款数据包），而不更改防火墙的过滤行为。

11.3第4层端口

将单个端口或端口间隔转换为简单防火墙是很简单的。否定端口范围和多端口模块。然而，单词间隔类型也适用于16位机器字，并解决了这些挑战。对于端口，无需将间隔转换回CIDR表示法。³⁷

在原始文件中[23]，我们犯了一个严重的错误[27]在端口上指定匹配的语义时。幸运的是，该错误仅在角落案例中出现，并不影响已发布的评估。然而，我们已经在野外看到了触发该错误的规则集，因此，它并不仅仅是学术性质的。由于我们已经证明了所有算法的正确性，并检查了所有假设，所以错误并不存在于代码中，而是存在于模型中。我们在本节中描述了问题及其解决方案（已经实施）。

我们定义了源端口匹配的数据类型，如下所示：

此数据类型将源端口匹配描述为16位端口号的间隔。数据包的匹配语义被定义为数据包的源端口必须在间隔内。例如，数据包第页比赛\（\mathsf{SrcPorts}\a\b\）当且仅当

。我们定义了\（\mathsf{DstPorts}\）类似地。有了这些语义，我们可以构造一个角案例来描述为什么这个模型不符合现实。考虑以下防火墙：

防火墙位于iptables-节约格式显示滤波器表，由两条链组成向前地和链条. The向前地链是内置的，默认策略为接受在这里。从向前地链，此防火墙处理的任何数据包都会直接发送到用户定义的链链条第一。一个数据包只能返回如果是源端口为22的TCP数据包或目标端口为80的UDP数据包。所有其他数据包都被丢弃。因此，此防火墙以复杂的方式表达了以下策略：“放弃所有不属于 tcp协议 源端口22或 udp（统一数据处理程序） 目的端口80“。虽然这个规则集没有明显的用途，但它是人为构建来演示我们的错误的。我们的工具以以下方式“简化”了规则集：

根据我们的语义，简化是正确的。实际上，由于各种原因，这个简单的防火墙是错误的。首先，它不是格式良好的，即它尝试在端口上进行匹配，而没有指定协议。其次，它混淆了UDP和TCP端口。

问题在于我们的语义\（\mathsf{SrcPorts}\）和\（\mathsf{DstPorts}\）粗略地说，没有所谓的“端口”，只有TCP端口、UDP端口、SCTP端口等。

我们通过在端口匹配中包含协议解决了此问题：

这个\（8字）对应于协议IPv4中的字段[68]，分别是下一包头IPv6中的字段[17]，通过分配的编号识别协议[72,73]. 它不允许使用通配符。语义定义了数据包的协议必须与数据类型中指定的协议相同，并且源端口必须在间隔中（如第一个定义中所示）。

使用正确的语义，我们的工具计算正确的预期结果：

端口上匹配的否定是一个有趣的角点情况，所提出的问题可以简化为。我们将用一个简单的例子来说明这个问题。假设我们有一个规则，它尝试接受每个不udp（统一数据处理程序）目标端口80。³⁸为了简单起见，我们假设有一个规则如下：! （-p udp--dport 80）-j接受。从语义上来说，为了展开这种否定，规则要么匹配所有不匹配的东西udp（统一数据处理程序）或其他一切udp（统一数据处理程序）但不是目标端口80。它可以用以下两个规则表示：-p udp-j接受然后-p udp--dport 80-j接受。我们在工具中使用此策略来展开端口上的否定匹配。请注意出现的类型依赖关系：否定一个与端口匹配的规则会产生一个与协议匹配的规则和一个与港口匹配的规则。

此示例还表明，任何将匹配条件减少为平面位向量的工具要么有缺陷（它会丢失属于端口匹配的协议），要么无法支持复杂的求反。这包括将防火墙分析减少到SAT的工具[39]或BDD[1,85]. 它可能也会影响ITVal[48]它依赖于多路决策图（MDD）。这也是我们的情况\（｛\varGamma，\gamma，p\vdash\big\langle-rs，\；s\big\langle\Rightarrow t｝\）有缺陷的语义\（伽玛射线）此处描述。我们的简单防火墙模型不允许复杂的否定，并且我们已经证明匹配条件总是格式良好的，因此，出现的错误类别不会在那里发生。

11.4TCP标志

iptables可以在一组第4层标志上进行匹配。要匹配标志\（掩码\）选择相应的标志并c（c）声明必须存在的标志。例如，匹配--同步是的同义词\（掩码=\mathtt{SYN，RST，ACK，FIN}\）和\（c=\mathtt{SYN}\）.对于一套（f）对于数据包中的标志，可以将匹配形式化为\（f\cap掩码=c\）.如果c（c）不是的子集\（掩码\），表达式不匹配；我们称之为空匹配项。我们证明了两场比赛\（（掩码_1，c_1）\）和\（（掩码2，c2）\）相等当且仅当\（（\mathbf{if}\c1\substeq mask_1\wedge c2\subsetq mask_2\\mathbf{then}\c1=c2\wedge mask_1=mask_2 \\mathbf}\（\lnot c1\ substeq-mask_1）\ wedge（\lnot-c2\subteq mask_2））持有。我们还证明了两个匹配的合取是\（（\mathbf{if}\c1\substeq mask_1\楔形c2\subsetq mask_2\楔形mask_1\cap mask_2\cap c1=mask_1 \cap mask_2\cap c2\mathbf{then}\（mask_1\scup mask_2，\，c1\cup c2）\\mathbf}\\else}\\mathtt{empty}）.如果我们假设--同步对于一个数据包，我们可以删除所有等于--同步并添加--同步匹配标志上的所有其他匹配项，并删除包含空匹配项的规则。标记上的某些匹配可能仍然存在，例如。，\（\mathtt｛URG｝\），需要稍后进行抽象。

11.5接口

简单的防火墙模型不支持否定接口，例如。，-我是+。因此，必须将其移除。我们首先激发了对否定接口进行抽象的需求。

对于白名单场景，人们可能会争辩说，使用否定接口构成了不良实践。这是因为新的（虚拟）接口可能会在运行时添加到系统中，而否定接口上的匹配现在也可能包括这些新接口。因此，被否定的接口对应于黑名单，这不建议用于大多数防火墙。然而，我们的模型不支持否定接口的主要原因是技术性的：\（\mathsf{set}\）表示与接口表达式匹配的接口集。例如，\（\mathsf{set}\{texttt{eth0}}=\lbrace{\texttt{eth2}}\rbrace\）和\（\mathsf{set}\{texttt{eth+}}\）是以前缀开头的所有接口的集合eth公司如果比赛开始\（{\texttt{eth+}}\）取反，则它匹配补码集中的所有字符串：\（\tathsf{UNIV}\setminus（\mathsf{set}\{\texttt{eth+}}）。简单的防火墙模型要求两个原语的连接最多只能是一个原语。这显然是用这样的设备无法实现的。此外，使用否定接口可能会引起很大的混淆。请注意，接口匹配条件'+'匹配任何接口。还要注意“+’\（\in\mathsf{UNIV}\setminus（\mathsf{set}\{\texttt{eth+}}））.这里，'+'不是通配符，而是接口的名称。当人们意识到这一点时，否定接口带来的混乱变得更加明显+'可以同时作为通配符和普通字符出现。因此，不可能构造与接口完全匹配的接口匹配条件+'，因为'+'在接口匹配条件的末尾被解释为通配符。³⁹虽然从技术上讲，Linux内核允许在“+'作为普通字符[46]iptables命令不允许构造这样的匹配[60].

11.6接口与IP范围的交互

后来，在门派。 12.1，我们将计算一个IP地址空间分区。为了更好地理解，该分区不应该被接口信息“污染”。因此，对于分区，我们将假定规则集中没有接口匹配。在本节中，我们描述了一种方法，可以删除否定接口和非否定接口，同时保留它们与IP地址范围的关系。

输入接口通常被分配一个有效源IP的IP范围，这些IP预计将到达该接口。让\（ipassmt\）是从接口到IP地址范围的映射。此信息可通过以下方式获得ip路由和ip地址。我们会写\（ipassmt[i]\）接口的相应IP范围我。对于以下示例，我们假设

目标是用相应的源IP范围重写输入接口。例如，我们希望替换所有出现的-i eth0具有-第10.8.0.0/16条。只有在没有欺骗数据包的情况下，这个想法才是正确的；我们只期望源IP为的数据包10.8.0.0/16到达eth0。一旦我们确定防火墙阻止了欺骗数据包，我们可以在第二步中假设没有任何欺骗的接受数据包。默认情况下，Linux内核提供反向路径过滤，自动阻止欺骗的数据包。在这种情况下，我们可以假设没有发生欺骗数据包。在一些复杂的场景中，需要禁用反向路径过滤，并应在防火墙规则集的帮助下手动阻止欺骗数据包。在以前的工作中[26]，我们提出了一种算法来验证规则集是否正确阻止欺骗数据包。该算法集成在我们的框架中，经过验证是合理的，工作原理相同\（ipassmt\），不需要简单的防火墙模型（即支持否定接口）。如果有接口我应接受任意IP地址（本质上不提供欺骗保护），可以设置\（ipassmt[i]=\mathsf{UNIV}\）因此，我们可以根据\（ipassmt\）在运行时和之后，继续假设没有发生欺骗数据包。

在假设没有发生欺骗数据包的情况下，我们现在将介绍两种关联输入接口的算法我到\（ipassmt[i]\）。这两种方法都适用于否定接口和非否定接口。第一种方法提供了更好的结果，但需要更强的假设（可以在运行时检查），而第二种方法可以在没有进一步假设的情况下应用。

第一种方法。一般来说，这被认为是不好的做法[82,83]具有跨区域接口。如果两个接口共享一个公共的重叠IP地址范围，则它们是跨区域的。数学上，缺少跨区域接口意味着对于\（ipassmt\），其分配的IP范围必须是不相交的。如果出现以下情况，我们的工具会发出警告\（ipassmt\）包含跨区域接口。如果未检测到跨区域接口，则所有输入接口都可以替换为其分配的源IP地址范围。这完全保留了防火墙的行为。在这种情况下，输入接口和源IP之间存在内射映射。有趣的是，我们的证明不需要假设\（ipassmt\）映射到完整的IP世界。

第二种方法。不幸的是，尽管被认为是不好的做法，但我们在许多实际配置中发现了跨区域接口，因此无法应用前面的算法。首先，我们证明了所述重写算法的正确性意味着不存在区域跨越接口。⁴⁰这导致了这样一个结论：如果没有这个假设，就不可能执行重写。因此，我们提出了一种将IP范围信息添加到规则集的算法（不删除接口匹配），从而将输入接口上的匹配限制为其IP范围。该算法计算以下内容：只要输入接口上有匹配项我，该算法查找该接口的相应IP范围并添加-秒\（ipassmt[i]\）遵守规则。为了证明该算法的正确性，不需要对跨区域接口进行假设，\（ipassmt\）只能为接口的子集定义\（ipassmt\）可能无法覆盖整个IP世界。因此，用户无需指定\（ipassmt\），但使用它可能会产生更准确的结果。

输出端口重写。我们提出的输入接口重写方法可以推广到也支持输出接口(-o个)正在重写。其核心思想是用由系统的路由表确定的相应IP地址范围来替换输出接口上的匹配。为此，我们解析路由表，将其映射到一个关系（它提供了一个独立于其顺序的结构），并计算关系的逆。这最终为每个接口及其相应的IP地址范围提供了映射。

此计算的映射与\（ipassmt\）事实上，我们发现将反向路由关系与\（ipassmt\）。为了方便起见，我们还提供了一个函数来计算\（ipassmt\）来自路由表。

本质上，从语义上计算反向路由关系与严格反向路径过滤中的行为相同[5]. 我们已经正式证明⁴¹这个观察结果。

表1真实防火墙评估摘要

由于路由表可能会频繁更改，甚至由外部恶意路由广告触发，因此默认情况下，我们不会在本工作中重写输出端口。通常，我们不会将其应用于评估（第14，表1)；然而，在一个案例中（第14，防火墙D），我们将进一步展示结果如何改进。

11.7对基本体进行抽象

某些基本体无法转换为简单模型。章节6.3已经提供了功能\（\mathsf{pu}\）这将删除所有未知的匹配条件。这导致了一个近似值，也是“\（\subseteq\）'定理中的关系11我们发现，我们也可以在任何时候将任何已知的原语重写为未知的原语。这可以用于在预处理期间应用附加知识。例如，由于我们了解标志，我们知道以下条件为假，因此可以删除使用它的规则：--同步 \（\楔形\） --tcp标记RST、ACK RST。在此优化之后，所有剩余的标志都可以被视为未知标志，并在以后进行抽象。这使得可以很容易地为进一步的基本匹配条件添加额外的知识和优化策略，而无需调整任何适用于简单防火墙模型的算法。我们证明了这种方法的合理性：\（\subseteq\）'定理中的关系11已保存。

12分析简单防火墙规则集

在本节中，我们将展示两种算法，它们适用于转换为模型。

12.1IP地址空间分区

我们提出了一种将IP地址的整个空间划分为等价类的算法。它在现实世界规则集的规则数量中大致以线性时间运行。同一分区中的所有IP地址在防火墙规则集中显示相同的行为。我们不要求分区是最小的。因此，以下是一个有效的解决方案：\（左\{左\{0\右\}，左\{1\右\}，点，左\}255.255.255.255右\}\右\{）然而，我们需要将分区作为进一步算法和大小分区的起点${2}^{32}$（对于IPv4）对于此目的而言太大。在IPv6的情况下，每个分区一个地址是不可行的。

首先，我们通过以下观察激发了分区算法的思想。对于任意数据包第页，我们写\（p（\mathtt{src}\mapsto s）\）将源IP地址修复为秒.

引理1

让X（X）是中指定的所有源IP匹配项的集合\（个\）即。，X（X）是一组CIDR范围。假设我们有一套B这样的话\（X中的所有A\）持有。那么，对于\（B\中的s_1）和\（B\中的s_2）,

反向读取引理，它表示从中选取的所有具有任意源IP的数据包B被防火墙平等对待。因此，B是IP地址范围分区的成员。施加的条件B对于规则集中匹配的所有源CIDR范围（称为A类在引理中），B要么是范围的子集，要么与之不相交。引理表明，对于B，因此我们将构造一个算法来计算B。对于任意集X（X），这种情况纯粹是集合理论，我们可以独立于防火墙理论来解决它。为了简单起见，我们可以互换使用有限集和列表。

算法\（\mathsf{partitions}\）结构如下。这个\（\mathsf{part}\）函数计算一个步骤并接受两个参数。第一个参数是一个集合\（X中的S），第二个参数\（TS\）是一组集合，对应于将被分区的其余集合。在第一次通话中，我们设置\（TS\）到\（\lbrace\mathsf｛UNIV｝\rbrace\）然后，我们反复打电话\（\mathsf{part}\）在中的所有元素上X（X）并贯穿结果，即。，

step函数\（\mathsf{part}\）其本身实现如下：对于固定S公司,\（\mathsf{part}\S\TS\）递归\（TS\）并分裂集合，使得引理的前提条件1持有。

调用的结果大小\（\mathsf{part}\）一次可以达到两倍的大小\（TS\）。这意味着完整防火墙规则集的分区大小的顺序为\（O（2^{\vert-rules\vert}）\）然而，经验评估表明，实际规则集的最终大小要好得多。虽然IP地址范围可能在规则集中重叠，但对于所有规则对来说，它们通常不会以最坏的方式重叠。因此，至少有一组\（大写字母T\）或\（T\设置减去S\）通常为空。例如，对于我们最大的防火墙，计算分区的数量是规则数量的10倍。我们的评估（表1第节。 14)确认分区数通常小于规则数。

我们的算法满足引理的假设1用于任意X（X）。因为IP地址在规则集中作为源和目的地出现，所以我们使用我们的分区算法，其中X（X）是在规则集中找到的所有IP的集合。结果是一个分区，对于同一分区中的任意两个IP，将任意数据包的源或目标设置为两个IP中的一个，防火墙的行为相同。这导致了更强版本的引理1，它在没有任何假设的情况下保持不变，同时也适用于源IP和目标IP。⁴²此外，分区覆盖了完整的IPv4（或IPv6）地址空间。⁴³

12.2服务矩阵

计算的IP地址空间分区可能不是最小的。这意味着两个不同的分区可能表现出完全相同的行为。因此，对于手动防火墙验证，这些分区可能会产生误导。马莫尔斯坦详细阐述了这个问题[49]. ITVal的解决方案是最小化分区。我们建议将分区最小化，但写入固定服务。评估表明，结果较小，因此更清晰。

固定服务对应于具有任意IP的固定数据包。例如，我们可以将SSH定义为TCP、目标端口22和任意但固定的源端口\（\页\）1024.服务矩阵描述了特定服务在整个IPv4（或IPv6）地址空间上允许的访问。它可以可视化为图形；例如，图6如图所示7图中显示了具有数千条规则的防火墙的服务矩阵示例8为了清楚起见，此图使用符号名称（例如。，\（服务器\）)而不是IP地址。原始IP地址如图所示9具有高度分散的IP范围的更复杂的示例如图所示10和11; 这些源于相同的防火墙安装，但在稍后的时间。所有矩阵都是最小的，即它们无法进一步压缩。

首先，我们描述了防火墙何时对任意源IP表现出相同的行为\（s1、s2\）和固定数据包第页:

我们说，如果目标IP的模拟条件成立，则防火墙对固定服务显示相同的行为。

我们呈现一个函数\（\mathsf{groupWIs}\），它计算固定服务的最小分区。其思想是从算法的输出开始\（\mathsf{partitions}\）并将其最小化。为此，将生成每个分区成员的入站和出站连接的完整方形访问控制矩阵。一个条目\（m{i，j}\）在这个矩阵中表示分区成员我允许与分区成员通信j个。详细来说，一个条目\（m{i，j}\）是一对布尔值，其中第一个元素表示我允许与中的所有IP地址通信j个第二个条目表示j个允许与中的所有IP地址通信我.计算所有条目\（m{i，j}\），该算法执行两次调用（一次用于源IP，另一次用于目标IP）对于每对分区成员。这可以通过将来自分区每个成员的任意代表作为源地址和目标地址并执行用于具有这些固定IP的固定数据包。通过合并具有相同行为的分区，即合并矩阵中的相等行，使矩阵最小化。该算法的分区数是二次的。早期评估[23]显示了它的伸缩性出奇地好，即使对于大型规则集也是如此，因为分区的数量通常很小。

算法是合理的，⁴⁴完成，⁴⁵并且产生最小的结果。⁴⁶因此，\（\mathsf{groupWIs}\）根据固定服务的简单防火墙规则集计算IP地址上的等价关系。因此，我们将输出集的成员称为\（\mathsf{groupWIs}\）等价类。任何IP地址都是其等价类的代表。

定理12

(\（\mathsf{groupWIs}\）声音和生成最小结果）对于任何等价类中的任意两个IP\（\mathsf{groupWIs}\），防火墙对固定服务显示相同的行为。

对于任意两个等价类A类和B在里面\（\mathsf{groupWIs}\），如果我们能在中找到两个IPA类和B分别在防火墙对固定服务显示相同行为的情况下\（A=B）.

提高绩效。我们假设规则集具有默认策略。否则，我们将回到以前的较慢算法。不过，任何简化的、格式良好的iptables规则集都有一个默认策略。⁴⁷上述算法执行对对于分区中的每对代表。对的调用次数为二次方，大大减慢了算法的速度。而不是重复执行对于作为源地址和目标地址的所有代表组合，对于固定服务和固定源地址，我们可以通过对规则集的一次迭代预先计算所有匹配的目标地址集。这同样适用于匹配的源地址。粗略估计，这将调用的二次数量减少到到规则集上的线性迭代次数。注意，渐近运行时仍然是二次的。我们已经实现了这个改进的算法，并证明了定理12和13经验性评估表明，这一改进带来了十倍的加速。

最终定理。服务矩阵是一个方阵，其中行数（对应列数）对应于由\（\mathsf{groupWIs}\）.条目\（m{i，j}\）在服务矩阵中应表示等价类中的所有IP地址我允许与等价类中的所有IP地址通信j个。此矩阵可能不是对称的，并且与中使用的内部表示不同\（\mathsf{groupWIs}\）到目前为止，定理12仅保证矩阵的布局（即行和列），但不保证矩阵的内容（即权限\（m{i，j}\）)具有所需的属性。此外，我们不想显示矩阵，但我们想将允许的访问可视化为图形，例如图7,8,9,10,11，或12由于服务矩阵是一个正方形矩阵，因此可以将其视为邻接矩阵，从而将其可视化为图\（\mathsf{groupWIs}\）只计算图的节点。

绘制图形，例如使用TikZ[77]或Graphviz，⁴⁸首先需要打印节点，然后打印边缘。不应打印节点（代表）的名称，而应打印它们实际代表的IP范围（等价类）。例如，图7可定义如下：

在本例中，节点名称一,b条、和c（c）是在语义上对应于其标签所描述的IP地址集的标识符。例如，一表示范围为131.159.21.0到131.159.2.255的等价类。例如，坐标(-4,-4)对于节点一与我们的担忧无关。边缘意味着其代表参考的完整IP范围可以进行通信，例如：。，

（a） 至（b）意味着整套131.159.21.0/24可以与131.159.15.240/28建立连接。在最终图纸中，标识符一,b条、和c（c）未显示，但仅显示其相应的IP范围。

一张图表\（（V，\，E）\）由一组顶点组成V（V）和一组边\（E \ substeq V \ times V \）。在我们的场景中，我们有一张地图\（{V}\）其中键是标识符(一,b条,c（c）, ...) 映射到其等价类（IP地址集）。我们选择了V（V）成为…的领域\（{V}\）.方便地将\（{V}\）就是宇宙。我们计算\（{V}\）通过呼叫\（\mathsf{groupWIs}\）并为每个等价类选择一个代表（例如，取最低的IP地址）。我们计算E类通过呼叫每对\（V\乘以V\）。请注意V（V）最小化，经验评估表明不是性能问题。为了方便起见，我们打印了符号标识符一,b条,c（c）, ...对于的键\（{V}\）而不是IP地址。我们给出了最后一个定理，证明了根据我们的方法绘制的图的正确性。⁴⁹

定理13

（服务矩阵）让\（（{V}，\，E）\）成为服务矩阵。然后，

定理如下：对于固定连接，可以查找IP地址（源秒和目的地d日pairs）当且仅当防火墙接受时(秒, d日)固定连接的IP地址对。

使形式化复杂化的部分是“在图中查找IP地址”的概念。查找源IP地址秒在图中，一个首先定位秒作为其中一个IP等价类的成员，此处\（s\mathrm{范围}\）。此等价类由代表表示\（s\mathrm{repr}\）。同样的操作可以获得\（d\mathrm{repr}\）定理现在说\（E中的（（s_\mathrm{repr}，；d_\mathrm{repr{））当且仅当防火墙允许来自秒到d日。if-and-only-if关系与存在量词结合在一起也意味着我们总是可以找到一个等价类秒和d日，这意味着我们的图始终包含IP地址空间的完整且不相交的表示。

13独立Haskell工具fffuu（飞行功能单位）

我们使用了Isabelle的代码生成功能[34,35]在Haskell中构建独立工具。由于所有分析和转换算法都是用Isabelle编写的，所以我们只需要添加解析器和用户界面。总的来说，80%以上的代码是由Isabelle生成的，这让我们对该工具产生了强烈的信任。

我们称之为工具fffuu（飞行功能单位），“（f）耐久性（f）正常（f）爱尔兰单位无处不在单位“Understander”。

fffuu（飞行功能单位）只需要一个参数即可运行，即iptables-save转储。这使得它非常有用。也可以通过ipassmt公司，更改桌子或链它被加载，传递一个用于输出端口重写的路由表，或者为服务矩阵选择服务。

fffuu（飞行功能单位）可以使用从源代码轻松编译堆栈,⁵⁰这确保了可再生建筑在未来的良好发展。

例子。我们展示fffuu（飞行功能单位）通过一个小例子。我们想推断图中所示规则集背后的意图6。虽然此规则集是人为创建的，用于演示某些角落情况，但它是基于真实防火墙的实际规则[三,16]. 还要注意接口名称

带有UTF-8符号和shell转义的颜色[53]完全有效。

图6

示例规则集。（在线彩图）

图7

图中规则集的服务矩阵6

很难猜测规则集正在实现什么。我们将规则集加载到fffuu（飞行功能单位），不需要任何附加参数或手动步骤来计算。生成的服务矩阵（对于任意端口）如图所示7并深入了解规则集的意图。从一个IP范围到另一个IP区域的箭头表示第一个范围可以与第二个范围建立连接。

在底部，我们看到localhost范围为127.0.0.0/8。反身箭头（localhost到localhosd）表明防火墙不会阻止其自身的localhost-traffic，这通常是一个好迹象。然而，localhost/traffic通常对防火墙分析不感兴趣，因为此范围通常不会路由[15]. 从现在起，我们将忽略它。

在顶部，在云中，我们可以看到一大组IP地址。这与互联网相对应。在左边，我们可以看到131.159.21.0/24的范围。它可以访问互联网和131.159.15.240/28范围。在右边，我们看到的是131.159.15.240/28范围，它只能访问互联网，但不能访问131.159.21.0/24范围。

仔细看这个图，我们可能会认识到整体架构：防火墙实现了“非军事区”（DMZ）架构模式。这通常可以描述为分为两部分的本地网络；可以从外部Internet访问的公共服务（需要从外部访问的托管服务，例如邮件或web服务器）和只能连接到Internet但不能反向连接的内部服务。为了缓解公共网段中某些主机受到威胁的情况，防火墙还禁止从公共网段连接到内部网段。从原始文件开始iptables-save输入，无需fffuu（飞行功能单位），很难发现和验证此架构。

14评价

我们从超过15个防火墙中获得了真实世界的规则集。有些是对生产至关重要的核心设备。它们由不同的作者撰写，利用了大量不同的特点，展现了不同的风格和模式。我们发布完整的规则集是一个重要贡献（参见Wool[82,84]). 据我们所知，这是真实世界中最大的、公开可用的iptables规则集集合。注意：一些管理员希望保持匿名，因此我们将他们的公共IP地址替换为我们机构的公共IP范围，从而保留所有IP子集关系。

表1总结评估结果。第一列（“Fw”）标记所分析的规则集。第2列（“规则”）包含iptables-save。我们直接处理这些真实世界的数据集。第3列描述了所分析的链。根据防火墙的类型，我们要么分析向前地（“FW”）或INPUT（输入）（“IN”）链。对于主机防火墙，我们分析了IN；对于网络防火墙，例如网关或路由器上的防火墙，我们分析了FW。在括号中，我们写下展开分析链后的规则数。展开还具有一些通用的、直接的优化，例如删除匹配表达式所在的规则\（\lnot\，{\mathsf{Any}}{}\）第4列（“简单规则”）是转换为简单防火墙时的规则数。在括号中，我们写下了删除接口时简单防火墙规则的数量。该规则集随后用于计算分区和服务矩阵。在第5列（“使用”）中，我们标记翻译后的简单防火墙是否有用。稍后我们将详细介绍指标。第6列（“部件”）列出了IP地址空间分区的数量。为了进行比较，我们在括号中给出了ITVal计算的分区数。在第7列和第8列中，我们给出了SSH和HTTP的服务矩阵的分区数。在第9列（“时间（ITVal）”）中，为了进行比较，我们将ITVal分区的运行时间放在括号中，用秒、分钟或小时表示。在第10列（“时间（这个）”）中，我们给出了分析的总体运行时间。

在转换为简单防火墙时，为了实现对任意匹配原语的支持，需要执行一些近似。对于每个防火墙，第一行表示过度近似（更宽松），第二行表示欠近似（更严格）。

与中间评估相比，不再需要手动从分析中排除某些规则（参见第6.4). 对于某些规则集，我们不知道接口配置。对于其他人来说，存在跨区域接口。基于这些原因，正如第。 11.6在大多数情况下，我们无法重写接口。这是过度近似和不足近似之间存在差异的原因之一。

我们使用iptables-res撕下这验证了我们的结果是正确的。然后，我们直接使用iptables生成ITVal所需的防火墙格式(iptables-L-n). 我们需要将其转换为简单防火墙，因为ITVal无法理解原始的复杂规则集，并为其生成有缺陷的结果。

性能。我们有两种执行算法的可能性，这取决于用户是想在Isabelle内部运行它们，还是想作为外部独立应用程序运行它们[34].

在我们的评估中，我们使用了Isabelle的代码反射功能。本质上，它为我们提供了一种执行算法的方法，就像它们是用Isabelle的实现语言（Standard ML）实现的一样。Isabelle的代码生成器为许多编程语言的标准库中已经存在的数据结构引入了自己的未优化版本。因此，生成的代码可能效率很低。⁵¹例如，与标准库实现的恒定查找时间相比，Isabelle生成的字典中的查找具有线性查找时间。相反，ITVal是高度优化的C++代码。我们在一台具有2个物理内核和8 GB RAM的i7-2620M笔记本电脑上测试了我们的工具。相比之下，我们在一台具有16个物理Xeon E5-2650内核和128 GB RAM的服务器上执行了ITVal。我们的工具的运行时间是两个简单防火墙、分区计算和两个服务矩阵的完整转换。相反，ITVal的运行时只包含计算一个分区。我们工具的报告时间还包括Isabelle代码生成器的运行时间，但对于ITVal，我们没有添加其编译时间。这是ITVal在运行时间<1分钟时优于我们的工具的原因之一。

这些基准设置对我们的工具有偏见。事实上，将我们的工具导出到一个独立的Haskell应用程序，用Haskell-标准库中的优化数据结构替换一些通用数据结构，实现积极的编译器优化和并行化，不计算编译时间，并在Xeon服务器上运行我们的工具，我们的工具的运行时间提高了几个数量级。我们的独立工具fffuu（飞行功能单位）还可以实现数量级的更好运行时。然而，我们选择了“不公平”的设置来证明直接在定理证明器中运行验证代码的可行性。

表1表明我们的工具在大型防火墙方面优于ITVal。如果ITVal的内存需求超过20GB，我们将其添加到表中。ITVal需要大量内存来存储更大的规则集，而我们的工具可以在商品硬件上完成。总体数字表明，我们的工具的运行时足以进行静态离线分析，即使是大型实词规则集也是如此。

为了日常使用和方便，我们使用Haskell工具fffuu（飞行功能单位）这给我们的表中的数字增加了另一个数量级的加速1.

结果质量。ITVal的主要目标是计算最小的分区，而我们的分区可能不是最小的。分区数量越少越好，因为结果越容易监督。可以看出，ITVal比我们在第6列中的方法提供了更好的结果。由于服务矩阵比分区更具体，因此服务矩阵（第7列和第8列）的分区可以更小。我们的服务矩阵可以证明是最小的，因此改进了ITVal的分区。由于分区不能小于服务矩阵，因此第6列中的数字必须大于或等于第7列或第8列中的数值。对于防火墙A类和R（右）可以看出，ITVals的结果是虚假的，而我们的结果是可以证明的正确的。通常，如果ITVal计算的分区数小于服务矩阵的分区数，则这是ITVal中的错误。

在第5列中，我们展示了翻译后的简单防火墙（包括接口）的用处。如果近似值保留了有趣的信息，我们认为防火墙很有用。因此，我们手动检查了规则集并将其与原始规则进行了比较。对于过于接近，我们专注于保留（非阴影）\（｛\mathtt｛Drop｝｝\）规则。对于欠近似，我们重点关注保留（非阴影）\（{\mathtt{Accept}}\）规则。如果防火墙在开始时对所有数据包都提供了某种速率限制，那么这种欠近似自然是一种全下拉规则集，因为速率限制可以应用于所有数据包。根据我们的标准，这样的规则集是没有用的（但唯一可靠的解决方案）。我们用上标表示这种情况^第页。该表表明，通常每个防火墙至少有一个近似值是有用的。

图8

实验室SSH服务矩阵（2015）

为了简单起见，我们只详细介绍了最有趣的规则集及其分析结果。

防火墙A。此防火墙是我们实验室（网络架构和服务主席）的核心防火墙。它有两个上行链路，互连几个VLAN，并在20多个接口上进行匹配。它有大约500个直接用户和一个用于后面自治系统（AS）的传输网络。流量通常为数Mbit/s。我们分析了2013年10月、2014年9月、2015年5月和2015年9月的转储。不断变化的规则数表示它处于活动管理状态。

防火墙从一些速率限制规则开始。因此，其更严格的近似假设是速率限制始终适用，并将规则集转换为拒绝所有规则集。更宽松的近似对这种速率限制进行了抽象，并提供了对原始规则集的非常好的近似。

SSH服务矩阵如图所示8和图9使用原始IP地址。该图如下所示：我们的绝大多数IP地址被分组为内部的和服务器。可以从外部访问服务器，但无法从内部主机访问。\（ip _1\）和\（ip 2\）是两个单独的IP地址，但有特殊例外。还有一组用于连接的AS的主干路由器。INET是一组不属于我们的IP地址，基本上是Internet。INET是互联网的另一部分。在服务矩阵的帮助下，管理员确认INET的存在是由过时规则引起的错误。错误配置已修复。图8总结了4000多条防火墙规则，有助于轻松直观地验证防火墙的复杂SSH设置。管理员还对Kerberos（Kerberos-adm）和LDAP服务矩阵感兴趣。他们帮助验证了复杂的设置，并发现了清除规则集的潜力。

图9

带有原始IP地址的实验室SSH服务矩阵（2015年）

图10

实验室IPv4 HTTP服务矩阵（2016）

图11

实验室IPv6 HTTP服务矩阵（2016）

我们使用了fffuu（飞行功能单位）工具进一步分析我们的防火墙。例如，图10（IPv4）和11（IPv6）是根据2016年6月的最新快照创建的，描述了HTTP的服务矩阵。表中未列出此快照。这些数字显示了原始IP地址。可以看出，“两个INET”错误已经修复，但防火墙的整体复杂性增加了。请注意，服务矩阵是最小的，即无法进一步压缩它。这两个数字揭示了此防火墙的内在复杂性。然而，尽管这些数字很复杂，但仍然可以在一页上看到。对于实际规则集的数千条规则来说，这是不可能的。它证明了我们的服务矩阵可以对复杂的规则集进行适当的概述。

防火墙D。该防火墙取自Shorewall系统，有373条规则和65条链。可以看出，展开增加了规则的数量，因为用户定义的链生成了复杂的调用结构。转换为简单防火墙进一步增加了规则集的大小。除其他原因外，这是由于将几个否定的IP匹配重写回非否定的CIDR范围和NNF规范化。然而，绝对数字告诉我们，这种爆炸对计算机分析来说没有问题。

大致来说，防火墙将接口相互连接，即它大量使用-我和-o个这很容易在过度逼近中看到。还有许多跨区域接口。正如我们已经证明的那样，在这种情况下重写接口是不可能的。此外，对于某些接口，没有指定IP范围。因此，与网络层防火墙相比，此规则集更像是链路层防火墙。因此，服务矩阵几乎没有任何用处。

稍后，在获得了更详细的接口和路由配置后，我们再次尝试重写输入和输出端口。结果未显示在表中，但如图所示12。该图现在正确总结了防火墙实施的网络体系结构。它显示了通用互联网、Debian更新服务器（141.76.2.4）和四个具有不同访问权限的内部网络。

图12

带输入和输出端口重写的防火墙D SSH服务矩阵

防火墙E。此规则集取自引言中的NAS设备（图1). 规则集首先执行一些速率限制。因此，欠近似对应于拒绝所有规则集。该表列出了系统更新后规则集的最新版本。我们的SSH服务矩阵揭示了一个错误配置：SSH在更新后意外地保持启用状态。在这一发现之后，缺陷得到了修复。NAS提供的其他服务的服务矩阵（表中未列出）验证了这些服务只能从本地网络访问。这最终产生了引言中提到的预期结果。

防火墙F。此防火墙正在可公开访问的服务器上运行。防火墙首先允许本地主机的一切，然后阻止过去显示恶意行为的IP地址，最后允许某些服务。由于大多数规则都用于阻止恶意IP，因此我们的IP地址空间分区大致随规则数量线性增长。然而，服务矩阵显示，实际上只有三类IP范围：本地主机、被阻止的IP以及被授予访问服务的所有其他IP。

防火墙G。对于此生产服务器，服务矩阵验证了SQL守护进程只能从本地网络和三个明确定义的公共IP地址进行访问。我们的工具可以验证管理员是否正确配置了防火墙。

防火墙H。2003年的此规则集似乎阻止了工作时间内的Kazaa文件共享流量。此外，规则会删除字符串为“X-Kazaa-User”的所有数据包。更宽容的抽象正确地告诉防火墙可以接受所有IP的所有数据包（如果上述条件不成立）。因此，防火墙本质上被抽象为一个allow-all规则集。根据我们的衡量标准，这些信息没有用处。然而，在这种情况下，此信息可能会揭示规则集中的错误：防火墙明确允许某些IP范围，但默认策略是\（{\mathtt{Accept}}\）并包括所有这些先前明确允许的范围。通过检查防火墙的结构，我们怀疑默认策略应该是\（｛\mathtt｛Drop｝｝\）。这种可能的错误配置被过度近似所发现。

近似不足一开始无法理解“X-Kazaa-User”上的字符串匹配，因此对应于拒绝所有规则集。然而，手动检查近似不足仍然会发现一个有趣的错误：规则集还试图防止某些硬编码MAC/IP对的MAC地址欺骗。然而，我们在近似值不足的情况下看不到任何欺骗MAC地址的丢弃规则。事实上，规则集允许非冒充数据包，但忘记丢弃冒充的数据包。此防火墙演示了我们近似的最坏情况：一组接受的数据包是宇宙，另一组是空数据包。但是，由于这个规则集被严重破坏，因此不可能有更好的近似值。然而，手动检查简化规则集有助于发现几个错误。这表明，即使服务矩阵不包含任何信息，我们工具的其他输出可能仍然包含有趣的信息。

防火墙P。这是一家中型公司主防火墙的规则集。管理员问我们他们的规则集在做什么。他们没有透露他们的意图，以防止分析结果偏向预期结果。

我们计算了简化的防火墙规则和服务矩阵。使用欠近似，我们还可以保证防火墙绝对允许的数据包。管理员严格检查了我们工具的输出。最后，他们确认防火墙完全按照预期工作。这表明：不仅发现错误，而且显示正确性是我们工具的关键优势之一。

经过分析，管理员揭示了他们的真实意图。他们之前已经将该系统升级为iptables。他们的用户（公司的员工）意识到了这一点。他们收到了一些关于连接问题的投诉，员工们指责防火墙。然而，管理员怀疑连接问题是由一些违反公司政策的用户触发的，例如共享用户帐户。在我们分析的帮助下，管理员可以拒绝所有关于其防火墙配置的指控，并跟踪他们最初对行为不端员工的怀疑。

几个月后，我们收到的反馈是，防火墙很完美，“用户很愚蠢”。

图13

带有Docker主机状态的HTTP服务矩阵

防火墙R。此规则集是从Docker主机中提取的，部分由地形S[21]. 对于远程管理，规则集允许对所有机器进行无约束的SSH访问，这可以从SSH服务矩阵仅显示一个分区的事实中看出。相反，对HTTP强制执行高级设置，HTTP矩阵如图所示13。能够验证公开的HTTP设置，同时忽略SSH维护设置，这说明了计算每个服务的访问矩阵的优势。我们扩展了fffuu（飞行功能单位）还显示可以位于已建立状态。这是由一条橙色虚线显示的。由于特定场景的特殊要求，我们可以看到10.0.0.2是一个真正的信息汇，甚至可能无法满足已建立连接。较低的闭包还展示了一个有趣的细节：除了一个受速率限制的主机外，SSH连接得到了保证。具有讽刺意味的是，ITVal对原始规则集执行分段错误。通过我们的处理，它成功地终止了，但返回了一个虚假的结果。

15Outlook:验证OpenFlow规则

OpenFlow（开放流）[64,67]是配置启用OpenFlow的交换机的标准。它通常在软件定义网络（SDN）的上下文中被提及，近10年来一直是网络管理和操作中的热门话题。

本文重点分析了iptables而不是OpenFlow，原因如下：尽管OpenFlow 1.0[67]它已经上市5年多了，是一种相对年轻且传播范围不大的产品。相比之下，iptables经过了实战测试，得到了现实世界的认可，支持大量功能，并且已经投入生产使用超过十年。还有使用大量功能的十年前的配置，管理员不再完全理解这些功能[三]. 截至2016年7月，流行的系统和网络问答网站服务器故障⁵²与iptables相关的问题数量是OpenFlow的100多倍。相关的超级用户⁵³该网站上与iptables相关的问题数量甚至比OpenFlow多1000倍。

多年来，iptables已经发展成为一个拥有大量（遗留）功能的系统。与此相比，OpenFlow是一项整洁的技术。但考虑到Nicira扩展等因素，我们预计未来几年会出现类似的功能蔓延[61]或尝试使用通用FPGA增强OpenFlow以添加“奇异功能”[12]. 在更广泛的背景下，通过扩展OpenFlow或其提议的有状态、功能更丰富的继承者之一[7]，许多iptables功能已经在其之上重新实现[65].

我们宣布的目标是提供科学方法来理解具有挑战性的配置（如iptables中所观察到的），并在复杂的、真实的、传统增长的系统上评估我们的方法。我们获得的见解也可以应用于OpenFlow。特别是，本文的大部分内容都集中在匹配条件上，例如，对未知内容进行抽象、优化、重写、规范化，甚至用IP地址替换接口。我们在匹配条件方面的工作可以在OpenFlow上下文中的未来工作中直接重用。

然而，iptables不是OpenFlow。特别是，OpenFlow标准定义了可以为数据包执行的大量操作。相比之下，iptables过滤主要使用两个操作\（\mathtt{Accept}\）和\（\mathtt{Drop}\）这是因为防火墙将过滤与其他网络功能（如数据包重写）完全分离。OpenFlow实现倾向于混合使用这些功能。我们已经展示了如何处理未知匹配条件，但未知操作是一个尚未解决的问题。我们讨论了完整的OpenFlow语义需要什么。特别是可变数据包模型（参见第4.2)将是必要的，而我们的方法不支持这一点。然而，OpenFlow交换机在技术上不需要将包过滤与其他操作混合。例如，Nelson等人构建的流水线OpenFlow路由器体系结构。[57，第节。3，图3]清楚地将包过滤与包转发和重写分开。通常，使用最新OpenFlow标准中指定的管道处理[64]这可能是将过滤与转发和重写分离开来的一个进步。这也可能有助于编译器生成OpenFlow规则，并遭受由多个表的叉积引起的大规模放大，从而将不同操作的规则连接到一个表中[76]. 这种由OpenFlow规则实现的过滤表没有未指定的行为，可以用我们提出的方法进行分析。

与防火墙规则相反，OpenFlow流表条目通常不是手工编写的，而是高级编程语言（如NetCore[52]，净KAT[4]，或流量日志[56])可以使用。总的问题是，是否有必要分析低级OpenFlow规则，因为例如，存在从NetCore到OpenFlow的经过验证的编译器[33]. 因此，对高级编程语言的分析和验证可能比对生成的低级OpenFlow条目的分析更有趣。Flowlog语言的设计特别考虑了内置的验证和分析[55,58]NetKAT被明确设计为带有测试的Kleene代数（KAT），适用于形式分析，并且具有自动决策过程[30].

16结论

这项工作的动机是，我们找不到任何工具来帮助我们分析实验室和其他防火墙规则集。尽管存在许多关于防火墙分析的相关工作，但所有学术防火墙模型都过于简单，无法适用于这些现实世界的规则集。通过本文中介绍的转换，它们可以通过现有的工具进行处理。

我们已经演示了第一个经过充分验证的、适用于防火墙规则集的实际分析框架。我们的工具fffuu（飞行功能单位）支持Linux iptables防火墙，因为它因其丰富的功能而被广泛使用和熟知。它直接作用于iptables-save输出。我们提出了一个关于常见匹配条件的代数，以及一种将复杂条件转换为简单条件的方法。进一步的匹配条件（未知或无法转换）以合理的方式近似。这就产生了将复杂的现实世界规则集转换为简单模型的方法。评估表明，尽管可能存在近似值，但简化规则集保留了原始规则集的有趣方面。

基于简化模型，我们提出了划分IPv4和IPv6地址空间和计算服务矩阵的算法。这允许以明确的方式总结和验证防火墙。

该分析在伊莎贝尔定理证明器中得到了充分的实现。管理员不需要额外的数学输入或知识。

该评估证明了它在许多实际规则集上的适用性。为此，据我们所知，我们收集并发布了学术界最大的真实世界iptables规则集集合。我们证明了我们的方法在正确性、支持的匹配条件、CPU时间和内存需求方面可以优于现有工具。我们的工具有助于验证是否缺少错误，或者在实际生产规则集中发现以前未知的错误。

17可利用性

我们的Isabelle/HOL理论文件以及形式化和引用的正确性证明和我们的工具fffuu（飞行功能单位）可在

https://github.com/diekmann/Iptables_Shemantics网站

它是第一个经过完全机器验证的iptables分析工具。理论文件的稳定版本也可以从“正式证据档案”（AFP）中获得[19,22,24,51]. AFP维护政策确保我们的正式化将继续与更新的Isabelle版本一起工作。

分析的防火墙规则集的原始数据可以在以下位置找到：

https://github.com/diekmann/net-network

据我们所知，这是真实世界中最大的、公开可用的iptables防火墙规则集集合。