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包的方式。如果你试图冒充一个已经存在的连接，初始化一个新连接，防火墙仍然会先与规则集进行比较。例如，假设你试图建立一个这样的连接：