checkpoint防火墙状态表

了解Check Point FW-1状态表

作者：Lance Spitzner)

整理：warning3)

主页：

日期：2000-08-15

<* 译者：以前关于防火墙状态表，也只是有一个大概的了解，通过看这篇文章，也纠正了一些自己的错误看法，感觉很有收获，因此就把它翻译出来了。由于时间仓促，可能些地方翻的会有问题，如发现错误，请跟我联系。

这篇文章的主要目的是帮助你了解FW-1的状态连接表是如何工作的。这张表使FW-1知道谁在做什么，什么连接时是允许通过的...这篇文章是我对最新的FW-1 版研究的一个继续。为了使你更好的理解你自己的FW-1状态检查表并与我所说的进行验证，我将这篇文章中所用到的源码附在最后。

状态检查(Stateful Inspection )

==============================

让我们首先从一个很基本的问题开始我们的讨论。假设你有一个防火墙，它的过滤规则允许所有连接通过(any - any -accept),那么防火墙是否会允许一个用ACK位发起的新TCP连接通过呢如果防火墙允许任何连接通过，那么似乎任意的包都应当通过。然而，如果从状态检查的工作原理上看，这个包又似乎应当被丢弃。

我开始对状态检查(至少是对Check Point FireWall-1)的理解是这样的：

当防火墙收到一个发起TCP连接请求的SYN包时，这个SYN包首先会与防火墙的过滤规则按顺序(从规则0开始)进行比较，如果所有的规则都不允许接受这个包，那它就被拒绝，这个连接就被丢弃或者拒绝(发送RST包给远程主机).然而，如果这个包被接受了，这个连接会话就被加入到防火墙的状态连接表中，这个表在内核空间中分配。后续的每个包(不带SYN标记的包)都会与状态表比较，如果相应的会话已经在表中了，那个这个包就是连接会话的一部分，然后这个包就被接受，允许通过。如果不是，这个包就被丢弃。这将

改进系统性能，因为不需要将每个包都与过滤规则集进行比较，而是只对发起连接的SYN包进行比较。所有其它的TCP包都在内核空间中与状态表进行比较，这个速度是很快的。

好，现在回到我们开始谈的那个问题上来。如果我们用一个ACK包发起一个会话，防火墙是否会接受这个包呢，即使过滤规则已经允许所有的连接通过就象我们刚才说的，你可能认为会接受。但现在我们对状态连接表有了更多的认识，可能这个答案会是相反的了。当防火墙收到一个ACK包时，它会先与内核空间中的状态连接表进行比较，而不是过滤规则集。当然防火墙的状态连接表中没有相应的会话记录，因为并没有一个SYN包发起过连接。那么，到底防火墙会不会接受这个包呢？

答案- FW-1如何建立一个连接

============================

答案是令人吃惊的。不仅这个ACK包被接受，它还会被加入到状态表中！我对防火墙状态表的理解并不正确。我所发现的结果是，当防火墙收到一个不在状态表中的包时，它会先与过滤规则进行比较，不管这个包是SYN,ACK或者是其他的什么包。如果过滤规则允许接受这个会话，那么这个会话就被加入到状态连接表中去。这个连接会话的所有后续包都会与状态表进行比较，既然在状态连接表中已经存在了相应的会话，因此这些包就被接受而不再与过滤规则集进行比较。将'fw tab -t connections'得到的结果进行

转化，我们得到下面的输出结果：

注意：下面看到的这些是我的状态连接表中那些使用ACK包发起的连接。

mozart #fwtable

---- FW-1 CONNECTIONS TABLE ---

Src_IP Src_Prt Dst_IP Dst_Prt IP_prot Kbuf Type Flags Timeout

10003 25 6 0 16385 02ffff00 2845/3600

10002 24 6 0 16385 02ffff00 2845/3600

10001 23 6 0 16385 02ffff00 2845/3600

我们可以看到这三个包都被接受并被加入到防火墙状态表中，但它们都是使用用ACK包发起的连接。同样，对于Null,SYN/ACK,FIN/ACK 等类型的包也会被接受。

当你使用'ftstop;fwstart'重新启动防火墙时，过程连接表会被清空。如果有并发连接发送ACK包，防火墙看到这些包时，会检查它们是不是符合过滤规则，并重建连接表。所有这些操作对终端用户都是透明的。这就是你为什么那些加密认证的会话连接会中断，因为防火墙没有这些连接的"初始状态"。同时应当注意的时，对于非SYN包连接缺省连接超时是3600秒，这意味着，你可以将这个会话在连接表中保存60分钟的时间直至超时。这个超时时间可以在控制属性菜单里面调整。

注意：有效的FIN或者RST包并不会建立一个会话，因为它们被用来中断一个连接。另外，唯一不会被增加到状态表中去的是'Xmas'包，可以用Fyodor的nmap(-sX开关)来产生。然而这些包会被接受并被记录。

这里我了解到的另外一点是，FW-1的状态检查只根据源/目的IP和端口来判断是不是一个会话。它不管序列号，因为我制造了很多不同的序列号，防火墙都认为是一个会话而接受了。当建立连接的时候，FW-1也不维护包类型的状态。当你发送一个SYN包初始化一个会话时，防火墙先与过滤规则集进行比较，如果被接受，就将这个会话增加到状态表中，就象我们前面讨论的那样。这时候，超时时

间被设置成60秒。防火墙会等候一个返回包来建立连接。当它看到一个返回包时，超时被设置成3600秒(60分钟).然而防火墙并不在乎返回什么类型的包。我使用SYN发起一个连接，然后只发回一个ACK包，防火墙就将这个包作为连接的一部分接受了（因为IP和端口是匹配的).因此，防火墙并没有智能到能够知道必须返回SYN/ACK的应答包，也不在乎序列号。要维护序列号等状态需要更多的系统资源，可能是为了提高系统性能才这么做的吧。

拒绝服务攻击(Bugtraq ID 549)：当建立一个连接的时候，如果你使用ACK(或者其他的非SYN包,象Null,FIN/ACK,SYN/ACK等等)来发起连接，连接超时自动被设置成3600秒。这暗示着存在以拒绝服务攻击的可能。既然远程系统并不存在，它们就不会发送RST或者FIN包来中断连接，这将在连接表中留下一个"死"连接，这个死连接会存在一个小时的时间。通过发送大量ACK包连接包给并不存在的系统，你可以迅速地填满防火墙的连接表。幸运的是，从防火墙外部发动这种攻击比从内部要困难的多。但是，如果你从防火墙后面往外进行扫描时，很容易造对自己的DoS攻击。Check Point对这个问题发表了提供了一个解决方法，

你可以按照下列步骤来解决这个问题：

. Check Point已经提供了一个用状态检查的解决方案，但重新装载过滤策略时可能会影响状态表的功能

. 减少TCP超时时间到15分钟(900秒)。这将减少攻击者填满你的连接表的机会

. 增大你的连接表。这使填满连接表变得更为困难。

. 使用更为严格的规则集，限制能进出的连接

. Jason Rhoads提供了一个PERL程序，,可以为你监视连接表，并按照你定义的规则发出警告

. 使用Fastpath (for ver 或者FastMode (for ver 。这将从连接表中去掉TCP连接，但这也会带来其它的安全问题。关于Fastpath/FastMode请看下面更为详细的介绍。

. 注意: SynDefender并不能保护这种攻击，因为它只被设计来保护SYN flooding攻击，这

是另外一种不同的攻击。这种攻击是基于非SYN包的。

我喜欢FT-1的一个特点是它对待SYN包的方式。如果你试图冒充一个已经存在的连接，初始化一个新连接，防火墙仍然会先与规则集进行比较。例如，假设你试图建立一个这样的连接：

A --- FW -->

B # 系统A联往系统B

现在，系统B可以发送任意的包给系统A,只要IP和端口匹配(例如，那些属于这个连接会话的包).然而，如果系统试图发送SYN包建立一个新的连接，即使它使用与已存在的那个连接同样的端口，防火墙仍然会认为这个SYN包是一个新会话的一部分，将它与规则集进行比较。就我的观点来说，这是件好事。在上面的例子中，如果我们只允许来自外部系统A的连接，不允许从内部的系统B发往外部的连接。那么系统B与系统A联系的唯一方式就是作为一个已建立的连接的一部分来进行。

当系统A连往系统B时，这个连接被加入到防火墙连接检查表中，现在系统B可以发送应答包给系统A了。然而，系统B并不能向A 发送任何的SYN包来新建连接，即使IP和端口号是相同的。当防火墙看到SYN包时，它将这个包与规则集进行比较。在上面所说的条件下，这个包将被丢弃，虽然已经存在一个端口和IP都相同的连接。

Fastpath: 我学到的另外一些东西就是，如果fastpath被使用，那么TCP回话不会被加入到过程连接表中。这是因为Fastpath仅仅检查SYN包，所以不需要将连接会话增加到连接表中。如果一个包中设置了其它的标志，缺省情况下这个包就不会被过滤而是让其通过了。通常fastpatch用来改进性能。它的思路是：如果一个包没有设置SYN标志，那么它肯定是一个已经建立的连接的一部分，因为只有SYN 包才能开始一个连接。既然只检查SYN包，所以性能肯定会大大提高。然而，使用faspatch通常并不是一个好的做法，因为这可能让你暴露在多种攻击方式之下。Fastpath在FW-1 中存在，并且只能对所有的TCP包同时起作用。在中，它又被叫做Fastmode,可以有选择的对不同的TCP服务实施。

关闭一个连接

=================

根据初步的测试结果，FW-1通过设置连接超时时间来关闭连接。当检查模块看到一个连接会话开始交换FIN或者RST包时，它就将超时时间从3600秒改为50秒。如果50秒内没有其它的包发送，连接就被从状态表中删除。如果在超时时间段内又有其它的包发送，那

么超时时间会再被设置成50秒...这可以阻止别人通过发送假的RST或者FIN包来进行拒绝服务攻击。在关闭TCP连接会话时，在应答了第二个FIN包后进入的TIME_WAIT状态与这种超时有点类似。

UDP

====================

维护UDP状态更简单，因为它们是无连接的。当过滤规则允许一个UDP包通过防火墙时，这个连接就被增加到连接表中。在超时时间段(缺省是40秒)内,只要源/目的地址和端口匹配的UDP包都允许通过。例如，下面是一个DNS请求：

Src_IP Src_Prt Dst_IP Dst_Prt IP_prot Kbuf Type Flags Timeout

1111 53 17 0 16386 ff01ff00 34/40

1111 0 17 0 16386 ff01ff00 34/40

你能看到，系统正在向做DSN查询。40秒内，那个系统可以返回任意多的UDP包(只要源/目的地址和端口匹配).注意这里有两个表项，区别是目的端口不同，一个是53,另一个是0.我不知道为什么FW-1会创建那个目的端口为0的表项。如果不是过滤所有的UDP数据传输，这种情况很常见。

ICMP

=======================

FW-1对ICMP的处理很令人失望。缺省情况下，FW-1不对ICMP进行状态检查。它永远不会被放到状态连接表中。因此，用户被迫盲

目地允许特定的ICMP传输(例如入站ECHO_REPLIES）或者不得不自己修改检查代码我认为这是FW-1最大的不足。

报文分组

========================

最近我一直在看报文分组，特别是FW-1如何处理分组报文。尽管报文分组并没有直接应用到状态表中，但我认为它也很重要，值得加入到这篇文章中。我不会详细地将报文分组的原理，我假设读者已经具备了IP报文分组的基本知识。我首先会大体上讲一下FW-1是如何处理报文分组的，然后我会再针对TCP,UDP,ICMP协议讲一下。

首先，FW-1将接收到的分组报文再发出去。就是说如果FW-1收到一个分组的报文，过滤规则也允许它通过的话，它会将这个分组再转发出去。但是，我认为FW-1在检查分组的报文之前肯定进行了某种形式的报文重组。这个结论是在下列测试的基础上得出的。当我用一个完整的分组报文发起TCP连接的时候，报文被防火墙接受并加入到了状态表中，然后再以分组的形式发送给目的主机。现在我的状态表里有了一个会话表项，然后我试图发送更多的分组报文,它们属于同一个连接会话，这些报文也被接受，超时时间被重置。然而，如果我发送一个不完整的TCP分组(也属于同一个连接会话)，这个分组就不被接受，而且它也不会被记录。这让我相信当FW-1第一次收到一个分组报文时，它并不进行规则检查，而是要等到所有的分组均被收到并且完成报文重组后，才进行规则检查。一旦重组完成，防火墙才开始决定如何处理这个报文，是接受还是丢弃，记录等等。另一个例子是使用jolt2，它是一个用来攻击Window系统的工具。它发送100个不完整的ICMP或者UDP分组给选定的目标主机。当用来攻击Fw-1后面的主机时,这些包不会通过防火墙，也不会被防火墙所记录。我认为这是由于这些ICMP分组是不完整的，它们不能被重组为一个完整的ICMP报文，因此也就不会被

检查和记录。

事实上，对于一个包含状态检查的防火墙，常常要进行某种形式的报文重组。很多检查连接状态防的火墙(包括FW-1)检查包都是基于源/目的地址和源/目的端口的(TCP头).然而，对于分组报文，只有第一个分组包含这些信息，所有其它的分组都只有IP地址信息。如

果不进行某种形式的报文重组，防火墙就不能确定后续分组是属于哪个连接会话的（除了第一个分组).通过对分组报文进行重组，防火墙就可以确定这些分组到底是属于哪个连接会话的。

然而，在重组之前不进行报文检查也有一个问题，防火墙就可能遭受不完整或者是非法的分组报文的攻击.既然这些报文是不完整的或者非法的，就不可能被正确重组，它们也不会被检查和记录。所以，防火墙会继续接收这样的包并尝试重组它们，尽管重组是不可能的。因此处理大量的这样的分组将占用系统资源，导致拒绝服务攻击。这种攻击不能通过设置防火墙过滤规则来防止，也不会被记录。为了得到这个漏洞更为详尽的消息，可以看CheckPoint的安全公告如果你是Unix用户，可以在命令行用"fw ctl pstat"来看你的防火墙处理了多少分组。到可以得到更多的相关资料。

下面我们来看看特定的协议。首先，来看TCP.对于数据长度少于24字节的分组报文，FW-1将会丢弃其第一个分组，并且记录下这个报文:"TCP packet too short".(注意：记住，这里我们讨论的数据长度不包括20字节的IP头).例如，用网络扫描工具namp的'-f'选项将会产生一个分组报文，第一个分组数据长度为16个字节，第二个分组为8字节，因此缺省这些分组检测会被FW-1丢弃（不管你的过滤规则如何设置)并被记录。

ICMP和UDP则又有不同。首先，标准的分组长度(8,16,32字节等等)都是可以的(不象TCP,要求至少24字节).然而，"奇数"字节的分组大小是不允许的(这里的"奇数"是指不是8字节的整数倍)。例如,试图发送一个数据长度为12字节的分组，这就不会被接受，也不会被记录。

这些看法都是基于我个人的研究，并不是所谓官方资料。如果你发现我的逻辑，测试方法或者

使用的技术有任何问题，请提醒我！

附录：

测试使用的工具：

可以帮你更好的理解Check Point FW-1的状态检查表。

hping2允许你自己构造TCP/ICMP/UDP包

Nemesis与hping2类似，也有自己一些不同的功能。使用libpcap和libnet.它允许你自己构造各种类型的报文，包括TCP,UDP,ICMP,DNS,OSPF等等

libnet它封装了一些网络函数.